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