[arch-dev-public] Dangerous dbus update for testing
There's a dangerous dbus update coming up for the testing repository. The package itself isn't so special, as it works fine, but the fact that every dbus-daemon process on your system will crash during the upgrade can lead to unpleasant surprises. Testing users: please be aware of this and run your upcoming upgrades from a plain text console instead of from X. One of the unpleasant surprises is that xorg-server in testing goes down with dbus while it's upgrading, leading to loss of important work or an interrupted package upgrade process.
On Wed, Mar 12, 2008 at 3:37 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
There's a dangerous dbus update coming up for the testing repository. The package itself isn't so special, as it works fine, but the fact that every dbus-daemon process on your system will crash during the upgrade can lead to unpleasant surprises.
Testing users: please be aware of this and run your upcoming upgrades from a plain text console instead of from X. One of the unpleasant surprises is that xorg-server in testing goes down with dbus while it's upgrading, leading to loss of important work or an interrupted package upgrade process.
Awesome. I had something similar happen to me when a status script for my screen session segfaulted while it was upgrading bash... took screen down, and thus killed bash too... fun times. Is there *any* way around this?
On Wed, 2008-03-12 at 15:42 -0500, Aaron Griffin wrote:
On Wed, Mar 12, 2008 at 3:37 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
There's a dangerous dbus update coming up for the testing repository. The package itself isn't so special, as it works fine, but the fact that every dbus-daemon process on your system will crash during the upgrade can lead to unpleasant surprises.
Testing users: please be aware of this and run your upcoming upgrades from a plain text console instead of from X. One of the unpleasant surprises is that xorg-server in testing goes down with dbus while it's upgrading, leading to loss of important work or an interrupted package upgrade process.
Awesome. I had something similar happen to me when a status script for my screen session segfaulted while it was upgrading bash... took screen down, and thus killed bash too... fun times.
Is there *any* way around this?
No, there isn't. The structure of dbus 1.1 is completely different from 1.0. Dbus 1.0 has a configuration-validation algorithm that validates the configuration before doing a reload, but as the new installed configuration is completely valid, but just different from what 1.0 can handle, your 1.0 daemon will crash. As xorg-server doesn't set the right flags when opening the dbus connection and integrating it in the mainloop, it will exit together with your crashing dbus daemon, taking down all programs running inside X without any warning. I was not amused when I upgraded it on my system last monday.
On Wed, Mar 12, 2008 at 3:58 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-03-12 at 15:42 -0500, Aaron Griffin wrote:
On Wed, Mar 12, 2008 at 3:37 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
There's a dangerous dbus update coming up for the testing repository. The package itself isn't so special, as it works fine, but the fact that every dbus-daemon process on your system will crash during the upgrade can lead to unpleasant surprises.
Testing users: please be aware of this and run your upcoming upgrades from a plain text console instead of from X. One of the unpleasant surprises is that xorg-server in testing goes down with dbus while it's upgrading, leading to loss of important work or an interrupted package upgrade process.
Awesome. I had something similar happen to me when a status script for my screen session segfaulted while it was upgrading bash... took screen down, and thus killed bash too... fun times.
Is there *any* way around this?
No, there isn't. The structure of dbus 1.1 is completely different from 1.0. Dbus 1.0 has a configuration-validation algorithm that validates the configuration before doing a reload, but as the new installed configuration is completely valid, but just different from what 1.0 can handle, your 1.0 daemon will crash.
As xorg-server doesn't set the right flags when opening the dbus connection and integrating it in the mainloop, it will exit together with your crashing dbus daemon, taking down all programs running inside X without any warning. I was not amused when I upgraded it on my system last monday.
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later. I ask because I can't really think of a better way. Dang this is stupid. -Dan
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed. This topic comes up once in a while: http://www.archlinux.org/news/288/ Last year it was gnome-session and XFCE Terminal, this year it's Xorg, with the difference that Xorg is in testing, while the offended gnome-session package was on most extra users' system.
On Wed, Mar 12, 2008 at 4:30 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
Ooooh. This makes it more clear. So when we get a sane xorg-server that doesn't override keyboard layouts, then this won't be an issue. I didn't understand that part. That makes much more sense now 8)
On Wed, Mar 12, 2008 at 4:36 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 12, 2008 at 4:30 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
Ooooh. This makes it more clear. So when we get a sane xorg-server that doesn't override keyboard layouts, then this won't be an issue. I didn't understand that part. That makes much more sense now 8)
Ahh. So why haven't we purged ourselves of this broken xorg-server yet? I haven't seen too many +1 votes for it, and I've been staying away from using it after the early feedback. -Dan
Am Mittwoch, 12. März 2008 schrieb Dan McGee:
On Wed, Mar 12, 2008 at 4:36 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Mar 12, 2008 at 4:30 PM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
Ooooh. This makes it more clear. So when we get a sane xorg-server that doesn't override keyboard layouts, then this won't be an issue. I didn't understand that part. That makes much more sense now 8)
Ahh.
So why haven't we purged ourselves of this broken xorg-server yet? I haven't seen too many +1 votes for it, and I've been staying away from using it after the early feedback.
-Dan
here it breaks qemu keymapping, so -1 from me for the acutal xorg-server -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Wed, Mar 12, 2008 at 10:30:19PM +0100, Jan de Groot wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
I'm not against input hotplugging. I am against input hotplugging that dies when it loses the connection to dbus. What other things does it break? Jason
On Wed, 2008-03-12 at 16:09 -0700, Jason Chu wrote:
On Wed, Mar 12, 2008 at 10:30:19PM +0100, Jan de Groot wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
I'm not against input hotplugging. I am against input hotplugging that dies when it loses the connection to dbus.
What other things does it break?
Crosspaste from other thread. Note that point 4 will take until next year to finish... something xorg-server-1.6'ish: 1. The dbus code is shit 2. Configuration of keyboard maps is shit 3. Suspend/resume is shit (probably related to 1.) 4. XInput itself is in very bad state already Point 1 can be triggered by /etc/rc.d/dbus restart. Point 2 can be triggered by wanting something else than a US keymap, combined with some nice non-standard variant Point 3 has been reported in combination with synaptics, but I haven't investigated on it further because I know 1 and 2 are valid. Point 4 was told to me at FOSDEM by Daniel Stone, the only maintainer I know that has the guts to mess with code that nobody wants to get his hands dirty on.
On Thu, Mar 13, 2008 at 12:26:42AM +0100, Jan de Groot wrote:
On Wed, 2008-03-12 at 16:09 -0700, Jason Chu wrote:
On Wed, Mar 12, 2008 at 10:30:19PM +0100, Jan de Groot wrote:
On Wed, 2008-03-12 at 16:12 -0500, Dan McGee wrote:
Is there any better way to handle this? When this gets moved to extra, people -Syu first, read front page news later.
I ask because I can't really think of a better way. Dang this is stupid.
The crashing xorg-server is in testing and will never make it to extra: we're against the input hotplugging as it breaks too many things, including a dbus restart. This warning is for testing users who also have xorg-server from testing installed.
I'm not against input hotplugging. I am against input hotplugging that dies when it loses the connection to dbus.
What other things does it break?
Crosspaste from other thread. Note that point 4 will take until next year to finish... something xorg-server-1.6'ish:
1. The dbus code is shit 2. Configuration of keyboard maps is shit 3. Suspend/resume is shit (probably related to 1.) 4. XInput itself is in very bad state already
Point 1 can be triggered by /etc/rc.d/dbus restart. Point 2 can be triggered by wanting something else than a US keymap, combined with some nice non-standard variant Point 3 has been reported in combination with synaptics, but I haven't investigated on it further because I know 1 and 2 are valid. Point 4 was told to me at FOSDEM by Daniel Stone, the only maintainer I know that has the guts to mess with code that nobody wants to get his hands dirty on.
Ok, agreed on point 1. I'm using a dvorak keymap... true, it's not a variant. I did tell hal to tell xorg to use the kbd driver. I have a synaptics touchpad that works fine with suspend/resume. I did run into one problem this morning, but I'm not exactly sure whose fault it was. Hal seemed to think the only keyboard/mouse I had were the external ones. It forgot that I had builtin keyboard and mouse. I can't say anything about point 4. I thought XInput (which I assume is for input hotplugging) was one of the cool new technologies being worked on in xorg. My only concern in this whole thing is that we'll take out hal support because we're prejudiced against it, not because it's not ready for general consumption. Once it's ready for general consumption I hope that we do make the decision to include it. Jason
Jason Chu schrieb:
My only concern in this whole thing is that we'll take out hal support because we're prejudiced against it, not because it's not ready for general consumption. Once it's ready for general consumption
and documented and possible to disable in xorg.conf
I hope that we do make the decision to include it.
Fine by me.
Jan de Groot schrieb:
No, there isn't. The structure of dbus 1.1 is completely different from 1.0. Dbus 1.0 has a configuration-validation algorithm that validates the configuration before doing a reload, but as the new installed configuration is completely valid, but just different from what 1.0 can handle, your 1.0 daemon will crash.
As xorg-server doesn't set the right flags when opening the dbus connection and integrating it in the mainloop, it will exit together with your crashing dbus daemon, taking down all programs running inside X without any warning. I was not amused when I upgraded it on my system last monday.
I want to repeat what I already told you (Jan) on IRC: xorg with input hotplugging enabled breaks my system and is not needed (keyboard and mouse hotplugging work well enough when using the kbd driver and /dev/input/mice with the mouse driver). I actually downgraded to extra/xorg-server only half an hour after the upgrade. I say, we revert xorg-server back to the old behaviour until: 1) it works properly with dbus and is actually configurable to different layouts than us 2) it is documented in the manpages (right now, hal or dbus aren't mentioned in any xorg or xorg.conf manpage, and hotplugging cannot be disabled once it is built in).
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Jan de Groot
-
Jason Chu
-
Thomas Bächler
-
Tobias Powalowski