[04:22] <Keybuk> #6  0x0804b322 in test_source_reload () at tests/test_conf.c:288
[04:23] <Keybuk> 288             TEST_EQ_P (item->job, job);
[04:23] <Keybuk> (gdb) p job
[04:23] <Keybuk> $1 = (Job *) 0x0
[04:23] <Keybuk> (gdb) p item->job
[04:23] <Keybuk> $2 = (Job *) 0x806c8b0
[04:23] <Keybuk> (gdb) p item->job->name
[04:23] <Keybuk> $3 = 0x806c9c8 "tmp/test_conf.c-test_source_reload-213-12871/foo"
[04:23] <Keybuk> heh
[04:23] <Keybuk> oops
[04:23] <AlexExtreme> heh :p
[04:47] <Keybuk> hey Michael
[04:51] <mbiebl> Keybuk: hi
[04:56] <Keybuk> how goes it?
[04:58] <mbiebl> Fine, thanks.
[04:59] <mbiebl> How about you?
[04:59] <Keybuk> not so bad
[04:59] <Keybuk> making an attack on the new conf code today
[05:00] <mbiebl> Made a pull today and noticed that you were quite active the last couple of days ;-)
[05:00] <Keybuk> yeah, beware that the current code isn't actually working
[05:00] <Keybuk> ie. not finished
[05:03] <mbiebl> What's your aimed release date for 0.3.9?
[05:03] <Keybuk> no idea
[05:03] <Keybuk> soon
[05:03] <Keybuk> once the new conf code is working
[05:04] <mbiebl> Does that also involve a change in the directory layout?
[05:04] <Keybuk> maybe
[05:04] <Keybuk> if I carry that, I'll renumber it to 0.4
[05:05] <Keybuk> /etc/event.d will become /etc/init/jobs.d at some point
[05:05] <Keybuk> but I may hold off and just use the new code to do /etc/event.d for now
[05:05] <Keybuk> (or even sneakily support both)
[05:09] <mbiebl> I'm currently preparing for Debconf (will be flying there on saturday)
[05:09] <Keybuk> cool
[05:09] <Keybuk> Edinburgh is a very pretty city
[05:09] <mbiebl> Hopefully I'll be able to convice the fellow DDs, which are so keen on the meta-init-script format, that it's imho not such a great idea. 
[05:10] <Keybuk> meta-init-script?
[05:10] <mbiebl> There was some blogging and discussion a month ago about a meta-init-script format.
[05:11] <mbiebl> From which initscript for the existing init systems should be generated.
[05:13] <mbiebl> http://blog.incase.de/index.php/2007/04/17/init-script-generators/
[05:14] <mbiebl> I'm pretty sure, such a system will not work.
[05:14] <mbiebl> We would end up with something that would be even worse than we have today with sysvinit.
[05:14] <ion_> *shiver*
[05:15] <mbiebl> imo a initsystem is something important like the package format of a distro.
[05:16] <AlexExtreme> fedora came up with a similar idea on their mailing list, i don't know what happened to it though, but instead of having a script generator they would simply provide a script in packages for most init systems. ugh
[05:16] <mbiebl> That's a maintenance night mare.
[05:16] <AlexExtreme> yep
[05:16] <mbiebl> Even the metascript idea is not much better there, because the testing will be a nightmare.
[05:16] <AlexExtreme> that's exactly what i was thinking as i read the thread
[05:18] <Keybuk> Fedora are being odd
[05:18] <Keybuk> cblizzard's post seems to think that starting things when you need them is a revelation
[05:18] <mbiebl> And D-Bus all the way ;-)
[05:19] <Keybuk> dbus people still seem to think that system services are the way forward
[05:19] <Keybuk> "We have this great hammer ... I know this looks like a job for a screwdriver, but it works if we hit it hard enough with the hammer too!"
[05:20] <AlexExtreme> heh :)
[05:20] <ion_> Lets replace IRC with D-Bus.
[05:20] <mbiebl> I also think that this whole D-Bus system service activation is crazy.
[05:21] <mbiebl> Unfortunately the HAL guys are not much better in that respect.
[05:21] <mbiebl> As much as I value what HAL brought for the Linux desktop,
[05:22] <mbiebl> cramming everything into HAL, power management, disk formattting (shrug) etc, seems insane.
[05:22] <mbiebl> (at least to me)
[05:23] <Keybuk> they're not quite into HAL
[05:23] <Keybuk> they sit alongside it, exposing themselves as HAL methods
[05:23] <Keybuk> that makes some amount of sense
[05:23] <Keybuk> the alternative is something like network-manager, which is its own daemon, with own communication properties, etc.
[05:24] <Keybuk> using HAL for the communication actually makes it easier
[05:24] <Keybuk> network-manager could be a hal add-on that implements "change essid" type properties on network interfaces
[05:24] <Keybuk> which would make programming easier
[05:24] <Keybuk> the separation is about the same, since the communication is still dbus, and the daemon is still separate
[05:24] <Keybuk> you're just using a particular kind of dbus call (HAL methods)
[05:25] <mbiebl> Well, if you make NM a HAL addon, you also lose some good features:
[05:25] <mbiebl> The ability to start/stop it on its own.
[05:26] <mbiebl> separate logging
[05:26] <mbiebl> clear separation, so systems which don't use it, don't have to install it.
[05:27] <Keybuk> hal addons are seperate daemons, so they can be start/stop'd on their own, etc.
[05:28] <mbiebl> Really? Don't they have to be spawned from the hald process?
[05:29] <mbiebl> And the standard service management tools will not work with hal addons.
[05:30] <Keybuk> not sure whether they have to be or not
[05:30] <Keybuk> I think the communication is just dbus, so they don't need to be
[05:30] <Keybuk> ICBW
[05:31] <mbiebl> Doesn't matter. It's just me, rambling a bit ;-)
[05:40] <mbiebl> OT: Did you read this story: http://www.msnbc.msn.com/id/19088976?GT1=10056
[05:40] <mbiebl> I really had to smile
[05:42] <ion_> Hehe
[05:42] <AlexExtreme> heh
[05:47] <ion_> In case someone didnt notice this one, ill rudely spam it again. http://heh.fi/tmp/saukonpuisto-panorama
[05:51] <mbiebl> cool. would make a perfect wallpaper for a 4-monitor xinerama setup ;-)
[05:51] <mbiebl> bbl
[05:51] <AlexExtreme> nice
[05:58] <ion_> Do you make nautilus create a transparent background and compiz render the background?
[06:01] <Keybuk> yup
[06:01] <ion_> Thats great.
[06:02] <Keybuk> http://people.freedesktop.org/~racarr/nautilus.debdiff
[06:03] <Keybuk> you also need http://people.freedesktop.org/~racarr/libeel.debdiff
[06:03] <Keybuk> and the compcomm wallpaper plugin
[06:04] <ion_> Ive thought thats the way to go forever. A wallpaper image could be replaced with a nice non-distracting animation, on which the desktop stuff would be composited.
[06:27] <wasabi> hah cool racaar did it
[06:30] <Keybuk> yeah he did
[09:05] <Keybuk> urgh
[09:05] <Keybuk> messyness has ensued in the "job replacement" code :-/
[09:11] <theCore> is the cron-like functionality in Upstart got implemented yet? 
[09:14] <theCore> nevermind
[09:21] <Keybuk> not yet
[09:23] <theCore> Keybuk: yeah, I understood that, when I saw "Events generated at timed intervals or scheduled times" under planned features
[09:24] <theCore> on the front page of upstart website
[09:27] <Keybuk> *nods*
[10:02] <Keybuk> File 'conf.c'
[10:02] <Keybuk> Lines executed:71.04% of 221
[10:02] <Keybuk> conf.c:creating 'conf.c.gcov'
[10:02] <Keybuk> *sigh*
[10:02] <Keybuk> 29% to go
[10:03] <ion_> Heh
[10:23] <theCore> Keybuk: you're not the only one 
[10:24] <theCore> at least, testing pays off on the long run
[10:39] <Keybuk> truwe
[11:16] <Keybuk> ok, whew
[11:16] <Keybuk> the config code should now be roughly compatible with the old code again
[11:17] <Keybuk> (except that this new code is ready to support -HUP/initctl reload; and also has the necessary smarts to be modified to support job definitions in larger files and multiple overlapping sources of jobs)