| === h\h is now known as haraldh | ||
| 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:43 |
| ion | :-) | 13:44 |
| 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:45 |
| ion | Please describe the feature. :-) | 13:46 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| * Keybuk likes this | 13:53 | |
| Keybuk | need to reboot, brb | 13:55 |
| 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:57 |
| Keybuk | now gdm will wait for mountall to complete before starting the login session | 13:58 |
| ion | Nice | 13:59 |
| 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:11 |
| Keybuk | if mountall is already running, that could prod it | 14:12 |
| 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:14 |
| Keybuk | no different, was just wondering about whether or not it was a good idea | 14:17 |
| 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:19 |
| 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:20 |
| 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:28 |
| 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:30 |
| 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:56 |
| 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:57 |
| 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 | 14:58 |
| 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:01 |
| ion | (http://launchpadlibrarian.net/31650305/glib2.0_2.21.6-0ubuntu1_2.21.6-0ubuntu2.diff.gz) | 15:04 |
| Keybuk | sadmac2: no | 15:05 |
| sadmac2 | Keybuk: hmm. where'd I read that then... | 15:06 |
| Keybuk | ion: ooh, you patched that <g> | 15:06 |
| 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:07 |
| ion | I could drop the parent, and e.g. nih_strdup the message and put that to __abort_msg. Whichever’s better. | 15:08 |
| 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:09 |
| Keybuk | yeah, I guess it does tend to offload everything to nih_log_message | 15:10 |
| 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:11 |
| 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:12 |
| ion | Ok, using strdup now. http://heh.fi/patches/libnih-abort-msg | 15:13 |
| ion | Whoops, forgot the parent parameter to nih_strdup. | 15:14 |
| 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:16 |
| 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:17 | |
| ion | Will do | 15:18 |
| Keybuk | sadmac2: the confusion is exactly what xsplash is | 15:19 |
| 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:20 |
| 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:21 |
| sadmac2 | Keybuk: we just have fades between those points | 15:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| soren | Keybuk: Indeed. Nevertheless, the lp bug resolution magic is really convenient :) | 15:28 |
| sadmac2 | Keybuk: our X server should be totally upstream... | 15:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| sadmac2 | Keybuk: I don't know of any Fedora devs that aren't moreso upstream Xfolk, so yeah... | 15:34 |
| sadmac2 | *Fedora X devs | 15:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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 | 15:48 |
| Keybuk | sadmac2: why does the checkpointing thing scare you? | 17:31 |
| === robbiew1 is now known as robbiew | ||
| 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:08 |
| 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:09 |
| 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:11 |
| 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:14 |
| 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. | 19:15 |
| === robbiew is now known as robbiew-akf | ||
| === robbiew-akf is now known as robbiew-afk | ||
| === robbiew-afk is now known as robbiew | ||
| mbiebl | Keybuk: there is a funny typo in netbase's postinst | 23:05 |
| mbiebl | upstart-rc.d ;-) | 23:06 |
| 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:07 |
| ion | :-) | 23:08 |
| mbiebl | in the ubuntu-boot ppa, i.e. | 23:09 |
| Keybuk | already fixed | 23:09 |
| === robbiew is now known as robbiew-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!