#upstart 2007-02-01 <_ion> atool is handy. http://johan.kiviniemi.name/blag/2007/02/01/atool/ #upstart 2007-02-03 <Keybuk> gnargh, I hate UNIX sometimes <Keybuk> SIGCHLD isn't getting delivered :-/ <Keybuk> (gdb) p sigpending (&act.sa_mask) <Keybuk> $34 = 0 <Keybuk> (gdb) p sigismember (&act.sa_mask, 17) <Keybuk> $35 = 1 <Keybuk> is definitely pending <Keybuk> yet, when I remove the procmask, it doesn't turn up #upstart 2007-02-04 <Seveas> Keybuk, some stupid suggestions: if it's sent while masked, isn't it just ignored? Do you actually give it a chance to be delivered (eg not looping inside a sighandler)? <Keybuk> the point of masks is to block their delivery, not cause them to be ignored :) <Keybuk> I figured what it was; before setting the handler, I set it to SIG_DFL first just to make things sane <Keybuk> setting a signal to SIG_DFL means it gets handled in the kernel, so the process signal mask doesn't apply <Keybuk> solution: don't reset the signals when being restarted, and voila <Keybuk> signals are "reliable" in that they can be raised, and you will get them if you're listening <Keybuk> however you may just get one, not several, depending on the OS <theCore> I always start to think Unix system programming is hard when I see all the fancy abbrv. <theCore> 96 revision(s) pulled. <theCore> whoa, Keybuk, you seem to work hard <Keybuk> heh <Keybuk> there are scarier stats <theCore> bzr diff -r-96.. | diffstat <theCore> it seems most of your work is centred on test suites <Keybuk> -r 223 was 0.2.7 (edgy version), 179 in libnih <Keybuk> $ bzr diff -r ..223 | diffstat <Keybuk> 62 files changed, 19751 insertions(+) <Keybuk> $ bzr diff -r ..179 | diffstat <Keybuk> 63 files changed, 17881 insertions(+) <Keybuk> -- <Keybuk> vs. <Keybuk> $ bzr diff -r 223.. | diffstat <Keybuk> 80 files changed, 21029 insertions(+), 10311 deletions(-) <Keybuk> $ bzr diff -r 179.. | diffstat <Keybuk> 66 files changed, 20752 insertions(+), 8230 deletions(-) <Keybuk> a lot of it is test suite, yeah <Keybuk> and all the bugs I've found in the process <Keybuk> getting the code base sane so I can merge in the new stuff <theCore> just a question, does test driven programming worth the effort. It seems to be the norm at Canonical <theCore> effort. -> effort? <Keybuk> I'm not sure about test-*driven* programming, where you write the tests first, then the code second <Keybuk> I've found it *very* useful for complex algorithms <Keybuk> but find it gets in the way of straight forward bone-playing <Keybuk> I'm certainly a great fan of *tested* programming <theCore> I was thinking writing a test-suite for my small project, a easy-to-use iptables front-end. <theCore> but, I don't think it will be necessary <theCore> the whole is < 1000 lines, without any fancy algorithm <Keybuk> you should still try and have it tested though <Keybuk> I've found all manner of silly bugs in the simplest of functions by testing it <Keybuk> e.g. "initctl shutdown" tried to send message 1 to the pid of the UPSTART_SHUTDOWN enum entry <theCore> hmm, right. In fact, it could be a good learning experience <theCore> after all, I will probably end-up as a software engineer, so I will to learn how to test my code sooner-or-later <theCore> will need* <theCore> hehe, you're a Lord of the Ring fan? <Keybuk> heh, all the frodo/bilbo references? <theCore> yeah <Keybuk> they're just common english metasyntactic variables <Keybuk> foo/bar/baz/frodo/bilbo/drogo/wibble/wobble/etc. <Keybuk> but yes, also I do like LotR <theCore> also, you got some pretty neat macro in nih/test.h <Keybuk> originally I didn't have any, and the upstart tests were all just written by hand, even down to printf ("Testing some_function()\n"); <Keybuk> I grew them into those macros simply to make it easier <Keybuk> TEST_ALLOC_FAIL is my new favourite; it loops over the enclosed code, counts how many times malloc is called, and then runs the code again causing each one to fail in turn -- so you can test the side-effects of -ENOMEM :p <theCore> yes, I was looking at this one <theCore> TEST_CHILD is neat too <Keybuk> that reminds me, I have a fix for TEST_CHILD to turn it into one statement :p <theCore> hehe <theCore> I always been a bit scared by C's macros, since I saw #define MAX(A, B) (A > B ? A : B) <Keybuk> that's a tricky one, because it evaluates both A and B twice <theCore> yep <Keybuk> so MAX(a++, b++) will expand to (a++ > b++ ? a++ : b++) <theCore> exactly <theCore> the pleasure of side-effects <Keybuk> so if a was 3 and b was 4, then you'd get 5 as the value, and a would be 4 and b 6 <Keybuk> there's a gccish way of writing that <Keybuk> but it only works if you know the types <Keybuk> e.g. <theCore> #define MIN(A,B) ((A) < (B) ? : (A) : (B)) <Keybuk> #define maxsize_t(a,b) ({size_t _a = (a), _b = (b); _a > _b ? _a : _b; }) <theCore> oh, #define MIN(A,B) (A <? B) <Keybuk> I've never heard of "<?" <theCore> I just learned it <theCore> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Min-and-Max.html <Keybuk> those are C++ extensions only, no? <theCore> I don't know <Keybuk> the only note I can find in the gcc 4.1 manual is <Keybuk> The G++ minimum and maximum operators (`<?' and `>?') and their <Keybuk> compound forms (`<?=') and `>?=') have been deprecated and will be <Keybuk> removed in a future version. Code using these operators should be <Keybuk> modified to use `st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abmin' and `st33ec:265c:71fe:e26d:2682:4ec2:aaa1:99abmax' instead. <theCore> that makes sense <theCore> C++ STL is way more powerful than C's preprocessor <Keybuk> I don't really like C++ <Keybuk> if they wanted to make a new language, they should have unbolted it from C <Keybuk> instead they ended up with a hideous half-breed <Keybuk> both Java and C# are far more elegant <theCore> well, it depends of your point of view <Keybuk> the principal thing about C++ that I hate is that it still has header files <theCore> but, I agree that Java and C# are more elegant <Keybuk> which artificially separates your class structure and code <Keybuk> AND by inference, exposes your private information to anyone reading them <Keybuk> they should have dropped the pre-processor, and made cpp files self contained units that could be referenced <theCore> I agree, but I don't think we will ever see a such change in C++ <Keybuk> indeed <Keybuk> which is a shame <Keybuk> the obvious bogosity is "#define private public" <theCore> haha <theCore> oh? <theCore> gcc has improved <theCore> the MAX macro works <_paulfm> hi everyone <_paulfm> Is anyone home? :-) <_paulfm> I am looking for some upstart help... I have just built it on Debian etch (testing) <_paulfm> I am hesitant to do a make install.... Im worried I may hose the init system <_paulfm> If I reconfigure and build.. with the /opt/upstart prefix <_paulfm> how do I start djennings@example.org... so my upstart tests get run... but I leave the "regular" init in place <_paulfm> hmmm... nobody home <dns_server> is anyone around that can help me write a script? <popey> moo <popey> hmm - wrong channel :) <AlexExtreme> lol <Keybuk> cows are welcome here <Seveas> cows make good meat <Keybuk> they do indeed <_paulfm> hellooo...doe anyone here use upstart on debian #upstart 2007-02-05 <dns_server> could someone help me write some scripts? <Keybuk> what type of scripts? <dns_server> i'd like to get smbfs mounted when a network comes up <dns_server> do you know where i can find some good examples of scripts etc? <Keybuk> what type of scripts? <dns_server> just anything <Keybuk> I'm sorry, but I still don't understand your question; could you be more specific <dns_server> what i want is to mount smbfs (fuse mount that shows all computers) automatically when a network interface comes up. <dns_server> i'm not shure what networking events get started and there are not too many examples to look at <Keybuk> what distribution are you using? <dns_server> ubuntu feisty and it would be good if it also worked on edgy if that is possible <dns_server> where do i find what network events are sent? so my script can respond to them <dns_server> ie what events can my script respond to? <dns_server> there is not a huge ammount of documentation from what i can see <crimeboy> can i put upstart in the dapper? <Keybuk> wasabi: hey, how goes it? <wasabi> pretty good <wasabi> trying to learn enough C to fix this vmware module he <Keybuk> heh <Keybuk> I've discovered that management is both more fun, more challenging and more time consuming then I previously imagined <wasabi> Uh huh. You usually end up not being able to work on what you like. <wasabi> Unless you like management. ;0 <wasabi> That's been my experience anyways. <Keybuk> I've certainly had to let go of a lot of stuff, yeah <Keybuk> including all the bug triage, handling, fixing, etc. <Keybuk> can't say I'm sorry to see that go :p <wasabi> At least it pays better? :) <Keybuk> well, yes #upstart 2007-02-06 * Keybuk taps his fingers * ..[topic/#upstart:Keybuk] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://www.netsplit.com/blog/articles/2006/12/14/upstart-0-3 | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://lca2007.linux.org.au/talk/102 <AlexExtreme> wahey <AlexExtreme> 0.3.2 <Keybuk> I've actually been sitting on that one for a day or two <Keybuk> there was a length discussion about whether it needed a CVE or not <AlexExtreme> there was a security flaw? <Keybuk> ish <Keybuk> sudo ls -l /proc/*/fd/6 <AlexExtreme> hmm, can't try that right now. I'm without a linux install :/ <Keybuk> it leaked its inotify instance descriptor to other processes <AlexExtreme> ah <Keybuk> not serious; the worst you can do is remove the watch on the config directory <AlexExtreme> yeah <AlexExtreme> so, I'll soon be able to start writing new job files for frugalware? <Keybuk> yup <AlexExtreme> great <Keybuk> am merging in and programming the specs now #upstart 2007-02-07 <Keybuk> so, the one thing I do hate about gcov ... <Keybuk> "Merge mismatch for summaries" <mbiebl> Keybuk: hi <mbiebl> tested the latest 0.3.2 version <Keybuk> did it work? <mbiebl> 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. <mbiebl> yeah, without problems. <Keybuk> right, rename and delete still aren't fully implemented <mbiebl> But besides from that, it's running fine. <mbiebl> I'll prepare a new Debian release soon. <mbiebl> I think your rigid test-case based developing pays off. <mbiebl> I used initng for a while and it often crashed and left an unbootable system. <mbiebl> Never had that with upstart. <mbiebl> So, thumbs up ;-) <mbiebl> btw, how was lca? <mbiebl> So your talk via video stream <mbiebl> s/so/saw/ <Keybuk> it seems to have been pretty useful, yeah <Keybuk> I'm finding it really handy at the moment, as I'm modifying large amounts of code <Keybuk> yet can be sure that I'm not unexpectedly changing behaviours I wasn't aware of <Keybuk> just unexpectedly changing behaviours I hadn't tested <g> <Keybuk> LCA was pretty cool actually <Keybuk> is by far my favourite geek conference <mbiebl> Yeah, the programme sounded really interesting, many very interesting people and projects. <Keybuk> it usually is <Keybuk> already thinking up my paper for Melbourne next year <mbiebl> what topic? <Keybuk> dunno yet <mbiebl> btw. have you ever been on linuxtag (germany)? <_ion> Congrats for the new release. :-) <Keybuk> I've never made it to LinuxTag, no <Keybuk> nor FOSDEM <mbiebl> What a pity. I'm sure you'd have liked it too. Many geeks all over the place ;-) <_ion> Obviously the best possible place to have such conferences in would be Tampere, Finland. <Keybuk> yeah, it's one of the ones I keep missing <Keybuk> too many conferences in a year ;p <mbiebl> _ion: sounds cold ;-) <Keybuk> Helsinki was nice <_ion> About 30C currently. :-) <mbiebl> argh... <mbiebl> winter is currently running crazy here in Germany (+10C) <mbiebl> I blame it on the global warming effect ;-) <Keybuk> it's colder here (-7C) <mbiebl> Keybuk: have you already started work on converting sysv style init scripts to upstart jobs? <Keybuk> yes, most of the initscripts package <mbiebl> Have you started with the core system (rcS) or with the multisession part (e.g. hal, dbus etc)? <Keybuk> core system and dbus <Keybuk> mostly because dbus is special and benefits from it <mbiebl> So, will the packages itself directly ship the upstart job files or do you keep them inside the the upstart package? <Keybuk> pretty much the same style as sysvinit <Keybuk> upstart ships system-services and startup-tasks packages <Keybuk> the former is basically what sysvinit ships in inittab <Keybuk> and the latter is basically the old initscripts package <Keybuk> other packages then ship upstart jobs <Keybuk> e.g. dbus ships its own <mbiebl> Let's take postfix as an example. <mbiebl> Have you replaced the sysv init script with a upstart job, or do you ship both files? <Keybuk> postfix I haven't touched <Keybuk> if I were, I'd ship just the upstart job <Keybuk> shipping both is bad, since upstart has the sysv compat stuff :) <mbiebl> The reason, why I ask, is that for Debian I'll probably have to go for the second option. <mbiebl> So people can switch between sysvinit and upstart. <mbiebl> And I thought about diverting update-rc.d/invoke-rc.d for that reason. <Keybuk> shipping both gives you the problem that you couldn't ship upstart-compat-sysv <Keybuk> otherwise upstart would start postfix both natively *and* via sysv-rc <mbiebl> Yeah, that's why I thought about diverting update-rc.d <Keybuk> right <Keybuk> that'd work <Keybuk> you'd have to have a magic update-rc.d that "decided" whether the package also shipped an upstart config file <mbiebl> Yeah, exactly. <mbiebl> In Ubuntu it will be a bit more easy. <Keybuk> yeah :) <mbiebl> But for Debian I figured this would be the only way to provide a smooth conversion path. <_ion> Make a sysvrc compatibility layer for upstart jobs! <_ion> ;-) <Keybuk> _ion: that's called "upstart" <_ion> Hehe, yeah. <mbiebl> Anyways, I'm off to bed now. <Keybuk> g'nite <mbiebl> As soon as I have a clearer view how to implement this for Debian, I'll probably pester you again, Keybuk <Keybuk> sure <mbiebl> n8 and cu <Keybuk> oh, heh, some debugging code ended up in 0.3.2 by accident <Keybuk> init: main: attach gdb to 1 now <Keybuk> init: main: too late <Keybuk> sweeeeeet <Keybuk> test-stop: test failed main <Keybuk> (stop) <Keybuk> EXIT_STATUS = 1 <Keybuk> (from the following job: <Keybuk> start on stop test <Keybuk> script <Keybuk> echo "$UPSTART_JOB: $@" <Keybuk> echo "($UPSTART_EVENT)" <Keybuk> echo "EXIT_STATUS = $EXIT_STATUS" <Keybuk> end script <_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 <Keybuk> tricky one, innit <geo1> anyone home? <Keybuk> mmm, refactoring <Keybuk> today I'm trying to get the event-completion stuff finished <_ion> "f*** with networking" <Keybuk> hmm? :p <_ion> Perhaps an expletive would be an appropriate 'FOO' ;-) <Keybuk> rofl * Keybuk just got that * Keybuk takes a decision on state serialisation <_ion> A decision? <Keybuk> yes <Keybuk> it's kinda broken in the face of event-completion and job-serialisation <Keybuk> and has needed a rewrite for a while anyway <Keybuk> (it uses a pipe and a text dump of the linked lists) <Keybuk> since we have a stable IPC protocol, I don't want to close the control socket on restart anymore <Keybuk> which means we can use that to serialise the state <Keybuk> (much better tested code, much more efficient) <Keybuk> and with the rewrite, I can fix the inherent problems with it (dumping linked lists isn't the right way) <Keybuk> this won't be compatible with the code from older versions <Keybuk> however, since those aren't tracking anything except the pid of getty ... <Keybuk> ... I've decided to ignore that <_ion> All right. <Keybuk> 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 <Keybuk> they'll all appear to be stopped <AlexExtreme> 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? <Keybuk> righ <Keybuk> t <Keybuk> that's what I'm thinking <Keybuk> the problem is minor, and can be knowledged-based with "restart your computer" <AlexExtreme> yes <AlexExtreme> 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 <Keybuk> right <Keybuk> initially for feisty, upgrades won't restart upstart <Keybuk> but that's ok, because the IPC protocol is stablish now <Keybuk> and by the time feisty releases, I'll have replaced the restart code <AlexExtreme> ok <Keybuk> icky <Keybuk> job->goal_event->event.name <_ion> Heh. <Keybuk> (where job->goal_event is the EventEmission structure referencing the event currently being handled that caused the job's goal to change ... <Keybuk> ... I can't think of a better variable name) <wasabi> As an aside, perhaps the ability for an upstart job to reassociate with an already running pid might be interesting? <wasabi> Actually, shouldn't it? <wasabi> Why would it not know the existing pids? <Keybuk> why would it know them? <Keybuk> exec() has a way of killing all the memory <wasabi> well, thought that stuff would have been serialized to disk on a restart. <Keybuk> serialised somewhere, certainly <Keybuk> I Hate Valgrind <Keybuk> it blatantly ignores its "don't follow children" option <baze> hi <Keybuk> baze: hi <Keybuk> welcome <baze> is upstart already usable for distros other than ubuntu? or will it ever, and is there a rough ETA? <baze> i'm using arch here, which uses bsd init scripts... not sure if upstart can handle those <Keybuk> upstart shipped with Ubuntu 6.10, with a set of jobs that emulate the behaviour of sysvinit <Keybuk> this should be quite portable to other distributions <Keybuk> as all you need do is modify the same set of jobs to match /etc/inittab on that distribution <Keybuk> we've had people do it for Fedora, Gentoo, Frugalware, etc. already <baze> so it should be possible already to use it in other distros? <Keybuk> that gets you up and running pretty fast <Keybuk> yes, absolutely <baze> cool :) <baze> i should give it a try <Keybuk> the current release is suitable for deployment maintaining compatibility with the existing init scripts <Keybuk> the next major release of upstart is suitable for deployment *replacing* the existing init scripts <baze> but emulating the sysvinit stuff is not really the goal of course ;) <Keybuk> right <baze> so if i get it running, i should get all the fancy new stuff from upstart too, right? <Keybuk> but it was a fantastic way to test the daemon <Keybuk> shake all the bugs out <Keybuk> and figure out what we needed <baze> right <Keybuk> yup, you get the new stuff as well <baze> neat <AlexExtreme> hmm <AlexExtreme> let's try 0.3.2 <baze> 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.. <Keybuk> baze: upstart doesn't try and implement that <Keybuk> we cheat, and just run the /etc/init.d/rc shellscript that comes with sysvinit <Keybuk> arch should have an equivalent shell script that iterates /etc/rc.d <Keybuk> so just run that :) <AlexExtreme> arch doesn't <Keybuk> you'd probably not need runlevel, telinit, etc. <Keybuk> and could get away with a simple single job <baze> AlexExtreme is right, there is no such file in /etc/rc.d <AlexExtreme> heh <baze> do you use arch too or why did you know that? <AlexExtreme> no <AlexExtreme> I use Frugalware <baze> others tried upstart with arch? <baze> ah <baze> is there a frugalware package for upstart? <baze> couldn't find one with the package search <AlexExtreme> 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 <AlexExtreme> brb, just gonna test 0.3.2 <baze> fw uses the same init system as arch does, right? <AlexExtreme> baze, no <AlexExtreme> the only thing we (did) share was pacman <baze> ok <baze> i don't really know anything about fw besides the pacman stuff, as you see ;) <AlexExtreme> 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 :) <AlexExtreme> </rant> <AlexExtreme> and 0.3.2 seems to work great <AlexExtreme> Keybuk, would you mind adding Frugalware to the packages section on the upstart website? <baze> so fw uses init.d and rc2.d and so on? <AlexExtreme> not init.d <AlexExtreme> /etc/rc.d/rc(whatever).d <AlexExtreme> the init scripts are in /etc/rc.d <baze> ok <AlexExtreme> with names like rc.dbus, rc.hald, and so on <baze> i see <baze> well, that's pretty much like arch then <baze> except the naming is different, if i understand it just a little bit correct ;) <AlexExtreme> I wouldn't have thought so <AlexExtreme> arch simply sticks the scripts in a dir and you configure the ones you want in rc.conf <baze> yep <baze> well anyway, could i have a look at your PKGBUILD? maybe that helps me a bit <AlexExtreme> *FrugalBuild :) <baze> gna ;p <baze> idc :p <baze> frugalbuild then <AlexExtreme> http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/upstart/FrugalBuild <baze> thanks <AlexExtreme> it depends on sysvutils which is here: http://ftp.frugalware.org/pub/other/people/alex/upstart-mess/source/base/sysvutils/FrugalBuild <AlexExtreme> that's only for the sysv compat stuff though <AlexExtreme> once the system is upstart-ized sysvutils won't be needed <AlexExtreme> gotta go <AlexExtreme> bye <baze> bye <Keybuk> AlexExtreme: wouldn't mind at all, give me a link :) #upstart 2007-02-08 <Keybuk> X really doesn't like ioctl()s on its file descriptor <Keybuk> wing-commander scott# cat /etc/event.d/test <Keybuk> on wibble <Keybuk> script <Keybuk> exit 1 <Keybuk> end script <Keybuk> wing-commander scott# initctl emit wibble <Keybuk> wibble <Keybuk> test (start) waiting <Keybuk> test (start) starting <Keybuk> test (start) running, process 8155 <Keybuk> initctl: wibble event failed <Keybuk> zsh: exit 1 initctl emit wibble <Keybuk> -- <Keybuk> sweeeet <Keybuk> wow, my laptop booted this morning *impressed* <_ion> Ooh <Keybuk> I'm finishing up merging the new state machine today <_ion> Cool <Keybuk> of course, I need to fix shutdown first <Keybuk> yay, fixed that <Keybuk> Committed revision 500 <Keybuk> woo <_ion> \o/ <Keybuk> wing-commander scott# cat /etc/event.d/test <Keybuk> start on wibble <Keybuk> script <Keybuk> sleep 5 <Keybuk> exit 1 <Keybuk> end script <Keybuk> wing-commander scott# initctl emit wibble <Keybuk> wibble <Keybuk> test (start) waiting <Keybuk> test (start) starting <Keybuk> test (start) running, process 2941 <Keybuk> test (stop) running <Keybuk> test (stop) stopping <Keybuk> initctl: wibble event failed <Keybuk> zsh: exit 1 initctl emit wibble <Keybuk> yay <_ion> Whee <AlexExtreme> Keybuk, great job with the new features :) you asked for the link to the frugalware upstart repository, it's at http://ftp.frugalware.org/pub/other/people/alex/upstart <AlexExtreme> also if you want an icon for it like debian and ubuntu have there, just use the favicon here: http://frugalware.org/ <Keybuk> ok, cool; thanks <Keybuk> AlexExtreme: ok, linked <AlexExtreme> thanks :) <_ion> keybuk: Today's proposition for 'FOO': 'goal', as in 'goal frodo until bilbo', 'goal with multiuser', 'goal network-up until network-down and fhs-mounted until fhs-unmounted' <Keybuk> heh <Keybuk> well <Keybuk> there goes the first of the old state machine ... <Keybuk> 505 changed the enums <mbiebl> Keybuk: do you have a BNF of the job file format (or a detailed spec)? <mbiebl> I wanted to write a syntax file for vim over the weekend. <mbiebl> So you get nice syntax highlighting on editing upstart job files ;-) <Keybuk> I actually don't <Keybuk> feel free to write one based on the config code <Keybuk> let me quickly define it for you <Keybuk> it's a line-based format; newlines end a stanza <Keybuk> Comments begin with '#' and run up to the next newline <Keybuk> whitespace chars are space, tab, \r and \n if inside quotes <Keybuk> newlines inside single or double quotes are ignored <Keybuk> s/ignored/treated as whitespace/ sorry <Keybuk> a slash may be used to cause a single or double quote to be treated as a plain character <Keybuk> and a slash may also be used to treat a newline as a whitespace character <Keybuk> so that's the basic format <Keybuk> an argument is a token of characters up until the first comment, whitespace or newline character that's not quoted <Keybuk> examples <Keybuk> foo <Keybuk> bar <Keybuk> "foo bar" <Keybuk> foo\ bar <Keybuk> foo\ <Keybuk> bar <Keybuk> (last two lines is one arg) <Keybuk> "foo <Keybuk> bar" <Keybuk> (likewise) <Keybuk> foo#foo bar <Keybuk> (the token there is foo) <Keybuk> a command is a token of characters up until the first comment or newline <Keybuk> whitespace is part of the command <Keybuk> commands are parsed according to shell rules (i.e. by running "sh -c $COMMAND" ) <Keybuk> the only other special thing is a block <Keybuk> that begins on the line after the stanza, and is ended up the phrase "WS? end WS BLOCKTYPE WS? COMMENT? NL" <Keybuk> see init/cfgfile.c for the list of stanzas, and how each one parses what follows <Keybuk> next_arg eats one argument <Keybuk> skip_comment eats a comment and the following newline <Keybuk> parse_args eats all arguments to the end of the line <Keybuk> parse_command eats the following command <Keybuk> some stanzas are more complex than others, expecting second-level words <mbiebl> Ok, thanks for the pointers. <mbiebl> It will be a bit hard to detect a upstart job file, because it doesn't have a special file extension or shebang. <Keybuk> they live in /etc/event.d :p <Keybuk> easy <mbiebl> Yeah, this is the metric I use already ;-) <Keybuk> I don't like "extensions" <Keybuk> you end up with something silly like ".job" <Keybuk> or <Keybuk> /etc/udev/rules.d/foo.rules <Keybuk> (or, worse) <Keybuk> /etc/udev/rules.d/foo-udev.rules <Md> Keybuk: did you add a regexp to ignore dot files, rpm/dpkg/emacs/vi backup files, etc? #upstart 2007-02-09 <Keybuk> yeah, it has that <mbiebl> Keybuk: I've been toying around a bit with r502 <mbiebl> And with minor updates to the job files it works fine. <mbiebl> I was just wondering, why the job files have all these "stop on shutdown|runlevel-x" stanzas <mbiebl> For scripts, stop is never really called, right? <Keybuk> well <Keybuk> because they're rc scripts <Keybuk> and sysv was never designed with running the rc6 (reboot) script while starting into rc2 <Keybuk> I have that so if you press Ctrl-Alt-Del while booting, it stops booting, and switches into reboot <Keybuk> which is roughly compatible <Keybuk> oh <Keybuk> you'll want the new job files <Keybuk> heh <mbiebl> well, i used the old ones compat job files and adapted them. <Keybuk> http://upstart.ubuntu.com/new-example-jobs/ <Keybuk> the main differences are <Keybuk> 1) "runlevel" is now a single event, with an argument specifying the new runlevel <Keybuk> 2) "shutdown" is no more <Keybuk> so things now just "stop on runlevel" (ie. kill the running rc script if the runlevel changes) <mbiebl> Cool, I'll try these ones. <Keybuk> they work for me <Keybuk> which isn't to say much <Keybuk> I found a pretty nasty error with logd in the process though <Keybuk> which is why they're console output for now <_ion> pe011840 < Keybuk> I don't like "extensions" <_ion> Amen to that. <Keybuk> ok <Keybuk> well <Keybuk> that's job_change_state () rewritten <Keybuk> which could be happily described as the most core function <Keybuk> it actually got a *lot* simpler <Keybuk> which I think is encouraging <_ion> Nice. <Keybuk> of course, none of it *compiles* yet :p <_ion> Naaah, having it compile isn't as important as they say. :-) <Keybuk> it's annoying that the tests don't compile either <Keybuk> so I'm not sure if the changes I'm making to them are right :p <Keybuk> lots of things had assumptions about the state model <_ion> Have you already implemented it as a lookup table (i think you mentioned something like that earlier), or are the state decisions still plain code? <Keybuk> plain code <Keybuk> much more efficient <int0x0c> What is the status of Upstart on Gentoo? <int0x0c> Has there been any effort to write a backend for it? <Keybuk> it shouldn't need a "backend" ? <_ion> He probably means a compatibility layer. <int0x0c> _ion, yep, thanks <int0x0c> wrong terminology <Keybuk> there's been a few efforts to write jobs that emulate the existing Gentoo init system <Keybuk> I haven't actually seen any completed ones yet though <int0x0c> hmm <int0x0c> alright <Keybuk> _ion: do you remember who was doing them? <_ion> Sorry, nope. <_ion> 2006-12-15 19:52:46 < steev64> as much as people are going to hate me for it (not necessarily *in here*), I am trying to get up <_ion> start working on Gentoo <Keybuk> Sep 13 22:28:06 <rubengonc> i am trying it on gentoo <Keybuk> Oct 04 17:12:15 <smlgb1> Hi there. Did anybody of you try to install upstart on gentoo yet? <Keybuk> we should get these people together :p <_ion> 2006-10-27 23:31:21 < phsdv> hi all, I just managed to get my gentoo system booted using upstart. * ..[topic/#upstart:Keybuk] : Upstart 0.3.2 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo <Keybuk> http://upstart.ubuntu.com/wiki/UpstartOnGentoo <Keybuk> :p <_ion> :-) <int0x0c> I might try my hand this weekend at getting upstart going * Keybuk embarks on updating the job_change_state() test suite ... ouch <Keybuk> http://upstart.ubuntu.com/wiki/JobStates?action=AttachFile&do=get&target=states.png <Keybuk> I am *so* glad I did that ^ <_ion> :-) <Keybuk> though I've added to it since then <Keybuk> mbiebl: re <mbiebl> Keybuk: yes? <Keybuk> just hi <mbiebl> ah, thanks ;-) <mbiebl> About Md's question: <mbiebl> Seems as if in r502, dpkg-(old|new) files are not ignored. <Keybuk> uh, maybe I didn't push that yet <Keybuk> does nih/file.c have a nih_file_is_packaging ? <mbiebl> nope <Keybuk> ah <Keybuk> woo, she compiles again! <Keybuk> whee <Keybuk> I wasn't hallucinating last night; the test cases *do* pass <phsdv> congrats! <Keybuk> am trying to decide whether to continue to allow "respawn COMMAND" as a shortcut for both "exec COMMAND" and "respawn" <Md> yes. syntactical sugar is nice :-) <Keybuk> well, moment of truth * Keybuk starts it <Keybuk> http://rafb.net/p/s2LD5c17.html <Keybuk> sweeeeeeet; ^ new job life cycle <Keybuk> note that the "test" job doesn't get to start until "test2" finishes, because test2 is marked "start on starting test" <Keybuk> http://rafb.net/p/HtgNXP55.html <Keybuk> ^ example of a job that needs another running <Keybuk> note how hal is started once dbus is running, but that when dbus is stopped, hal actually gets stopped first and dbus isn't stopped until hal is <Keybuk> http://rafb.net/p/eGZbr976.html <Keybuk> ^ and there's a counter-example of the opposite behaviour <Keybuk> tomcat is able to indicate that "apache needs it", so when you try and start apache, you get tomcat started *first* <giuseppe_> hi, i'm building a smal linux distro for learning purpose, and i was searching for something dealing with dependencies between daemons. I see upstart has removed this feature (https://launchpad.net/upstart/+spec/remove-depends). Does anyone has suggestions? are there init implementations dealing with dependencies? <Keybuk> for what reason do you want dependencies? <Keybuk> there are (currently) four basic classes of init daemon, which all handle the problem differently: <Keybuk> 1) those that run scripts in order, so the order expresses "what must come first" <Keybuk> e.g. sysvinit <giuseppe_> Keybuk: because i don't want to hardcode init scripts. I'm listening btw <Keybuk> 2) those that run everything at once, and expect the jobs to sort themselves out <Keybuk> e.g. launchd <Keybuk> 3) those that use a package-manager style dependency chain, when you start a daemon anything it "depends" on is started first (and likewise, when you stop a daemon, it's dependencies aren't stopped until afterwards) <Keybuk> e.g. Solaris SMF, init-NG <Keybuk> 4) those that use events; when you start or stop a daemon, it issues events; other daemons can be started or stopped by those events; and block the other <Keybuk> e.g. upstart <Keybuk> I assume that #1 is what you're already familar with, and #2 isn't useful <giuseppe_> ok so basically you're telling me to read the upstart doc better :) <Keybuk> the upstart docs aren't that good :p <Keybuk> (yet) <Keybuk> my two usual examples are dbus/hal and apache/tomcat <Keybuk> hal needs dbus to be running while it is, if dbus is stopped, hal must be too <Keybuk> tomcat is needed by apache if installed, so apache is started, tomcat must be started first (and tomcat must not be stopped until apache is) <giuseppe_> ok this is not possible with simple dependencies then.. you have to use events <giuseppe_> from what i understand <Keybuk> in a dependency-based system you might try something like <Keybuk> hal depends dbus <Keybuk> and hal is a goal <Keybuk> so when you start hal, dbus is started first <Keybuk> the second one is more tricky in a dependency-based system because you don't want to edit the apache job description just because tomcat is installed <Keybuk> so you actually need something like <Keybuk> tomcat is-dependency-of apache <Keybuk> and apache is a goal <Keybuk> (the first being in the tomcat description) <giuseppe_> ok very clear <giuseppe_> thanks Keybuk <Keybuk> don't know whether initNG supports that <Keybuk> I know SMF doesn't <Keybuk> in a event-based system, like upstart, you instead hook the events generated by hal, dbus, apache, tomcat, etc. <Keybuk> so you might use something like <Keybuk> hal: start on starting dbus <Keybuk> err <Keybuk> sorry <Keybuk> hal: start on started dbus <Keybuk> hal: stop on stopping dbus <Keybuk> and for the tomcat case, it's easy <Keybuk> tomcat: start on starting apache <Keybuk> tomcat: stop on stopped apache <Keybuk> http://rafb.net/p/HtgNXP55.html <Keybuk> http://rafb.net/p/eGZbr976.html <Keybuk> (those two URLs given an example of both of those) <giuseppe_> Keybuk: thank you very much i'm going to read <Keybuk> in theory, the event-based system requires less manual or semi-automatic configuration <Keybuk> you can ship job definitions that do the right thing <Keybuk> and you don't need to modify other jobs or goals when you install a new daemon * Keybuk makes yet another tweak to the state diagram <giuseppe_> hi, i'm having troubles compiling upstart with gcc 3.3.5, is it a known issue? <giuseppe_> child.c: In function `nih_child_poll': <giuseppe_> child.c:141: error: `WEXITED' undeclared (first use in this function) <AlexExtreme> yes <AlexExtreme> upstart only compiles with 4.x afai <AlexExtreme> *afaik <giuseppe_> :| <Keybuk> that's more likely an out of date libc <AlexExtreme> ah <Keybuk> upstart needs both kernel and libc support for the waitid() system call <AlexExtreme> yeah <giuseppe_> i'm using debian's 2.3.2.ds1-22 <giuseppe_> is there a particular libc version waitid() is available from? <Keybuk> 2.4 seems fine <Keybuk> there's a Debian package already <Keybuk> http://packages.debian.org/experimental/admin/upstart <giuseppe_> yep even 2.3.6 is ok <Keybuk> though it's a little out of date; if you have those build-deps, you should be fine <int0x0c> Have the upstart service files for the base ubuntu installation been developed yet (i.e. not the initrd wrapper) <Keybuk> int0x0c: they'll be available by monday <int0x0c> heh, wow, I picked quite a time to ask <AlexExtreme> woohoo :) <int0x0c> Are they in bzr at the moment? <giuseppe_> Keybuk: yes the problem is i'm trying to maintain a cross toolchain.. :| <AlexExtreme> Keybuk, let me know when/where I can get them when they are released, I can't wait to try it :) <Keybuk> no; I have a bunch of them on my laptop, but they're a bit broken because I'm busy rewriting upstart :p <Keybuk> and keep changing things <giuseppe_> Keybuk: i'm using this libc config: http://rafb.net/p/Kv1hho71.html, do you see problems with it? it is relative to glibc 2.3.6 <int0x0c> What is the bzr branch? <Keybuk> int0x0c: for? <int0x0c> the service files <Keybuk> giuseppe_: I don't really know libc compiles; I would imagine it's fine <Keybuk> int0x0c: there isn't one just yet <Keybuk> I'll get them published this weekend :) <int0x0c> bah, alright <int0x0c> thanks a ton <Keybuk> (I could publish them now, but they wouldn't work for you :p) <Keybuk> http://upstart.ubuntu.com/states.png <Keybuk> ^ now, isn't *that* neater <AlexExtreme> nice <AlexExtreme> don't you just love dot ;) <int0x0c> Keybuk, I'm running gentoo <int0x0c> Keybuk, and looking into writing a set of services <int0x0c> Keybuk, I just need something for reference <int0x0c> If you had a sec, I would love a tarball <int0x0c> but don't worry about it if not <AlexExtreme> as he said, they won't work right now :) <Keybuk> I understand that :) these just literally aren't ready right now <Keybuk> they're not even useful for reference <int0x0c> ahh, alright <int0x0c> fair enough <Keybuk> interesting; excluding tests, upstart 0.2.7 was 9,204 lines of code <Keybuk> since then (also excluding tests) <Keybuk> 36 files changed, 6899 insertions(+), 4654 deletions(-) <Keybuk> so I've changed roughly 50% of the code <Keybuk> that's kinda cool <AlexExtreme> yeah <Keybuk> test suites rock for this kind of mass-scale refactoring <Keybuk> a more odd stat ... <Keybuk> 0.3.5 has 11,360 lines of code ... but only 2,835 semi-colons <AlexExtreme> hah <AlexExtreme> I wish I could code as fast as this >< <Keybuk> the usual metric is 2.5 logical lines to a semi-colon <AlexExtreme> so for feisty do you reckon only the base services will be converted to upstart jobs for feisty's final release, seeing as feature freeze has started (it has, hasn't it?) ? <Keybuk> which makes upstart about 35% comments <AlexExtreme> hmm, just realised I said "for feisty" twice. ignore that :p <Keybuk> that's the plan <Keybuk> always has been, actually <AlexExtreme> mmm, k <Keybuk> most daemons will retain sysv init scripts for feisty <Keybuk> except the interesting ones <AlexExtreme> like dbus? <Keybuk> right <Keybuk> ok, that's config file deletion support pushed * Keybuk looks at his TODO list for what's next <Keybuk> I guess I should run valgrind over the new core :p <AlexExtreme> :P <Keybuk> shouldn't be any problems, since I didn't much around with memory stuff <Keybuk> all good <_ion> So you made "deleted" a state. That's good. <Keybuk> yeah, it made the most sense <Keybuk> it's the most trivial way of handling all the cases <Keybuk> - means it can't be started again, since it's not in the waiting state <Keybuk> - means that all deleted jobs can be quickly found and freed <Keybuk> - means that clients know that it's being deleted <Keybuk> etc. <_ion> Indeed. <Keybuk> it even means the clients can detect when they tried to start a deleted job :p <Keybuk> start "foo" <Keybuk> foo (stop) deleted <Keybuk> bloody ISP #upstart 2007-02-10 <_ion> 27C outside. \o/ <Keybuk> Feb 10 13:49:23 wing-commander init: /etc/event.d/4913: unable to read: Invalid argument <Keybuk> grr @ vim <_ion> :-\ <Keybuk> it really does write a file called 4913 into the current directory when you modify something <Keybuk> go figure <_ion> Perhaps the directory watching code should do something like "wait one second after things have stopped changing" <_ion> and then react <_ion> That should take care of any evil things editors might do with temporary files. <_ion> The very same feature would be useful in the future when "file/directory changing" can be used as triggers for upstart jobs. <_ion> I.e. "watch directory /foo, do this when things have changed and there have been no more changes for 15 seconds" <Keybuk> yeah, will have to think how to smooth that kind of thing out <Keybuk> 15s is a long time though <_ion> That was just an example of an arbitrary number a user might choose. <_ion> Not something we'd want for watching /etc :-) <_ion> /etc/event.d even <Keybuk> it's vaguely useful in many cases <_ion> A use case: i define a job that watches www-dir/apt-repo-incoming, and when one *minute* has passed from changes, it copies things to www-dir/apt-repo and runs falcon. I might want this because i manually copy things to it, and want to have up to a minute of time between copying individual files until the thing is actually triggered. <Keybuk> some editors just modify the file directly <Keybuk> some copy the file to a backup and modify the file itself <_ion> Yeah. <Keybuk> some write a temporary file, and move it over the previous file <Keybuk> at some point, I need to rethink the way process ids are stored in the Job <Keybuk> right now there's just job->pid and job->aux_pid <Keybuk> I'm temped to move the pid to underneath the process definition <Keybuk> job->process->pid, job->pre_start->pid, job->post_start->pid, etc. <Keybuk> and then I could enum those <Keybuk> job->process[PROCESS_PRE_START] ->pid <Keybuk> and then we can add arbitrary actions <Keybuk> id = job_action_id (job, "reload"); <Keybuk> job->process[id] ->pid <Keybuk> actually, I just found another reason to do that <Keybuk> then job->failed_state could actually be the *process* that failed :p <Keybuk> http://rafb.net/p/fOPZlY98.html <Keybuk> ^ \o/ <Keybuk> so, here's a poser <Keybuk> when you change a job's configuration file, should it <Keybuk> a) modify the configuration of the running job <Keybuk> b) mark the running job to be deleted when it stops, and use the new configuration for any new instances started later <Md> is implementing a actually possible? <Keybuk> a is what is currently implemented <Keybuk> but I'm increasingly thinking it's wrong <Keybuk> it works for debugging, "a quick edit to fix the job" <Keybuk> but I think in practice b is better, because changes to the job file are likely to be upgrades <Keybuk> and you might end up with a post-stop script that wasn't intended for the running process, since it doesn't match what pre-start did at the time <Keybuk> silly things, like what if the upgrade changed the pid file location? <Keybuk> or the run directory location <Keybuk> that's an issue we have todya <Keybuk> would be nice to fix it <_ion> b sounds good. <theCore> a) seems scary to me. <theCore> it seems to beg for race-conditions <Keybuk> yeah, like a pre-start script being run; the config file getting read; and a different process all together getting run afterwards <Md> Keybuk: yes, I agree that b would be better <AlexExtreme> Keybuk, just found an upstart bug - if you hit ctrl+alt+del multiple times, it will try to shut down multiple times <Keybuk> right, yes? <AlexExtreme> well, that shouldn't really happen, should it? <Keybuk> dunno <Keybuk> change "stop on runlevel" to "stop on runlevel [^6] " <Keybuk> :p <AlexExtreme> :p <mbiebl> Keybuk: I got a small problem with current svn <mbiebl> Seems as if kill -s TERM 1 in postinst <mbiebl> causes upstart to run sulogin (which kills my keyboard on X) <Keybuk> yes <Keybuk> it does that <Keybuk> normally it kills the entire X server <Keybuk> * WARNING: if you have any job declared "console owner" which is <Keybuk> run by the "stalled" event, comment out the "start on" stanza <Keybuk> before sending the TERM signal -- otherwise the newly started <Keybuk> process will start that job, which will kill your running X <Keybuk> server. <mbiebl> Hm, it didn't do that with <=0.3.2 <mbiebl> Is that a recent change? <Keybuk> yes <Keybuk> it's a "lack of a feature" <Keybuk> I disabled the stuff that serialised the state between upstart instances, because it was a mess and hard to maintain <Keybuk> I plan to put it back sometime in the couple of releases <mbiebl> ok <wasabi_> hey, quicky casper question since I know ya'll know a lot about it. ;) <wasabi_> Trying to copy the feisty boot CD to a USB drive, to install on a system without a CD. <wasabi_> filesystem.squashfs is what casper needs to mount... the vmlinuz and initrd.gz are obvious. What option tells casper how to find filesystem.squashfs? <Keybuk> it hunts for it <Keybuk> it's in the casper-local initramfs script * wasabi_ installs casper! <wasabi_> would ideally just be an option to mount a certain efs2 partition with a static path. ... *hopes* <Keybuk> it might be <wasabi_> hopefully the initramfs does usb mass storage by default. =/ <Keybuk> it should <Keybuk> ./usr/share/initramfs-tools/scripts/casper <wasabi_> hmm LIVEMEDIA maybe <Keybuk> it might be fixed as /casper/*.squashfs <wasabi_> That'll be fine. I just have to be able to point it to /dev/sdb3 <wasabi_> And it has to wait for it to appear. <wasabi_> Or... /dev/sd something. <wasabi_> Actually I won't know. <Keybuk> it should just fine it <Keybuk> uh, find it <wasabi_> # or do the scan of block devices <Keybuk> it checks all block devices <wasabi_> bah. grub doesn't like this. prints GRUB and dies. <wasabi_> wonder how I fix that one. <wasabi_> ... how does grub find it's stage2 anyways? <wasabi_> well this is obnoxious. * ..[topic/#upstart:Keybuk] : Upstart 0.3.5 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo <wasabi_> Odd. So I've got it booted into the initrd... casper breaks... probably can't find the livefs. <wasabi_> Guess I can just mount it manually. <wasabi_> nope. blah. <wasabi_> i've got it at an initramfs prompt though. that's good enough. i'm going on a road trip and at least needed it that far. ;) <wasabi_> I can do the rest by hand in the car. #upstart 2007-02-11 <_ion> Does anyone know which tool Keybuk uses for keeping the ChangeLog file updated in bzr? <_ion> Phew. Today was one of the few days of a year when i actually manage to get some code done despite my health issues. I wrote http://soijabanaani.net/tmp/nih_watch_delayed.diff <_ion> Writing that took like ten times the time it would have taken if i could concentrate normally. <_ion> Here's also a small parenthesis fix, http://soijabanaani.net/tmp/nih_hash_foreach_parenthesis.diff <phsdv> int0x0c, are you trying to get upstart going on gentoo? <phsdv> I just uploaded an ebuild for 0.3.5 into gentoo bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=150190) <Keybuk> so, I came up with a neat idea ... <Keybuk> you know how we have emits ? <Keybuk> that'd be a really nice way of defining special events <Keybuk> job lists the event names with the emits stanza <Keybuk> and when started, sends a message to upstart saying that it wants active notification of registrations <Keybuk> upstart sees it's from a pid of a known job, that has listed emits stanzas <Keybuk> so sends the job back as a reply every use of "on THAT-EVENT" <Keybuk> and whenever new jobs are registered, or jobs are deleted, keeps that process up to date <Keybuk> e.g. <Keybuk> a job called "inetd" <Keybuk> emits tcp udp <Keybuk> connects to upstart <Keybuk> and receives information that there are jobs with <Keybuk> on tcp 80 <Keybuk> on udp 53 <Keybuk> etc. <Keybuk> so it knows to listen on those ports, and knows to emit events with those arguments <AlexExtreme> sounds good <AlexExtreme> so, there's most of the work for replacing inetd done? :P <Keybuk> it means you can take exotic events out of the core <Keybuk> don't want inetd support? don't run upstart-ientd <AlexExtreme> yes <Keybuk> useful for the dbus proxy too <Keybuk> on dbus com/redhat/dhcp/eth0 com.redhat.dhcp.down <Keybuk> so it'd know to listen to that signal, and emit that evnet <_ion> keybuk: Ooo, really nice idea. <_ion> keybuk: Any comments about the watch_delayed thing? <Keybuk> I looked at the code, and it looked pretty good <Keybuk> haven't had a chance to test it yet; want to get complex-event done today since we want that asap <_ion> All right. <Keybuk> will look at it properly this week : ) <_ion> You might want to include nih_hash_foreach_parenthesis.diff immediately though, it fixes a bug. :-) <Keybuk> yeah, I saw that <Keybuk> thanks! <Keybuk> can you paste me a changelog for that one <_ion> * nih/hash.c (NIH_HASH_FOREACH, NIH_HASH_FOREACH_SAFE): Added missing parenthesis. <_ion> Is that enough? :-) <_ion> Duh, nih/hash.h, not .c <_ion> What tool do you use to maintain the changelog and have it integrated with bzr commits, btw? <_ion> A bzr plugin? <Keybuk> a shell script <_ion> Is it available for downloading? :-) <Keybuk> http://people.ubuntu.com/~scott/software/bzr-commit <_ion> Thanks <Keybuk> I maintain the ChangeLog first using emacs (C-x 4 a) <Keybuk> and then just use that to do the commits, with the changelog diff <Keybuk> actually -- can you commit your watch delayed stuffa <Keybuk> and push it to a branch of your own? <Keybuk> something like <_ion> Actually i did commit it to a branch of my own in the first place, but decided just to send a diff because i hadn't written changelog entries or commit messages using the format you use in your repository. I'll do that now, using that script. :-) <Keybuk> bzr push sftp://djennings@example.org/~ion/libnih/watch-delayed <Keybuk> I think is the format <Keybuk> that should automatically register it on https://code.launchpad.net/libnih <_ion> keybuk: https://code.launchpad.net/~ion/+branch/libnih/watch-delayed <Keybuk> excellent <Keybuk> wing-commander scott% ./parse "foo bar baz until frodo bilbo and eep" <Keybuk> Operator (AND) <Keybuk> Event ("eep") <Keybuk> Operator (UNTIL) <Keybuk> Event ("frodo", "bilbo") <Keybuk> Event ("foo", "bar", "baz") <Keybuk> \o/ <Keybuk> now to figure out whether I've got the precedence right :p <_ion> \o/ <Keybuk> wing-commander scott% ./parse "foo until bar and frodo until bilbo" <Keybuk> Operator (AND) <Keybuk> Operator (UNTIL) <Keybuk> Event ("bilbo") <Keybuk> Event ("frodo") <Keybuk> Operator (UNTIL) <Keybuk> Event ("bar") <Keybuk> Event ("foo") <_ion> keybuk: You should be able to pull the nih/hash.h fix and nothing else by running bzr merge --pull -r 386 http://bazaar.launchpad.net/~ion/libnih/watch-delayed, i think. <_ion> The actual delayed watch code is in revno 387. <Keybuk> wing-commander scott% ./parse "set timer until (boom or kaboom)" <Keybuk> Operator (UNTIL) <Keybuk> Event ("set", "timer") <Keybuk> Operator (OR) <Keybuk> Event ("boom") <Keybuk> Event ("kaboom") <Keybuk> \o/ <_ion> \/ <AlexExtreme> :) <_ion> keybuk: Have you decided a name for the complex-event-spec stanza yet? :-) <Keybuk> wing-commander scott% ./parse "fhs-filesystem-mounted until fhs-filesystem-down and network-up until network-down" <Keybuk> Operator (AND) <Keybuk> Operator (UNTIL) <Keybuk> Event ("fhs-filesystem-mounted") <Keybuk> Event ("fhs-filesystem-down") <Keybuk> Operator (UNTIL) <Keybuk> Event ("network-up") <Keybuk> Event ("network-down") <Keybuk> _ion: nope <Keybuk> wing-commander scott% ./parse "with apache or with thttpd" <Keybuk> Operator (OR) <Keybuk> Operator (WITH) <Keybuk> Event ("apache")
{'channel': 'upstart', 'month': 2}