[10:20] Anyone around to awnser a quick question ? [10:22] hettar: just ask [10:23] I have a daemon that I start/stop using upstart (kubuntu) which when you stop it needs to turn of some hardware. However upstart seems to just kill it. [10:24] I have sig handlers etc, but they aren't getting called. [10:24] is there some special way of performing a clean exit when being managed by upstart ? [10:31] Or have I just made a spectaular screwup in my code :) [10:37] hettar: Well, does it work if you send SIGKILL manually to your process? [10:39] yeah [10:39] If I do it all from old style init.d scripts it works fine. [10:41] hettar: best ask Keybuk [10:42] k thanks. [10:43] I'm currently adding some logging messages so I can see what is happing abit better. Hopefully that will give some clues too. [14:11] Keybuk: are you seriously interested in how to get your Git branch to a remote host or is this just a little bit of ranting? [14:11] If the former, I can give one or two tips [14:11] how to do it [14:17] mbiebl: I know how to do it [14:17] my rant is that it takes 9 commands, including editing things inside the .git repo [14:20] ok ;-) [14:21] I only need three commands, but sure, it could be improved [14:22] it seems to depend how complex your repo is [15:28] Keybuk: rsync [17:25] Keybuk: question: why nih_config? why not just use bison? [17:27] a reasonable question [17:29] is it just something you haven't much looked at? I'd be willing to redo the upstart conf stuff as bison if you wanted to compare the two. [17:33] exactly [17:34] I'll give it a shot at some point during the week. [17:34] Keybuk: also I have a patch to libnih that makes NIH_MUST and NIH_ZERO return the values they succeed on, so you can do foo = NIH_MUST (bar()) instead of NIH_MUST (foo = bar()) [17:35] it uses that ({...}) gcc extension. [17:37] sadmac2: does bison nowadays generate code which compiles without warnings? [17:38] interesting [17:38] that'd be nice [17:38] mbiebl: I believe so... [17:39] My last experience with flex/bison is 3 or 4 year old [17:39] so... [17:39] Keybuk: I also have, in a similar vein, an NIH_MEM_MUST that does the spin-on-ENOMEM-fail-on-other-error pattern that has cropped up in a lot of places (seemingly since the new allocator went in) [17:40] there's one of those already [17:40] NIH_SHOULD I think :p [17:40] it's just in nih/error.h instead [17:40] Keybuk: I kept finding the same damn 8-line while loop to do it, so I macro'd it. [17:41] really? [17:41] can you find an example of that particular while loop? [17:41] I thought I got rid of them all ages ago [17:41] #define NIH_SHOULD(_e) \ [17:41] while (! (_e)) { \ [17:41] NihError *_nih_should_err; \ [17:41] \ [17:41] _nih_should_err = nih_error_get (); \ [17:41] if (_nih_should_err->number == ENOMEM) { \ [17:41] nih_free (_nih_should_err); \ [17:41] } else { \ [17:41] nih_error_raise_again (_nih_should_err); \ [17:41] break; \ [17:41] } \ [17:41] } [17:41] Keybuk: it was somewhere in event_operator.c I think [17:42] yep, that was the exact macro. [17:42] I did the version that returns a value. I'll put it where it goes. [17:44] that's kinda nice [17:44] e = NIH_MUST (nih_new (NULL, foo)); [17:44] rather than [17:44] NIH_MUST (e = nih_new (NULL, foo)); [17:44] e = NIH_SHOULD (some_call ()); [17:44] if (! e) { [17:45] /* any error except ENOMEM */ [17:45] } [17:45] yes [17:45] I'll fix it up and mail it in when I get home tonight. [19:35] Md: hi [19:35] so, what are your plans regarding udev, now that lenny is out [20:05] mbiebl: solve a few work-related issues and then start working again on udev/m-i-t/pppd. hopefully I should be ready in a couple of weeks [20:07] Md: please keep me posted on the progress [20:07] are you insterested in helping? [20:08] Have you decided about the /lib/udev/rules.d vs /etc/udev/rules.d issue? [20:08] I see no compelling reasons to diverge from upstream [20:09] Md: I'm asking, because it will probably take some time to migrate all dependend packages over to the new location. [20:09] The the sooner in the squeeze cycle, the better. [20:09] not a big deal, they will not break anyway [20:11] sure