[02:25] <Keybuk> mbiebl: no, hadn't heard anything about that
[02:25] <Keybuk> cool ;-)
[13:39] <nanonyme> Any devs or other people who'd like to spar a few ideas about upstart present?
[13:39] <sadmac2> nanonyme: what do you mean?
[13:41] <nanonyme> Well, I bumped into the apparently common issue of it being a bit tricky to start programs inside a chroot when dealing with upstart.
[13:42] <nanonyme> I was wondering if there is some working solution and if not, whether dbus could be used so that upstart outside the chroot could communicate with processes inside the chroot and supervise them.
[13:44] <nanonyme> Opinions or ideas?
[13:44] <Keybuk> there isn't a working solution
[13:44] <Keybuk> just some fuzzy ideas
[13:45] <Keybuk> it's not really that high on the urgency list
[13:46] <nanonyme> Yeah. But would you think something like that could work? That is, that since upstart can use dbus, you'd hook up the directories dbus uses between real system and chroot.
[13:47] <nanonyme> (or am I missing something crucial here?)
[13:48] <Keybuk> I don't see how D-Bus helps here
[13:54] <nanonyme> Point. I didn't really think it far enough through.
[13:58] <Keybuk> the difficulty mostly comes from the chroot separation
[13:59] <Keybuk> making sure that "start apache" in the chroot starts the apache in the chroot, not in the outside system
[14:01] <nanonyme> Hrm.
[14:48] <sadmac2_> udev's syntax makes me pee a little.
[15:13] <sadmac> Keybuk: here's one for you: writing a "hey, look how cool libnih is!" blog post. Wanted a practical but simple code snippet that shows why multiple parents is useful.
[15:15] <Keybuk> err, there must be one somewhere in Upstart's source ;-)
[15:15] <sadmac> Keybuk: practical, lots of them. The simple is key :)
[15:16] <sadmac> i.e. an example that makes sense in 20 lines without having to see the whole rest of upstart's code
[15:17] <Keybuk> err, you could use a message?
[15:17] <Keybuk> where a struct has a string in it
[15:18] <Keybuk> (string parent is struct)
[15:18] <Keybuk> and you borrow the string, referencing it, using it in another struct
[15:18] <sadmac> was thinking along those lines
[17:57] <sadmac> http://screwyouenterpriseedition.blogspot.com/2010/03/why-you-should-be-using-libnih.html
[18:32] <sadmac> Keybuk: are you against patches to make some of the ignored compatibility options in /sbin/shutdown do what they used to?
[18:32] <Keybuk> yes
[18:33] <Keybuk> for the most part
[18:33] <Keybuk> IMO shutdown should only accept options that change the way the machine is shut down
[18:33] <sadmac> notting: we still have bugs for making -f, -F, and -n
[18:33] <Keybuk> all of the other silly hangers-on are better off moved to other tools / GNOME UI / etc.
[18:33] <sadmac> notting: kill these things?
[18:34] <Keybuk> -f, -F, etc. wildly assume your filesystem check implementation
[18:34] <Keybuk> e.g. for us, forcing a fsck is adding a kernel command-line argument, not touching a file
[18:34] <sadmac> we can do it either way
[18:35] <Keybuk> right, but I don't want to force that kind of thing
[18:35] <Keybuk> you may not even fsck on boot
[18:36] <Keybuk> maybe it's an embedded system with a read-only filesystem anyway
[18:36] <Keybuk> etc.
[18:36] <Keybuk> that's why I don't want any of those flags in shutdown
[18:37] <sadmac> I'd prefer not to carry patches. I think I'll WONTFIX the fedora bugs. If plautrba wants/is forced to do something about it in RHEL, so be it.
[18:43] <notting> Keybuk: well, if it's an embedded system, you get what you deserve if you tell it to fsck on the next reboot
[18:45] <sadmac> notting: are you up for an initscripts-based fix for 464456?
[18:45] <sadmac> see comment 3
[18:46] <notting> eh, i'm not sure the current behavior is really wrong
[18:46] <Keybuk> notting: put another way
[18:47] <Keybuk> if shutdown should have a "and check filesystems on next reboot" option
[18:47] <Keybuk> shouldn't shutdown also have a "reboot into windows" option? :p
[18:47] <notting> oh gah, lilo -R
[18:48] <sadmac> notting: I can close 464456, or give it to you to close. Where should we put it?
[18:48] <notting> i'll close it
[18:55] <sadmac> notting: https://bugzilla.redhat.com/show_bug.cgi?id=441048 , terminal isn't in cooked mode when it should be?
[18:56] <notting> yeah. it goes away, it comes back. usually we blame halfline
[18:58] <sadmac> notting: should I move it to plymouth? Or to initscripts (I'm guessing some sort of echo ^[!@#$%!@#$^! at the start of the single user job could fix it)
[18:58] <notting> plymouth
[19:03] <sadmac> Keybuk: do you have a launchpad bug about upstart not working on XFS?
[19:12] <nanonyme> Hrm, ^M is supposed to be enter too though, me thinks.
[19:14] <halfline> ^M is carriage return.  tty settings determine whether ^M or ^J or some combination there of is enter
[19:15] <nanonyme> Right. Both ^M and ^J are considered enter here though.
[19:16] <nanonyme> I've always hated the amount of variation those things have. :p Including backspace.
[21:50] <Caesar> Keybuk: you around?