[arch-general] recent upgrade has messed up x

[Scott Weisman]

Until last week, my X setup worked fine. No special configuration needed.

I have a 3rd generation Core i7 notebook with a dual monitor setup.

After a recent update, everything works differently, and not for the better.

Before, with a VGA monitor plugged in (with or without a second HDMI
monitor), the system would boot and output the console display to both the
VGA and LCD. Default X startup was to display at full screen resolution and
also output to VGA and LCD. Now, no matter what, it only outputs to LCD.

The xrandr command to go to dual monitor used to switch within a few
seconds at most. Now, it FAILS the first time. All screens are blank. I
then do a second xrandr to output only to external VGA, which succeeds.

I see this output from the previous command:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  21 (RRSetCrtcConfig)
  Serial number of failed request:  39
  Current serial number in output stream:  39

A third xrandr command to once again go to dual then works.

However, the transition takes MUCH longer.

And there are further problems. I have seen the HDMI screen occasionally
blank (the VGA screen is unaffected) for many seconds, then just go back
on. When the screens blank from lack of activity, the time to turn on is
also much longer than the previous 1 or 2 seconds.

The HDMI screen has a great deal of "flicker" (it's not actual flicker,
it's horizontal lines flashing) that just doesn't stop.

No X packages were updated recently. But there was a kernel update from 4.3
to 4.4.

I had zero problems before. Can anyone suggest some fixes? Would be much
appreciated.

Re: [arch-general] [arch-mirrors] pacman verify database

[João Miguel]

> >i've setup a mirror this week. one sync today synced an incomplete state
> >from a tier1 mirror. is there a tool/script to determine if a/my mirror
> >is in a consistent state?
> 
> I am not aware of any such tool. I'm forwarding this to arch-general
> in the hope that someone either knows or wants to create one.
> 
> Florian
I've found this page: https://www.archlinux.org/mirrors/status/. It's
available as a JSON file too. So you can just query it and off you go.

Re: [arch-general] recent upgrade has messed up x

[João Miguel]

I have a black screen with Xorg 1.18, both with nvidia and intel graphic
cards. So I'm using 1.17. However, with 1.17 and an intel graphic card
update I'd get a black screen as well. Are you sure xf86-video-intel is
not to blame? Maybe you should try to downgrade it.

Hope this helps,
João Miguel

[arch-general] Alternative init system proposal

[Ivan]

Hello, I have a proposal for Arch Linux developers and by mailing
on this list I would also appreciate feedback from non-developers that
use Arch Linux. 
Note: I am not here to hate on the current status, nor
to disapprove of current Arch choices.

So, to get to the point...
I would like to propose development and official support of an
alternative init system and service manager. My main preference would be
OpenRC + sysvinit. The combination of those two has shown to work
surprisingly well even with the current Arch's binary packages which are
compiled with systemd support/dependencies. There are OpenRC packages
already in the AUR, as well as an unofficial repository called
"openrc-eudev" that replaces udev with Gentoo's eudev. See 
http://systemd-free.org for more info. (Please disregard the hate on the 
website, I am not pro-systemd-hate)
Now, I realize this is not the correct way to do this stuff, and if we
want 
an alternative system, a lot of compiling might have to be done, Or is
it 
possible to keep systemd support?

1. Udev... Well, there are two alternatives worth mentioning. The first
is,
obviously, Gentoo's eudev that works really well, and keeps udev
compatibility. Another alternative worth mentioning is vdev
(https://github.com/jcnelson/vdev). It is also maintained in the AUR.
vdev is developed to be completely non-dependent on systemd and I think
it might be a nice option to consider. Note that it is still under
development.

2. Packaging... If current and furure builds are kept with systemd
support,
then there's only the option of including an OpenRC-compatible script in
the same package, along with the systemd.service file, and then
depending on what's used on the machine, install the according one (in
most cases).
Otherwise, new compilation will have to be done, and that brings up the
issue of storage space, which, in the worst case - gets cut in half.
I would need more feedback on this.

2.1. Repositories... core, extra, community and multilib would not need
any -openrc offsprings. If we would build new packages, without systemd
support, pacman would need code modifications to distinguish between the
two - systemd and openrc. An idea is to modify the package naming scheme
somehow, possibly -openrc and -systemd. 

3. Support... The biggest drawback is definitely the support that goes
on in ArchBBS, ArchWiki, Bugtracker and eventually #archlinux on
freenode IRC. 
The ArchBBS and the IRC wouldn't be detriment(?) because they don't
really 
have any *specific* support threads or sections. However, the ArchWiki
would 
need a lot of rewriting/editing, but honestly, the community is big
enough to handle it. As for the bugtracker, it might get a bit more bugs
than usually :D

To conclude, this is still a mere draft and a proposal. I realize that
there are a lot more things to be discussed about this. So, please give
me feedback on all of this and let's see what we can do about it and
what it can develop into...

Kind regards to the entire mailinglist,
~ parazyd


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Devon Smith]

No. Systemd is here to stay. Maintaining another's init would be a waste of
time and too much work. Plus, why on earth would people want to waste time
maintaining another init system when the one we have works? Is there
anything lacking in systemd that is available in openrc?
On Feb 7, 2016 18:11, "Patrick Burroughs (Celti)"  wrote:

> On Mon, 8 Feb 2016 01:58:19 +0100
> Ivan  wrote:
>
> > Hello, I have a proposal for Arch Linux developers and by mailing
> > on this list I would also appreciate feedback from non-developers that
> > use Arch Linux.
> > Note: I am not here to hate on the current status, nor
> > to disapprove of current Arch choices.
> > [snip]
>
> The big question you have to answer, the one you need to start with, is:
>
> Why is it in the Arch dev's interests to maintain two init systems and
> that much more area for incompatibility, that many more packages and
> bugs to wrangle? Especially if they are happy using systemd?
>
> Nobody could answer that question a few years ago, so the original Arch
> initscripts were dropped in favour of a systemd-only distro.
>
> If you have a serious answer, by all means, present it — but that *is*
> the stumbling block here.
>
> ~Celti
>

Re: [arch-general] Alternative init system proposal

[Doug Newgard]

On Mon, 8 Feb 2016 02:37:57 +
mick  wrote:

> On Sun, 7 Feb 2016 18:30:15 -0700
> Devon Smith  wrote:
> 
> > Is there anything lacking in systemd  
> A clear, logical and consistant naming convention for the services, units, 
> etc used by systemd, on a number of occasions I have spent an hour or more 
> looking for the script that controls a particular service. Admittedly there 
> seems to be less of them now than when systemd first invaded. cups is a pet 
> hate of mine, wouldn't 'cupsd' be much more intuitive than 
> 'org.cups.cupsd.service' or am I missing something?

Yeah, pacman -Ql  | grep service

Should take significantly less than an hour.

Re: [arch-general] Alternative init system proposal

[Jan Alexander Steffens]

On Mon, Feb 8, 2016 at 4:56 AM, Leonid Isaev
 wrote:
> That's why I still use Debian 5 stable in a container as a print server... 
> Cups
> 2.0+ is a real piece of crap. And yes, these org.xxx.xxx names _are_ stupid
> especially for filenames. But after using modern Fedoras, I think that systemd
> services are no longer supposed to be managed manually, but rather through 
> some
> frontend...

http://cockpit-project.org/

Re: [arch-general] Alternative init system proposal

[mick]

On Sun, 7 Feb 2016 18:30:15 -0700
Devon Smith  wrote:

> Is there anything lacking in systemd
A clear, logical and consistant naming convention for the services, units, etc 
used by systemd, on a number of occasions I have spent an hour or more looking 
for the script that controls a particular service. Admittedly there seems to be 
less of them now than when systemd first invaded. cups is a pet hate of mine, 
wouldn't 'cupsd' be much more intuitive than 'org.cups.cupsd.service' or am I 
missing something?

> that is available in openrc?
probably not.

It's much better to fix whats there and mostly works than go through the trauma 
of getting to grips with a new mostly works tool. 

mick

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

