=== j_ack [n=rudi@p508DA63E.dip0.t-ipconnect.de] has joined #upstart === j_ack [n=rudi@p508DA63E.dip0.t-ipconnect.de] has joined #upstart === j_ack [n=rudi@p508DA63E.dip0.t-ipconnect.de] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === pkt [n=pantelis@athedsl-131388.otenet.gr] has joined #upstart === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === wasabi__ [n=wasabi@cpe-76-184-96-5.tx.res.rr.com] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === shawarma [n=sh@atlas.linux2go.dk] has joined #upstart === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart === _ion [i=johan@kiviniemi.name] has joined #upstart === jonibo [n=jonas@213.212.2.215] has joined #upstart === popey [n=alan@ubuntu/member/popey] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === pkt [n=pantelis@athedsl-131388.otenet.gr] has joined #upstart === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === wasabi__ [n=wasabi@cpe-76-184-96-5.tx.res.rr.com] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === shawarma [n=sh@atlas.linux2go.dk] has joined #upstart === Artanicus [i=kuitunej@lehtori.cc.tut.fi] has joined #upstart === _ion [i=johan@kiviniemi.name] has joined #upstart === jonibo [n=jonas@213.212.2.215] has joined #upstart === popey [n=alan@ubuntu/member/popey] has joined #upstart === reppel [n=reppel@213-140-11-128.fastres.net] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart [11:49] hi, is job-as-states implemented in 0.3.5 or I'm better using https://launchpad.net/~keybuk/+branch/upstart/complex-event-config ? [11:51] jobs-as-states is implemented, yes [11:53] AlexExtreme: and the 'with' keyword? is it possible in 0.3.5 to use e.g. 'with networking-up' ? [11:53] (otherwise, how do i use a state?) [11:53] nope, with is not implemented [11:54] that *will* be part of complex-event-config but it isn't implemented in the branch yet afaik [11:54] ok, I was looking cfgfile.c and there is no mention of 'with' keyword.. [11:54] thanks [11:55] AlexExtreme: so how do i specify in a job that it requires the state networking-up ? 'on started networking-up' ? [11:55] http://upstart.ubuntu.com/wiki/JobsAsStates [11:56] thanks [12:02] is it possible to define a variable in a job description? [12:02] no idea [12:02] :) [12:03] i plan to write down some docs once i get this beast working :) [12:50] ./configure: line 1655: syntax error near unexpected token `1.9' [12:50] ./configure: line 1655: `AM_INIT_AUTOMAKE(1.9 gnu nostdinc check-news dist-bzip2)' [12:50] uhm\ [12:50] (i'm using the complex-event-config branch) [12:51] any idea? i really don't understand the whole autohell stuff... [12:51] i've just run autoconf into the upstart directory [12:51] and it created a configure script [12:51] but it gives this error [12:52] you shouldn't run autoconf [12:52] wait a sec [12:53] read this: https://lists.ubuntu.com/archives/upstart-devel/2007-February/000230.html [12:53] thanks again AlexExtreme [12:54] once you've done the nihify part of that, run this from the root of the complex-event-config branch: [12:54] autoreconf -i [12:54] then configure should work right [01:13] worked [01:13] nice [01:19] reppel, what distro are you using, just out of curiousity? [01:20] AlexExtreme: i'm cross-compiling upstart from etch to a custom mips one [01:20] wow [01:20] debian etch [01:20] cool :) [01:21] i had to do some small modification to allow cross-compiling on mips [01:21] SIGSTKFLT is not defined on this platform [01:21] and SSIZE_MAX is not defined in my toolchain so i defined it to LONG_MAX but i think this is a toolchain issue [01:22] also SIGUNUSED seems undefined [01:24] Making all in nih [01:24] make[2] : Entering directory `/home/ciotta/upstart/libnih/nih' [01:24] make[2] : *** No rule to make target `../m4/codeset.m4', needed by `Makefile.in'. Stop. [01:24] make[2] : Leaving directory `/home/ciotta/upstart/libnih/nih' [01:24] make[1] : *** [all-recursive] Error 1 [01:24] ideas? [01:28] nope [01:28] sorry [01:28] you'll have to ask keybuk when he's around [01:29] i suspect is a problem with nihify [01:30] yes [01:36] You don't know how much i don't like auto-* stuff [01:36] I don't like it either [01:42] there are also other erros [01:42] AlexExtreme: can you actually compile this branch? [01:42] no idea :) [01:43] I bet on it :) [01:47] start on stopped mount-kernel-filesystems ok <-- what's the meaning of ok? is it mandatory? [01:49] i think that means that it should only run if that is stopped but it exited normally [01:49] i.e, if it exited with an error that wouldn't be run === Keybuk [n=scott@quest.netsplit.com] has joined #upstart [01:57] Hi Keybuk, i'm trying to compile complex-event-config branch (bzr merged http://www.netsplit.com/bzr/libnih http://bazaar.launchpad.net/~keybuk/upstart/complex-event-config; cd complex-event-config; ../libnih/nihify .; autoreconf -i; ./configure; make) but it stops at "No rule to make target `../m4/codeset.m4'" in libnih/nih, any ideas? i think there might be a problem with links made by nihify) [01:57] which version of autoconf, automake, libtool, gettext, etc. do you have installed? [01:58] make sure they're the same rough versions as noted in HACKING [01:58] ok [01:58] I'm going to check, thanks [01:59] Keybuk: as a side note, i'm cross-compiling upstart for mips, i had to comment out SIGSTKFLT in nih/signal.c since it is not available on mipsel [02:00] reppel: update the libnih tree, there's a patch for that already [02:00] (bzr pull) [02:00] nice thanks [02:22] Keybuk: same error :| [02:23] dpkg -l autoconf automake libtool gettext |awk '/^ii/ {print $3}' [02:23] 2.61-4 [02:23] 1.10+nogfdl-1 [02:23] 0.16.1-1 [02:23] 1.5.22-4 [02:25] did you run autoreconf inside libnih? [02:25] uhm I only did it in the upstart dir/ [02:25] i'm going to try [02:26] right [02:26] you need to do the libnih one as well I think [02:26] just run autoreconf -i there, and try running "configure" again from upstart [02:29] ok you also have to run configure in the libnih dir to install libtool and other stuff [02:29] if you need to update the wiki, here is the sequence i use: [02:29] bzr branch http://www.netsplit.com/bzr/libnih libnih [02:29] bzr branch http://bazaar.launchpad.net/~keybuk/upstart/complex-event-config [02:29] cd libnih/ [02:29] autoreconf -i [02:29] ./configure [02:29] cd ../complex-event-config [02:29] ../libnih/nihify [02:29] autoreconf -i [02:30] ./configure [02:30] make [02:31] is there a wiki page on this? [02:31] (if not, go ahead and add one :p) [02:32] http://upstart.ubuntu.com/wiki/ContributingCode [02:32] Ok i'm registering in launchpad so i can make modifications myself [02:32] *by [02:33] uhm that page is marked as "immutable" [02:33] do you have a wiki account? [02:33] click Login at the top, fill in the fields and click Create Profile [02:33] ok thanks :) [02:36] Keybuk: you think it's better to add instructions to ContributingCode or create a page called CompilingUpstart into CategoryDoc ? [02:38] either works [02:38] CompilingUpstart would be useful and link to it [02:41] ok === pkt [n=pantelis@athedsl-134586.otenet.gr] has joined #upstart === mbiebl [n=michael@e180112078.adsl.alicedsl.de] has joined #upstart === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart === j_ack [n=rudi@p508DB669.dip0.t-ipconnect.de] has joined #upstart === thotz [n=thomas@d86-33-125-87.cust.tele2.at] has joined #upstart === thotz [n=thomas@d86-33-125-87.cust.tele2.at] has left #upstart [] [05:55] hmm [05:55] ? [05:55] is it possible to use CIA (as in http://cia.navi.cx) with Bazaar on launchpad? [05:59] I've no idea [05:59] ah well [05:59] their site doesn't mention Launchpad [06:00] well, it's not host specific, it's specific to the VCS [06:00] there's a bzr plugin, but that's client-side [06:00] hmm [06:00] it's client side... [06:00] that would be good [06:01] that'd involve me running it [06:01] which would seem to defeat the point, no? [06:01] i'm not talking about for upstart [06:01] the plugin runs on commit, not push [06:01] i'm considering moving my project's source to bazaar on launchpad [06:01] ah [06:02] why did ubuntu choose bzr over svn? [06:02] is it more oriented to the distributed model? [06:02] like git or arch? [06:03] <_ion> I don't really see a reason for anyone to choose svn or any other centralized VCS. :-) [06:04] <_ion> Even in a centralized environment, a centralized VCS is a single point of failure. [06:05] reppel: simple; with bzr I can commit on my laptop whenever I like [06:05] on trains, planes, etc. [06:05] and I can choose when I push it to the archive [06:05] oh nice [06:06] Ubuntu didn't choose bzr anyway :) we developed it [06:06] Keybuk: when you started it, there was no other option? (svn,arch,git,mercurial) [06:06] mercurial is a fork of bzr [06:06] at least, they took the original bzr design documents and wrote a separate implementation [06:07] git didn't exist at the time either [06:07] svn is useless, and should die a horrible death [06:07] <_ion> darcs is pretty old, isn't it? [06:07] svn is horrible [06:07] the only two useful revision control systems were CVS and Arch [06:07] CVS doesn't do distributed, merging or branching [06:08] Arch does, so we hired and funded that -- but found that it was just too much like hard work [06:08] so we forked it and called the fork "Bazaar" [06:08] _ion, darcs is great, but the choice of programming language was a bit wrong imo ;) also it's rather slow [06:08] but it soon became apparent that though there were good ideas there, it still wasn't tenable to use [06:08] so we designed from scratch a new one called "Bazaar NG" / "bzr", which has since inherited the "Bazaar" name [06:08] _ion: we'd never heard of darcs at the time [06:08] is the old bazaar still in use? [06:09] though I think Martin (who designed bzr) had [06:09] nah, old bazaar is basically dead [06:09] ah [06:09] ok [06:09] frugalware uses darcs for everything [06:09] the reason upstart uses bzr is simply that I like it :) [06:10] I don't really have any major [06:10] and at this moment, I agree that SVN should die a horrible death [06:10] annoyances with bzr, which says a lot [06:10] SVN is no better than CVS [06:10] it won't let me add a directory because a file had that name before, it says i need to commit the rename of that file but i already have done [06:10] the only useful thing it adds to CVS is atomic commits, at the cost of a huge amount of headache and maintenance problems -- combined with lethargic slowness [06:11] so [06:11] i'm switching to bzr === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart [06:11] (actually, that's not true ... I do have a medium annoyance with bzr, which is that some of its commands aren't consistent with each other -- but they do fix those from time to time) === phsdv [n=paul@dyn-88-123-135-123.ppp.tiscali.fr] has joined #upstart [06:14] i'm liking bzr already === int0x0c [n=ben@161.253.47.25] has joined #upstart [06:30] Hi, I have a question on event arguments. What happens if we have something like "on event1 and event2"? I guess $1 will belong to event1 and $2 to event2. But what happens if only event2 sends an argument with the event, it will be in $1 or in $2? [06:47] currently: [06:47] whichever of the two events comes second [06:48] so if event1 happens, then event2, the job only knows about event2 [06:48] UPSTART_EVENT=event2, $n are the arguments to event2 and the environment comes from event2 [07:11] that's mostly down to the design of the way that events are transferred into jobs [07:11] the EventEmission is referenced by the job when the goal changes [07:12] the arguments and environment are taken directly from the EventEmission structure [07:12] and when the job reaches a rest state, it unreferences the EventEmission [07:12] this all predates complex-event-config :) [07:12] assuming that we want to fix it so that: [07:13] on block-device-added and some-other-event [07:13] can still see what block device was added ... [07:13] we need to come up with a solution, which could be anything of: [07:13] 1. permit multiple event emissions on a job, collate them all (what does UPSTART_EVENT contain?) [07:14] - problem here is that events aren't finished until all jobs unreference them, so the initctl emit block-device-added would block until some-other-event happened [07:14] 2. collate the event information some other way in the job (eww, copying) [07:14] complex-event-config also affects instance jobs in a similar way [07:14] e.g. do you spawn an instance when the *first* event happens in a complex set, or the last? :p [07:19] the block-device-added was the example that triggered my question [07:21] (there's a reason the code is in a branch :p) [07:21] whould haveing an UPSTART_EVENT1+UPSTART_ARG1, UPSTART_EVENT2 + UPSTART_ARG2 be an option? [07:38] the problem is a coding one [07:39] at least, from my pov :p [07:39] though, having just done the washing up, I thought of a possible solution [07:40] 1) start instances from job_handle_event rather than job_change_goal -- so they're started on the first event in a set (though would need to also check them to make sure that if everything goes to FALSE, the instance is deleted) [07:40] 2) each Event operand node has not only an Event * for what it's matching but an EventEmission * for what it's matched [07:40] 3) set that to the emission when matched and set the value to TRUE; set it to NULL when the value is set to FALSE [07:41] 4) add an event refcount to EventEmission, they don't stop it being finished, but just stop it being freed; increment/decrement this when adjusting the Event operand [07:42] 5) iterate the tree and seed the environment with all other emissions than the current one [07:45] I have not looked into the implementation details before, but I see where you are going. [07:45] you need 4, in the case you have multiple scripts waiting for the same event? [07:48] the reason you need 4 is because of the way event emission works [07:49] take for example "on block-device-added and some-other-event" [07:49] if you just ref'd the eventemission in the normal way, the emission would be blocked until some-other-event occurred [07:49] so the process ("initctl" or just udev directly) that was emitting that event would be blocked [07:49] since it's waiting to hear progress on the event [07:50] if some-other-event never happens, they can be blocked indefinitely [07:51] ok, clear. We do not want things to block ;-) and for sure not forever [07:51] of course, the problem with above is that any event participating can never fail :) [07:51] because success would be toggling a flag in the tree [07:51] rather than the associated job reaching its goal rest state [07:56] so we are stuck for the moment? No (predictable) arguments with complex events. [07:57] it depends on your definition of "moment" :p [07:58] :-) I am sure you can think of a solution [08:06] yeah, is just one of the problems with that spec [08:06] and why it's still drafting [08:08] no problem. That is why I try to write some script, to find unforseen issues. [08:13] yeah [08:13] it's why I did a trial implementation [08:13] to make sure it just worked, which it doesn't === j_ack [n=rudi@p508DB669.dip0.t-ipconnect.de] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === int0x0c [n=ben@128.164.137.192] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart