=== mbiebl [n=michael@e180100135.adsl.alicedsl.de] has joined #upstart === j_ack [n=rudi@p508DAC51.dip0.t-ipconnect.de] has joined #upstart [01:22] so, the one thing I do hate about gcov ... [01:22] "Merge mismatch for summaries" [01:31] Keybuk: hi [01:31] tested the latest 0.3.2 version [01:31] did it work? [01:32] What I noticed is, that if I renamed a file in /etc/event.d/, initctl list still showed the old (and the new) job name. [01:32] yeah, without problems. === j_ack_ [n=rudi@p508DAC51.dip0.t-ipconnect.de] has joined #upstart [01:32] right, rename and delete still aren't fully implemented [01:33] But besides from that, it's running fine. [01:34] I'll prepare a new Debian release soon. [01:35] I think your rigid test-case based developing pays off. [01:35] I used initng for a while and it often crashed and left an unbootable system. [01:36] Never had that with upstart. [01:36] So, thumbs up ;-) [01:36] btw, how was lca? [01:36] So your talk via video stream [01:36] s/so/saw/ [01:38] it seems to have been pretty useful, yeah [01:38] I'm finding it really handy at the moment, as I'm modifying large amounts of code [01:38] yet can be sure that I'm not unexpectedly changing behaviours I wasn't aware of [01:39] just unexpectedly changing behaviours I hadn't tested [01:39] LCA was pretty cool actually [01:39] is by far my favourite geek conference [01:41] Yeah, the programme sounded really interesting, many very interesting people and projects. [01:49] it usually is [01:49] already thinking up my paper for Melbourne next year [01:49] what topic? [01:50] dunno yet [01:51] btw. have you ever been on linuxtag (germany)? [01:52] <_ion> Congrats for the new release. :-) [01:52] I've never made it to LinuxTag, no [01:54] nor FOSDEM [01:54] What a pity. I'm sure you'd have liked it too. Many geeks all over the place ;-) [01:54] <_ion> Obviously the best possible place to have such conferences in would be Tampere, Finland. [01:54] yeah, it's one of the ones I keep missing [01:55] too many conferences in a year ;p [01:55] _ion: sounds cold ;-) [01:56] Helsinki was nice [01:56] <_ion> About 30C currently. :-) [01:56] argh... [01:58] winter is currently running crazy here in Germany (+10C) [01:58] I blame it on the global warming effect ;-) [01:59] it's colder here (-7C) [02:02] Keybuk: have you already started work on converting sysv style init scripts to upstart jobs? [02:02] yes, most of the initscripts package [02:03] Have you started with the core system (rcS) or with the multisession part (e.g. hal, dbus etc)? [02:03] core system and dbus [02:03] mostly because dbus is special and benefits from it [02:04] So, will the packages itself directly ship the upstart job files or do you keep them inside the the upstart package? [02:05] pretty much the same style as sysvinit [02:05] upstart ships system-services and startup-tasks packages [02:05] the former is basically what sysvinit ships in inittab [02:05] and the latter is basically the old initscripts package [02:06] other packages then ship upstart jobs [02:06] e.g. dbus ships its own [02:06] Let's take postfix as an example. [02:06] Have you replaced the sysv init script with a upstart job, or do you ship both files? [02:07] postfix I haven't touched [02:07] if I were, I'd ship just the upstart job [02:08] shipping both is bad, since upstart has the sysv compat stuff :) [02:08] The reason, why I ask, is that for Debian I'll probably have to go for the second option. [02:08] So people can switch between sysvinit and upstart. [02:09] And I thought about diverting update-rc.d/invoke-rc.d for that reason. [02:09] shipping both gives you the problem that you couldn't ship upstart-compat-sysv [02:10] otherwise upstart would start postfix both natively *and* via sysv-rc [02:10] Yeah, that's why I thought about diverting update-rc.d [02:10] right [02:10] that'd work [02:11] you'd have to have a magic update-rc.d that "decided" whether the package also shipped an upstart config file [02:11] Yeah, exactly. [02:12] In Ubuntu it will be a bit more easy. [02:13] yeah :) [02:13] But for Debian I figured this would be the only way to provide a smooth conversion path. [02:13] <_ion> Make a sysvrc compatibility layer for upstart jobs! [02:13] <_ion> ;-) [02:14] _ion: that's called "upstart" [02:14] <_ion> Hehe, yeah. [02:17] Anyways, I'm off to bed now. [02:17] g'nite [02:17] As soon as I have a clearer view how to implement this for Debian, I'll probably pester you again, Keybuk [02:17] sure [02:17] n8 and cu [02:24] oh, heh, some debugging code ended up in 0.3.2 by accident [02:24] init: main: attach gdb to 1 now [02:24] init: main: too late [02:32] sweeeeeet [02:32] test-stop: test failed main [02:32] (stop) [02:32] EXIT_STATUS = 1 [02:32] (from the following job: [02:32] start on stop test [02:32] script [02:32] echo "$UPSTART_JOB: $@" [02:33] echo "($UPSTART_EVENT)" [02:33] echo "EXIT_STATUS = $EXIT_STATUS" [02:33] end script [02:34] <_ion> Some more or less bad ideas for the 'FOO' in 'FOO frodo until bilbo', 'FOO with networking' etc: act, react, work, operate, reflect, respond, go, do, serve, comply, subscribe, yield, pursue, follow, obey [02:38] tricky one, innit === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === j_ack [n=rudi@p508DAC51.dip0.t-ipconnect.de] has joined #upstart === geo1 [n=geo@m198-218.dsl.rawbw.com] has joined #upstart [06:26] anyone home? === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart [01:20] mmm, refactoring [01:59] today I'm trying to get the event-completion stuff finished [02:00] <_ion> "f*** with networking" [02:00] hmm? :p [02:01] <_ion> Perhaps an expletive would be an appropriate 'FOO' ;-) [02:01] rofl === Keybuk just got that === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === Keybuk takes a decision on state serialisation [05:44] <_ion> A decision? [05:44] yes [05:44] it's kinda broken in the face of event-completion and job-serialisation [05:44] and has needed a rewrite for a while anyway [05:44] (it uses a pipe and a text dump of the linked lists) [05:45] since we have a stable IPC protocol, I don't want to close the control socket on restart anymore [05:45] which means we can use that to serialise the state [05:45] (much better tested code, much more efficient) [05:46] and with the rewrite, I can fix the inherent problems with it (dumping linked lists isn't the right way) [05:46] this won't be compatible with the code from older versions [05:46] however, since those aren't tracking anything except the pid of getty ... [05:46] ... I've decided to ignore that [05:46] <_ion> All right. [05:47] the apparent bug will be that after updating upstart from current versions to 0.3.5, the state of any registered jobs won't be known [05:47] they'll all appear to be stopped [05:50] that wouldn't be that much of a problem, would it? the only problem it would cause on an upgrade from edgy to feisty (when it's released) would be that gettys wouldn't be stopped when you restart, no? [05:51] righ [05:51] t [05:51] that's what I'm thinking [05:51] the problem is minor, and can be knowledged-based with "restart your computer" [05:51] yes [05:52] and since on a edgy to feisty upgrade, you'll be prompted to reboot anyway for the kernel being upgraded, most people would hardly notice it === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart [05:54] right [05:54] initially for feisty, upgrades won't restart upstart [05:54] but that's ok, because the IPC protocol is stablish now [05:55] and by the time feisty releases, I'll have replaced the restart code [05:55] ok === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart [06:41] icky [06:41] job->goal_event->event.name [06:42] <_ion> Heh. [06:45] (where job->goal_event is the EventEmission structure referencing the event currently being handled that caused the job's goal to change ... [06:45] ... I can't think of a better variable name) [06:50] As an aside, perhaps the ability for an upstart job to reassociate with an already running pid might be interesting? [06:51] Actually, shouldn't it? [06:51] Why would it not know the existing pids? === Md [i=md@freenode/staff/md] has joined #upstart [06:59] why would it know them? [06:59] exec() has a way of killing all the memory [07:10] well, thought that stuff would have been serialized to disk on a restart. [07:18] serialised somewhere, certainly [08:28] I Hate Valgrind === baze [n=baze@d067119.adsl.hansenet.de] has joined #upstart [09:35] it blatantly ignores its "don't follow children" option [09:37] hi [09:37] baze: hi [09:37] welcome [09:38] is upstart already usable for distros other than ubuntu? or will it ever, and is there a rough ETA? [09:38] i'm using arch here, which uses bsd init scripts... not sure if upstart can handle those [09:38] upstart shipped with Ubuntu 6.10, with a set of jobs that emulate the behaviour of sysvinit [09:38] this should be quite portable to other distributions [09:38] as all you need do is modify the same set of jobs to match /etc/inittab on that distribution [09:39] we've had people do it for Fedora, Gentoo, Frugalware, etc. already [09:39] so it should be possible already to use it in other distros? [09:39] that gets you up and running pretty fast [09:39] yes, absolutely [09:39] cool :) [09:39] i should give it a try [09:40] the current release is suitable for deployment maintaining compatibility with the existing init scripts [09:40] the next major release of upstart is suitable for deployment *replacing* the existing init scripts [09:40] but emulating the sysvinit stuff is not really the goal of course ;) [09:40] right [09:40] so if i get it running, i should get all the fancy new stuff from upstart too, right? [09:40] but it was a fantastic way to test the daemon [09:40] shake all the bugs out [09:40] and figure out what we needed [09:41] right [09:41] yup, you get the new stuff as well [09:41] neat [09:54] hmm [09:54] let's try 0.3.2 [09:54] hm, arch doesn't use /etc/rcn.d/ and that stuff but only /etc/rc.d with no use of different setups for different runlevels.. [09:56] baze: upstart doesn't try and implement that [09:56] we cheat, and just run the /etc/init.d/rc shellscript that comes with sysvinit [09:57] arch should have an equivalent shell script that iterates /etc/rc.d [09:57] so just run that :) [09:57] arch doesn't [09:57] you'd probably not need runlevel, telinit, etc. [09:57] and could get away with a simple single job [09:59] AlexExtreme is right, there is no such file in /etc/rc.d [10:00] heh [10:01] do you use arch too or why did you know that? [10:01] no [10:01] I use Frugalware [10:01] others tried upstart with arch? [10:01] ah [10:01] is there a frugalware package for upstart? [10:02] couldn't find one with the package search [10:02] no, there isn't. I'm maintaining it in a seperate repo for the moment, but by 0.7 it will be the default init system [10:03] brb, just gonna test 0.3.2 [10:03] fw uses the same init system as arch does, right? [10:04] baze, no [10:05] the only thing we (did) share was pacman [10:05] ok [10:05] i don't really know anything about fw besides the pacman stuff, as you see ;) [10:06] and since now we forked pacman because we got sick of the way that pacman was being developed (i.e. remove as many features that aren't completely necessary as possible, and telling us that our patches "aren't valid" without saying why), we share absolutely nothing :) [10:06] [10:07] and 0.3.2 seems to work great [10:10] Keybuk, would you mind adding Frugalware to the packages section on the upstart website? [10:13] so fw uses init.d and rc2.d and so on? [10:14] not init.d [10:14] /etc/rc.d/rc(whatever).d [10:14] the init scripts are in /etc/rc.d [10:14] ok [10:14] with names like rc.dbus, rc.hald, and so on [10:14] i see [10:14] well, that's pretty much like arch then [10:15] except the naming is different, if i understand it just a little bit correct ;) [10:15] I wouldn't have thought so [10:15] arch simply sticks the scripts in a dir and you configure the ones you want in rc.conf [10:15] yep [10:17] well anyway, could i have a look at your PKGBUILD? maybe that helps me a bit [10:17] *FrugalBuild :) [10:17] gna ;p [10:18] idc :p [10:18] frugalbuild then [10:18] http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/upstart/FrugalBuild [10:18] thanks [10:18] it depends on sysvutils which is here: http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/sysvutils/FrugalBuild [10:18] that's only for the sysv compat stuff though [10:18] once the system is upstart-ized sysvutils won't be needed [10:20] gotta go [10:21] bye [10:24] bye [10:37] AlexExtreme: wouldn't mind at all, give me a link :)