On Mon, Feb 08, 2016 at 03:28:36AM +, mick wrote:
> On Sun, 7 Feb 2016 20:51:50 -0600
> Doug Newgard  wrote:
> 
> > On Mon, 8 Feb 2016 02:37:57 +
> > mick  wrote:
> > 
> > > On Sun, 7 Feb 2016 18:30:15 -0700
> > > Devon Smith  wrote:
> > >   
> > > > Is there anything lacking in systemd
> > > A clear, logical and consistant naming convention for the services, 
> > > units, etc used by systemd, on a number of occasions I have spent an hour 
> > > or more looking for the script that controls a particular service. 
> > > Admittedly there seems to be less of them now than when systemd first 
> > > invaded. cups is a pet hate of mine, wouldn't 'cupsd' be much more 
> > > intuitive than 'org.cups.cupsd.service' or am I missing something?  
> > 
> > Yeah, pacman -Ql  | grep service
> > 
> > Should take significantly less than an hour.
> > 
> 
> Now that I know about it, but I still think cupsd.service is more intuitive.

That's why I still use Debian 5 stable in a container as a print server... Cups
2.0+ is a real piece of crap. And yes, these org.xxx.xxx names _are_ stupid
especially for filenames. But after using modern Fedoras, I think that systemd
services are no longer supposed to be managed manually, but rather through some
frontend...

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Patrick Burroughs (Celti) wrote:

> The big question you have to answer, the one you need to start with, is:
> 
> Why is it in the Arch dev's interests to maintain two init systems and
> that much more area for incompatibility, that many more packages and
> bugs to wrangle? Especially if they are happy using systemd?
> 
> Nobody could answer that question a few years ago, so the original Arch
> initscripts were dropped in favour of a systemd-only distro.
> 
> If you have a serious answer, by all means, present it — but that *is*
> the stumbling block here.

I would start by taking out some quotes out of
https://wiki.archlinux.org/index.php/Arch_Linux

"Arch is installed as a minimal base system, configured by the user upon
which their own ideal environment is assembled by installing only what
is required or desired for their unique purposes."

"Arch Linux has always been, and shall always remain user-centric. The
distribution is intended to fill the needs of those contributing to it
rather than trying to appeal to as many users as possible."

"... it is the user who decides what his system will be."

I know everyone always cites this in their anti-systemd rands, but Linux
really has always been about choice, and yet all the major distributions
seem to embrace the same init system: systemd. Thus, distros are giving
up on their "distinctiveness" Now I keep seeing almost all the "big" 
GNU/Linux embracing nothing but systemd and that's very dissapointing.
(Arch) Users aren't picking systemd because it's there and it's perfect,
but
because there is no other choice, and was to a certain point imposed to
them... I am most certainly not going back to the past and referencing
the
mailinglist discussions where initscrips was dropped in favor of
systemd. That was the decision, and I fully respect it. Nevertheless,
consider: does Arch really have to *demand* systemd to be the only init
system? Not saying it will happen, and this being really farfetched:
Eventually the difference between distros seems to boil down to having a
different distribution name and a different package manager. It may
eventually become impossible to use Linux without also using systemd.
For me, and many other communities out there this is not a very pleasant
thing. I don't want to impose it here, but I'm sure you are aware of all
the init/systemd wars going on...

Since 2012, a lot of things happened. systemd gained a lot more
traction, maybe even due to the fact Arch implemented it. 
Note: OpenRC is actively developed since 2007. by developers coming from
the Gentoo community. Since then, it has grown into a very big project.
As for udev (it was integrated into systemd, and knowing hotplugging is
necessary for most users nowadays), The Gentoo developers have forked it
and named it eudev. Since then, eudev is also under active development.
It provides everything udev does, and doesn't break current udev stuff.
I can even personally confirm this, since I use OpenRC and eudev on my
personal computer (running Arch Linux, of course) instead of systemd.

To those saying "What does OpenRC have that systemd doesn't?": OpenRC
isn't made as a clone of systemd. It's a tool for itself, and works the
way it's made to work. If you still with to ask that question, note that
OpenRC can actually do as much as systemd (possibly even more, but I'm
no systemd wizard). Also here is the forum post where tomegun talks
about 
systemd adoption and lists some key points. Feel free to compare it to
OpenRC and the tools OpenRC is used with.
https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530
Anyone willing to discuss this in more depth, feel free to reply.

