[13:43] <Keybuk> I discovered a really nice Upstart feature over the weekend
[13:43] <Keybuk> it wasn't one I designed, but it's a wonderful emergent feature
[13:44] <ion> :-)
[13:45] <ion> The mountall patches should be in a working condition now, btw. The bug i noticed the last time you were around was the last one i’ve been able to find so far.
[13:46] <ion> Please describe the feature. :-)
[13:49] <Keybuk> because of the blocking behaviour of event operators
[13:49] <Keybuk> you can use events as checkpoints
[13:49] <Keybuk> for example
[13:49] <Keybuk> starting a GNOME session
[13:50] <Keybuk> place "initctl emit gnome-session-start" in the /etc/gdm/PreSession/Default script
[13:50] <Keybuk> you now have an event for gdm starting a gnome session
[13:50] <Keybuk> all well and good
[13:50] <Keybuk> but let's say you want to defer some boot operation until the gnome session has started
[13:50] <Keybuk>   start on gnome-session-start
[13:51] <Keybuk> pretty obvious really
[13:51] <Keybuk> but now let's say you not only want to defer the boot operation, but you don't want the gnome-session to start unless it's been done
[13:51] <Keybuk> turns out to be the exact same command ;)
[13:51] <ion> Neat :-)
[13:51] <Keybuk> what about something which could happen earlier, but must happen before session start ?
[13:52] <Keybuk>   start on filesystem or (filesystem and gnome-session-start)
[13:52] <Keybuk> if g-s-s happens before filesystem, g-s-s will *block*
[13:52] <Keybuk> as soon as filesystem happens, either way, the start condition becomes true
[13:52] <Keybuk> if filesystem beats g-s-s, g-s-s never blocks
[13:53]  * Keybuk likes this
[13:55] <Keybuk> need to reboot, brb
[13:57] <Keybuk> oh, and I forgot
[13:57] <Keybuk> say you need gnome-session-start to block if a service is still running:
[13:57] <Keybuk> just put a job file with nothing else in it except
[13:57] <Keybuk>   start on stopped mountall and gnome-session-start
[13:57] <Keybuk>   task
[13:58] <Keybuk> now gdm will wait for mountall to complete before starting the login session
[13:59] <ion> Nice
[14:11] <Keybuk> ion: am still trying to think of how to handle remote mounts in mountall
[14:11] <Keybuk> almost tempted to say that mountall should simply exit when all it has left are remote mounts
[14:11] <Keybuk> and re-run mountall on ifup
[14:11] <Keybuk> e.g. mountall --network or something
[14:12] <Keybuk> if mountall is already running, that could prod it
[14:14] <ion> How is that different than leaving it running and using USR1? I mean, of course it’s *different*, but what does that achieve better?
[14:17] <Keybuk> no different, was just wondering about whether or not it was a good idea
[14:19] <ion> It seems to me it would be simpler to leave it running and trigger (re)mounts from an external message, be it signal or something else.
[14:20] <ion> If mountall --network has to prod a previous instance if one exists, you have to implement that *anyway*. Might as well only use it that way.
[14:28] <Keybuk> yeah
[14:28] <Keybuk> just thinking about the fact that you may end up with mountall always running
[14:28] <Keybuk> because you have some insignificant network mount that never mounts
[14:28] <Keybuk> but I guess that's ok too
[14:30] <ion> That’s not too bad IMO.
[14:30] <ion> If you want to get rid of the mountall process, simply get rid of the fstab entry that never mounts. :-)
[14:56] <Keybuk> I think that remote mounts are going to have to be allowed to fail
[14:56] <Keybuk> since it may need a different network interface
[14:57] <ion> Indeed
[14:57] <Keybuk> which means if you have /usr on NFS, and it fails to mount, you'll have a hung boot
[14:57] <ion> Until the correct interface comes up and mountall retries?
[14:57] <Keybuk> well, it could be that, for example, the remote machine isn't up
[14:58] <Keybuk> I think this is solveable though with the progress functionalith
[14:58] <Keybuk> e.g. usplash comes up because we're still waiting
[14:58] <ion> Yeah
[14:58] <Keybuk> and we put a message there saying what FHS-critical filesystems we're still waiting for
[15:01] <ion> Would something like this look okay? (No test cases or anything else yet.) http://heh.fi/patches/libnih-abort-msg
[15:01] <sadmac2> Keybuk: I thought you ditched usplash in favor of $fooshiny
[15:04] <ion> (http://launchpadlibrarian.net/31650305/glib2.0_2.21.6-0ubuntu1_2.21.6-0ubuntu2.diff.gz)
[15:05] <Keybuk> sadmac2: no
[15:06] <sadmac2> Keybuk: hmm. where'd I read that then...
[15:06] <Keybuk> ion: ooh, you patched that <g>
[15:07] <Keybuk> ion: what's the abort_msg_parent thing for?
[15:07] <Keybuk> ion: isn't it possible to do this in nih_assert() itself?
[15:08] <ion> I could drop the parent, and e.g. nih_strdup the message and put that to __abort_msg. Whichever’s better.
[15:09] <Keybuk> dunno
[15:09] <ion> nih_assert is just a macro that does nih_log_message and abort. It leaves the printf processing to nih_log_message, so i pretty much have to set __abort_msg in nih_log_message, unless the whole thing is modified a lot.
[15:10] <Keybuk> yeah, I guess it does tend to offload everything to nih_log_message
[15:11] <ion> I could move the parent inside nih_log_message, of course. http://heh.fi/patches/libnih-abort-msg
[15:11] <sadmac2> ion: the first conditional in that parent looks unnecessary
[15:11] <sadmac2> s/parent/patch
[15:12] <sadmac2> ion: you assign the variable to NULL and then check for NULL
[15:12] <Keybuk> ion: why does it need a parent at all?
[15:13] <ion> Ok, using strdup now. http://heh.fi/patches/libnih-abort-msg
[15:14] <ion> Whoops, forgot the parent parameter to nih_strdup.
[15:16] <Keybuk> I guess one easier thing to do would be to add another log level
[15:16] <Keybuk> NIH_LOG_ASSERT
[15:16] <Keybuk> above NIH_LOG_FATAL
[15:16] <Keybuk> and call abort() inside nih_log_message, after setting __abort_msg ?
[15:16] <Keybuk> maybe that's too convoluted to save a strdup though ;)
[15:17] <ion> :-)
[15:17] <Keybuk> but could you open a bug with that patch on libnih for me?
[15:17]  * sadmac2 reminds himself to add backtracing to libnih
[15:18] <ion> Will do
[15:19] <Keybuk> sadmac2: the confusion is exactly what xsplash is
[15:20] <Keybuk> xsplash is basically just a splash screen that sits between X loading, the gdm login screen and the user's desktop
[15:20] <Keybuk> X-gdm login because gdm takes seconds to start its login screen
[15:20] <Keybuk> gdm login-user's desktop because GNOME is shit
[15:20] <Keybuk> (X-user's desktop in the case of auto-login)
[15:20] <Keybuk> we're also starting X very early comparatively, so it's worthwhile having the longer splash screen
[15:21] <Keybuk> in fact, I'm using those event tricks I was talking about here
[15:21] <Keybuk> so xsplash appears, then there's an Upstart event
[15:21] <Keybuk> that Upstart event is used to "finish up" things that we need started before GDM or the user's desktop
[15:21] <Keybuk> without them needing to delay X
[15:23] <sadmac2> Keybuk: we just have fades between those points
[15:24] <Keybuk> fades between what and what though? :)
[15:24] <sadmac2> Keybuk: also your checkpointing thing scares me :(
[15:24] <Keybuk> you have plymouth from initramfs to X
[15:24] <Keybuk> fade into some kind of splash screen
[15:24] <Keybuk> fade into gdm
[15:24] <Keybuk> fade into some other kind of splash screen
[15:25] <Keybuk> fade into user's desktop
[15:25] <Keybuk> ?
[15:25] <sadmac2> plymouth onscreen, fade to gdm, fade to users desktop
[15:25] <Keybuk> so what's on screen after you've logged into gdm?
[15:25] <ion> https://bugs.edge.launchpad.net/libnih/+bug/429411
[15:26] <sadmac2> Keybuk: gdm
[15:26] <Keybuk> you press enter at the password prompt, what stays on screen until the user's desktop?
[15:26] <sadmac2> Keybuk: it stays visible
[15:26] <sadmac2> Keybuk: I think gdm goes to a waiting-to-log-you-in thing before quitting, so it should be that
[15:26]  * sadmac2 would know if he rebooted more often
[15:26] <Keybuk> right
[15:26] <Keybuk> that stuff isn't upstream
[15:27] <Keybuk> likewise, you've never contributed the X patches upstream that allow plymouth to stay on screen while gdm starts ;)
[15:27] <sadmac2> Keybuk: ...should be...
[15:27] <ion> sadmac: Btw, the code was { static foo *bar = NULL; if (! bar) bar = baz (); }. Thus bar is kept between function calls and only initialized once.
[15:27]  * soren notes that there's no ubottu or anything in here.. Is that intentional?
[15:27] <sadmac2> Keybuk: wat?
[15:27] <Keybuk> (though iirc, plymouth looks completely frozen while gdm starts because obviously it can't animated once X takes over the framebuffer)
[15:27] <sadmac2> Keybuk: plymouth always stops in a state where that makes snese
[15:27] <Keybuk> soren: this isn't an Ubuntu channel
[15:28] <soren> Keybuk: Indeed. Nevertheless, the lp bug resolution magic is really convenient :)
[15:28] <sadmac2> Keybuk: our X server should be totally upstream...
[15:29] <sadmac2> Keybuk: granted it may be 12 revisions ahead of the released branch....]
[15:29] <Keybuk> sadmac2: it isn't
[15:29] <Keybuk> you have about 200 patches which aren't upstream
[15:31] <sadmac2> Keybuk: you should beat on airlied at LPC then :)
[15:31] <sadmac2> ajax is probably more appropriate, but beating on him is a health hazard
[15:32] <Keybuk> it doesn't overly bother me :)
[15:32] <Keybuk> I like knowing projects that Fedora has special patches for
[15:32] <Keybuk> so every time spatula starts on his "we contribute everything upstream" rant, I start sending him URLs
[15:32] <Keybuk> I know that the *reality* of developing a distro is that you have patches to glue things together that aren't really ready for sending upstream
[15:32] <Keybuk> or make assumptions that upstream won't accept
[15:33] <Keybuk> hell, even when you're upstream yourself, you know that the patch is ok for your distro because it assumes something but not ok for upstream
[15:34] <sadmac2> Keybuk: I don't know of any Fedora devs that aren't moreso upstream Xfolk, so yeah...
[15:35] <sadmac2> *Fedora X devs
[15:37] <ion> It *would* be kind of nice to use plymouth instead of usplash for the pre-X fsck messages, so there would be no need to maintain usplash. But i guess that has been considered and discarded.
[15:37] <Keybuk> no
[15:38] <Keybuk> if someone wanted to do the work to get Plymouth working in Ubuntu
[15:38] <Keybuk> then sure ;)
[15:38] <Keybuk> the reason we've stuck with usplash is that it works, and the cost of sticking is zero
[15:38] <sadmac2> Keybuk: I'm sure rstrode would be supportive.
[15:38] <Keybuk> whereas we don't know that Plymouth works, and it needs new themes written, and needs integrating (all those usplash_writes need replacing, etc.), so the cost of changing is high
[15:39] <Keybuk> I can't imagine that we'll forever stick with and maintain usplash
[15:39] <ion> It works FSVO works. It never has been able to use the correct resolution on any of my computers; the logo has always had wrong proportions. ;-)
[15:39] <sadmac2> Keybuk: don't forget the initrd hook
[15:39] <Keybuk> but right now, we don't have anybody who can do plymouth
[15:39] <Keybuk> ion: right, we briefly tested it and it didn't get something right like that on one machine
[15:39] <Keybuk> on another it didn't display graphics at all, just a text bar at the bottom
[15:40] <Keybuk> and on the third, it fell back to 16 colours or something
[15:40] <Keybuk> so of the three test machines, it failed on all three
[15:40] <sadmac2> Keybuk: the text bar thing will be an ongoing thing. plymouth uses KMS. KMS doesn't work everywhere.
[15:40] <ion> I mean, usplash fails to use the correct resolution here.
[15:40] <Keybuk> sadmac2: I've been *assured* that Plymouth works on non-KMS graphics cards
[15:40] <Keybuk> (graphically)
[15:40] <Keybuk> I think this is a lie
[15:40] <sadmac2> Keybuk: who assured you this?
[15:41] <sadmac2> Keybuk: it is a lie.
[15:41] <sadmac2> Keybuk: graphics are KMS-only
[15:41] <Keybuk> sadmac2: various people on http://www.netsplit.com/2009/09/02/making-a-splash/ comments
[15:41] <Keybuk> (may have to click "Older comments")
[15:41] <Keybuk> neo says:
[15:41] <Keybuk> September 2, 2009 at 12:18 pm  (Edit)
[15:41] <Keybuk> I am sorry but Usplash and Plymouth are very different. Plymouth can work on the non KMS case using frame-buffer.
[15:41] <Keybuk> ec.
[15:42] <sadmac2> Keybuk: well if it can, it can't do it in F11
[15:42] <Keybuk> I think that this person doesn't know what he's talking about
[15:43] <Keybuk> the whole point of KMS is that it provides a framebuffer
[15:43] <sadmac2> Keybuk: beware the words of people named for Matrix characters
[15:43] <Keybuk> in the non-KMS case, you *do not have a framebuffer*
[15:43] <Keybuk> (unless you use vesafb of course, in which case, hello sixteen colours glory)
[15:43] <sadmac2> Keybuk: fuck yeeeeeah!
[15:44] <sadmac2> Keybuk: regardless of where ubuntu goes you should really sit down with rstrode and talk about the whole splash thing. He's the only one I'd trust on Plymouth
[15:48] <Keybuk> there's no point me sitting down with him this year
[15:48] <Keybuk> I won't have any time until at least June ;)
[15:48] <Keybuk> probably not until 2011 in practice
[17:31] <Keybuk> sadmac2: why does the checkpointing thing scare you?
[19:08] <sadmac2> Keybuk: its making use of the internal state held by and, which is scary because there's no way to really observe it from userspace. Its using the syntax in a way that makes no sense given what the stanzas mean... its hackish.
[19:09] <Keybuk> the syntax makes it odd
[19:09] <Keybuk> but I don't think it's hackish
[19:09] <Keybuk> it's doing exactly what this stuff was *designed* to do
[19:09] <Keybuk> allow you, through their blocking behaviour, to use simple events to produce complex dependency and ordering behaviours
[19:09] <sadmac2> Keybuk: I was actually disappointed when I noticed triggers /didn't/ remove this behavior. Guess I'm glad now.
[19:11] <Keybuk> it's an emergent behaviour of the "before" stanza
[19:11] <Keybuk> ie.
[19:11] <Keybuk>   before foo and before bar
[19:11] <Keybuk> implies that foo and bar will both be delayed until *after* your service is run
[19:11] <Keybuk> even if before they were not
[19:14] <sadmac2> Keybuk: I got to the point yesterday where I had to replace event operator related stuff in parse_job, which got me thinking about replacing parse_job/nih_parse again
[19:15] <Keybuk> any particular reason?
[19:15] <sadmac2> I need to look at other L1 parsers. bison was good but not quite up to snuff for a grammar as out there as job definitions.
[23:05] <mbiebl> Keybuk: there is a funny typo in netbase's postinst
[23:06] <mbiebl> upstart-rc.d ;-)
[23:07] <Keybuk> heh
[23:07] <Keybuk> I do that quite a lot
[23:07] <Keybuk> and I try and install udevs on the installer
[23:07] <Keybuk> udev-udeb just kills me
[23:08] <ion> :-)
[23:09] <mbiebl> in the ubuntu-boot ppa, i.e.
[23:09] <Keybuk> already fixed