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