Let's go back to Arch itself, as the distro. 
As we all know, Arch is built around the KISS principle. (Yes, I know
this is contradictory to my request, but also note the beginning of this
email)
So, the KISS principle... I'm still sticking to OpenRC, and now I will
have to make some short notes:
* Daemon management is as simple as systemd. As a matter of fact,
  most (if not all) OpenRC users I've talked to say that it's even
  simpler than systemd because we can find everything in /etc/init.d/ 
  as opposed to `systemctl edit` and its tmpfiles/overrides. (Again, 
  I'm not a systemd wizard, don't take things for granted)
* Simplicity through /etc/init.d helps you fix misconfigured daemons
  more easily than systemd in case you forgot what you did. (Sort
  /etc/init.d/* by latest file modification)
* "Networking is difficult" - Absolutely not! In fact, even
  NetworkManager works just fine with OpenRC. With proper packaging,
  users will not need to do anything.
* "It's for power users" - Again, no. While many power users and (older
  system administrators prefer not using systemd, this does not mean
  OpenRC is necessarily complicated to use. Quite the opposite,
  OpenRC makes management very user-friendly and simple. Also, 

Re: [arch-general] Alternative init system proposal

[Patrick Burroughs (Celti)]

On Mon, 8 Feb 2016 01:58:19 +0100
Ivan  wrote:

> Hello, I have a proposal for Arch Linux developers and by mailing
> on this list I would also appreciate feedback from non-developers that
> use Arch Linux. 
> Note: I am not here to hate on the current status, nor
> to disapprove of current Arch choices.
> [snip]

The big question you have to answer, the one you need to start with, is:

Why is it in the Arch dev's interests to maintain two init systems and
that much more area for incompatibility, that many more packages and
bugs to wrangle? Especially if they are happy using systemd?

Nobody could answer that question a few years ago, so the original Arch
initscripts were dropped in favour of a systemd-only distro.

If you have a serious answer, by all means, present it — but that *is*
the stumbling block here.

~Celti


pgpAM4VFXloKj.pgp
Description: OpenPGP digital signature

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

Hi,

On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> 1. Udev...

You don't need udev in most cases. For instance, on a workstation, you can
simply create device nodes by hand.

> 2. Packaging...

Not an issue really.
 
> 2.1. Repositories... core, extra, community and multilib would not need

People who would be running an alternative init system wouldn't need much
support.

> I realize that there are a lot more things to be discussed about this.

And here is a can of worms. What are you going to do with logind and various
desktop integrations? What about systemd-tmpfiles snippets that do magic in
the background?

Regarding former, before you say consolekit2, it's not an answer. Yes, systemd
may be getting in too many places, but the previous state of affairs was not
better (I think everyone would agree that ck is a broken concept). Also, don't
forget about wayland. I strongly suspect that it is not going to run without
logind.

Regarding latter, you'll have to roll out lots of install files in existing
packages, even those that have no relation to an init system.

You see, by itself, systemd is a stupid and irrelevant piece of software. It is
things around it that create real problems...

HTH,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Alternative init system proposal

[mick]

On Sun, 7 Feb 2016 20:51:50 -0600
Doug Newgard  wrote:

> On Mon, 8 Feb 2016 02:37:57 +
> mick  wrote:
> 
> > On Sun, 7 Feb 2016 18:30:15 -0700
> > Devon Smith  wrote:
> >   
> > > Is there anything lacking in systemd
> > A clear, logical and consistant naming convention for the services, units, 
> > etc used by systemd, on a number of occasions I have spent an hour or more 
> > looking for the script that controls a particular service. Admittedly there 
> > seems to be less of them now than when systemd first invaded. cups is a pet 
> > hate of mine, wouldn't 'cupsd' be much more intuitive than 
> > 'org.cups.cupsd.service' or am I missing something?  
> 
> Yeah, pacman -Ql  | grep service
> 
> Should take significantly less than an hour.
> 

Now that I know about it, but I still think cupsd.service is more intuitive.

Re: [arch-general] Alternative init system proposal

[Leonid Isaev]

On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> process that does not happen overnight. Through time, solutions will
> surface. I'm not a magic lamp genie that has all the answers. 

Then you have to ask yourself, what defines a distribution. If you are going to
bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce customizations
to lots of other packages, isn't it easier to start from gentoo or alpine and
maintain pacman for those distros? I am asking because you are going to
duplicate a fair share of official repos...

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Alternative init system proposal

[Yaro Kasear]

I still don't get what makes OpenRC so great. Doesn't it still depend
entirely on SysV Init? That ALONE makes me want to keep it off my system.
If it makes us fall back on an init system that is frankly backward and was
badly in need of replacement then I don't see why it should be considered
an alternative.

Systemd ain't perfect, but when the best alternative is something that
relIes on dated components bona fide Unix systems don't even use anymore,
then they simply aren't alternatives.
On Feb 7, 2016 11:36 PM, "Leonid Isaev" 
wrote:

> On Mon, Feb 08, 2016 at 06:02:34AM +0100, Ivan wrote:
> > Hypothetically, if Arch Linux was to adopt an alternative init, it's a
> > process that does not happen overnight. Through time, solutions will
> > surface. I'm not a magic lamp genie that has all the answers.
>
> Then you have to ask yourself, what defines a distribution. If you are
> going to
> bring in ck, patch polkit, gnome, kde, xfce, etc, and introduce
> customizations
> to lots of other packages, isn't it easier to start from gentoo or alpine
> and
> maintain pacman for those distros? I am asking because you are going to
> duplicate a fair share of official repos...
>
> Cheers,
> --
> Leonid Isaev
> GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
>   C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
>

Re: [arch-general] Alternative init system proposal

[Jack L. Frost]

On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> Hello, I have a proposal for Arch Linux developers and by mailing
> on this list I would also appreciate feedback from non-developers that
> use Arch Linux. 
> ...

It's not reasonable to demand Arch devs maintain several init systems.
You can pretty easily maintain that out of the main repos for yourself
and others.

There are several maintained solutions already.
http://systemd-free.org details one such solution (openrc + sysvinit).
https://wiki.archlinux.org/index.php/Runit there's also runit.
https://fleshless.org/pages/spark.html I have a personal solution.

And there are others I can't quite remember right now.

Let the dev team focus on a stable base and modify it if you need to.


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Leonid Isaev wrote:
> On Mon, Feb 08, 2016 at 01:58:19AM +0100, Ivan wrote:
> 
> > I realize that there are a lot more things to be discussed about this.
> 
> And here is a can of worms. What are you going to do with logind and various
> desktop integrations? What about systemd-tmpfiles snippets that do magic in
> the background?
> 
> Regarding former, before you say consolekit2, it's not an answer. Yes, systemd
> may be getting in too many places, but the previous state of affairs was not
> better (I think everyone would agree that ck is a broken concept). Also, don't
> forget about wayland. I strongly suspect that it is not going to run without
> logind.

While I don't think it's time to debate consolekit yet, I would have to
say that it currently is an option.
Gnome (being made systemd-dependent) can still be patched to work
without systemd. Wayland is also proven to run without systemd. Though I
am not sure what will happen with future development (see your last two
sentences)...
 
> Regarding latter, you'll have to roll out lots of install files in existing
> packages, even those that have no relation to an init system.
> 
> You see, by itself, systemd is a stupid and irrelevant piece of software. It 
> is
> things around it that create real problems...

Hypothetically, if Arch Linux was to adopt an alternative init, it's a
process that does not happen overnight. Through time, solutions will
surface. I'm not a magic lamp genie that has all the answers. 


signature.asc
Description: PGP signature

Re: [arch-general] Alternative init system proposal

[Ivan]

On Sun, 07 Feb 2016, Devon Smith wrote:

> No. Systemd is here to stay. Maintaining another's init would be a waste of
> time and too much work. Plus, why on earth would people want to waste time
> maintaining another init system when the one we have works? Is there
> anything lacking in systemd that is available in openrc?

systemd isn't going anywhere. I'm not here acting as a GNU preacher or
whatever. I do not want to replace systemd, I am merely proposing an 
alternative to systemd for Arch Linux users. And users do want
alternatives. Especially Arch Linux users. After all, to put it simple:
Arch was always about control and customization. Why wouldn't users be
able to choose their initsystem/servicemanager? 

Time maintaining for sure would not be wasted. Reading the emails that
started as a reply to you might give you some insight. 

Arch is arguably one of the biggest distributions around today. By
offering an alternative init system, the community would undoubtly
become even bigger, and eventually, bring in more donations, and support
from all kinds of folks.

Is there anything lacking in systemd? Honestly, I would say there's too
much...

~ parazyd


signature.asc
Description: PGP signature