[00:09] <soren> damjan: Funny you should ask...
[00:10] <soren> damjan: https://bugs.launchpad.net/bugs/372864
[00:10] <damjan> funny as in, you are laughing all the way to the bank? :)
[00:11] <damjan> thanks
[00:11] <soren> Sure :)
[00:13] <damjan> I don't think this is available in 0.6.3 .. (does launchpad corellate bug reports with commits??)
[00:15] <ion> Karmic has 0.6.3, so what Scott said in the last message would work with it.
[00:16] <ion> The tty-device-added event must come from upstart-udev-bridge.
[00:16] <ion> Indeed, strings =upstart-udev-bridge:
[00:16] <ion> %s-device-added
[00:16] <ion> KERNEL=%s
[00:18] <Keybuk> it does
[00:38] <damjan> is upstart-udev-bridge going to be included in future upstart versions?
[00:39] <ion> Future Upstart versions won’t need it, as they’ll have the functionality built-in.
[00:40] <damjan> ion: how do you know this stuff? (it's a bit hard to come by upstart info)
[00:41] <ion> damjan: The upstart-udev-bridge man page says sos.
[00:41] <ion> so
[00:41] <damjan> ahh :)
[00:41] <Keybuk> damjan: you can just ask for upstart info ;)
[00:42] <damjan> Keybuk: the problem is when you don't know what to ask ... Upstart is still new (and changing) and has possibilities that weren't available before
[00:43] <Keybuk> that's certainly true
[00:44] <damjan> I'm experimenting with Upstart on ArchLinux .. so far I have it working
[00:44]  * Esmil too ;)
[02:33] <ion> http://xkcd.com/645/ :-D
[07:42] <testi_>  In 9.04 Upstart does not emit an event when a network device goes up, or a default route is added. How can I execute a script as soon as network is available (without busy waiting!)
[07:42] <testi_> Ubuntu 9.04
[07:52] <Md> testi_: use udev
[07:53] <testi_> okay
[08:17] <testi_> Hmm but there is an example event network-up (that is not emitted in Ubuntu). Use udev because upstart is incomplete? Or use udev to tellupstart that a ertain device has now an ip-adress?
[13:21] <spaetz> Hi
[13:22] <spaetz> Is it intended that a "restart dbus" kills my X server and restarts it?
[13:22] <Keybuk> yes
[13:22] <spaetz> without notifying or asking me?
[13:22] <Keybuk> you told it to, why would it ask you?
[13:23] <spaetz> because update-manager upgraded dbus which killed the X session which ran the update
[13:23] <spaetz> and therefore my upgrade was left in a state of limbo with a non-functioning network-manager
[13:23] <Keybuk> update-manager does not run "restart dbus"
[13:23] <Keybuk> if you had a bug like that, you should contact your distribution
[13:23]  * spaetz shrugs. All I did was running update-manager and it suddently restarted X
[13:24] <spaetz> I understand that living on the beta-edge will expose me to stuff like that
[13:24] <spaetz> but it's quite annoying. Also I used to /etc/init.d/dbus restart just fine without having X killed
[13:24] <spaetz> so if you are not aware of the dependency tree, a lot of bad stuff can happen
[13:25] <spaetz> who knows what else X depends on...
[13:25] <Keybuk> I don't see that it's a bug
[13:25] <Keybuk> if you're restarting services without understanding what depends on them, you deserve everything you get ;-)
[13:26] <spaetz> it might not be a bug, strictly speaking. But I am very much afraid of restarting *any* service now when in a X session.
[13:26] <spaetz> So, is there an easy way to find out the dependency tree?
[13:26] <spaetz> If there is none, then I'd consider that missing crucial functionality :)
[13:26] <Keybuk> no, because upstart doesn't work by dependencies
[13:27] <spaetz> so, how do I find out what else would kill my X?
[13:27] <Keybuk> read the /etc/init/gdm.conf fiole
[13:27] <spaetz> e.g. restart hal? dbus? cups? How can I find out?
[13:28] <spaetz> will do, and thanks for your patience
[13:28] <Keybuk> and then you'll discover that Upstart had no part in your X server restarting
[13:28] <Keybuk> and, in fact, your X server crashed *all by itself*
[13:28] <spaetz> Keybuk: no crash. Windows suddently started closing one after the other
[13:28] <Keybuk> it's crashing, just awkwardly ;)
[13:29] <spaetz> hehe, ok. I'll read the gdm.com stuff and check it out
[13:29] <spaetz> fortunately, i didn't have important stuff open
[13:30] <spaetz> the critical line seems to be: start on (filesystem and started hal)
[13:30] <spaetz> so when hal stops, gdm would stop
[13:31] <spaetz> and I assume hal depends on dbus
[13:31] <spaetz> ahh, and on udev. So no more udev restarts with running X either.
[13:31] <Keybuk> no
[13:31] <Keybuk> incorrect
[13:31] <Keybuk> that means that when hal is started, gdm is started
[13:32] <Keybuk> the "stop on" line is all about stopping, and that doesn't mention hal
[13:32] <spaetz> so when hal stops, gdm wouldn't stop? ok
[13:32] <spaetz> so then "restart dbus" making X restart must be a crash
[13:32] <spaetz> I recommend to write a blog post about that :)
[13:33] <Keybuk> when hal stops, X crashes
[13:33] <Keybuk> that's quite different
[13:33] <Keybuk> blog away ;)
[13:34] <spaetz> may, I quote bits of our conversation to make things clear?
[13:34] <spaetz> -> "may I..."
[13:35] <Keybuk> sure
[13:36] <Keybuk> though my conversation isn't exactly reveraling
[13:36] <spaetz> hehe, was interesting enough to me, thanks for the time to explain stuff
[13:37] <spaetz> next 24 days must be quite busy :)
[13:38] <spaetz> bye
[13:39] <mgoetze> Keybuk: about #433270 - where do those tty-device-added events come from? upstart itself? or do i need an appropriate udev configuration to emit them?
[13:45] <Keybuk> upstart-udev-bridge
[13:47] <mgoetze> that seems to exist in ubuntu, but i don't use ubuntu...
[13:48] <spaetz> I'll probably cut out some parts of the conversation later. But here is a draft quoting us (it's more than bits for now :-) ): http://sspaeth.de/archives/1191-Upstart-killed-the-Video-star.html
[13:54] <Keybuk> spaetz: the title is rather misleading
[13:55] <Keybuk> since we already established that it's X that dies on its own
[13:55] <Keybuk> sorry, but your blog post has no use
[13:56] <Keybuk> you're not documenting anything, just bitching
[13:56] <Keybuk> so I recall my permission to use anything I've said there
[13:58]  * spaetz shrugs. Your call. Will remove the quoting.
[13:58] <spaetz> we, did start the conversation that way though: 14:22 < spaetz> Is it intended that a "restart dbus" kills my X server and restarts it?
[13:58] <spaetz> 14:22 < Keybuk> yes
[14:12] <damjan> spaetz: yep, that dependecy on the system dbus in the X server is a new "feature"
[14:12] <damjan> ... and it sucks
[14:13] <damjan> btw, when I was asking (don't remmember what channel) the response was "dbus shouldn't be restarted"
[14:13] <spaetz> damjan: agreed
[14:13] <damjan> .. ever
[14:13] <spaetz> haha. Code just shouldn't crash, mem leaks not happen, and Microsoft play nice :-)
[14:14] <spaetz> everything should stand a reload of some other service without crashing on me
[14:15] <mgoetze> spaetz: go ahead and write an operating system in erlang then. we're all looking forward to the result, i can tell you
[14:17] <damjan> well, at least Dbus could be written in erlang :)
[14:17] <damjan> incerdible, there isn't even a bug report on bugs.freedesktop.org
[14:18]  * spaetz doesn't see what erland has to do with the fact that Xorg seems to have made a design decision that is just plain silly
[14:18] <spaetz> s/erland/erlang/
[14:19] <damjan> spaetz: an erlang dbus service could "restart" itself without bringing down the connections
[14:19] <damjan> but yeah, the Xorg server just uses the standard lib that doesn't handle disconnections from the bus AFAIK
[14:21] <spaetz> I see
[14:23] <damjan> but this bug report claims it's a problem in gnome-session http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527860
[14:24]  * spaetz just found the same bug report :). THere is also one for Gentoo and Arch.
[14:24] <damjan> spaetz: do you use Gnome?
[14:26] <damjan> ah.. so it was a problem in Awesome too
[14:26] <damjan> I should test this again
[14:26] <spaetz> Gnome yes.
[14:28] <damjan> ok, so in latest Xorg-server and awesome I don't have the problem .. so X is ok :)
[14:29] <damjan> xorg-server 1.6.3.901 here
[16:49] <ion> keybuk: I could rebase the fsck-locking branch against the ubuntu-core-dev branch. Or are you already doing that?
[17:45] <ion> keybuk: Rebased and verified to work.
[18:41] <ion> keybuk: “Flush standard output and error before spawning processes to make capturing logs easier (otherwise we end up repeating things still in the buffer).” Ah, so that’s what it was. I guessed the behavior must be related to something getting duplicated with the forks that shouldn’t, but i never got around to investigating it.