[11:49] <reppel> 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] <AlexExtreme> jobs-as-states is implemented, yes
[11:53] <reppel> AlexExtreme: and the 'with' keyword? is it possible in 0.3.5 to use e.g. 'with networking-up' ?
[11:53] <reppel> (otherwise, how do i use a state?)
[11:53] <AlexExtreme> nope, with is not implemented
[11:54] <AlexExtreme> that *will* be part of complex-event-config but it isn't implemented in the branch yet afaik
[11:54] <reppel> ok, I was looking cfgfile.c and there is no mention of 'with' keyword..
[11:54] <reppel> thanks
[11:55] <reppel> AlexExtreme: so how do i specify in a job that it requires the state networking-up ? 'on started networking-up' ?
[11:55] <AlexExtreme> http://upstart.ubuntu.com/wiki/JobsAsStates
[11:56] <reppel> thanks
[12:02] <reppel> is it possible to define a variable in a job description?
[12:02] <AlexExtreme> no idea
[12:02] <AlexExtreme> :)
[12:03] <reppel> i plan to write down some docs once i get this beast working :)
[12:50] <reppel> ./configure: line 1655: syntax error near unexpected token `1.9'
[12:50] <reppel> ./configure: line 1655: `AM_INIT_AUTOMAKE(1.9 gnu nostdinc check-news dist-bzip2)'
[12:50] <reppel> uhm\
[12:50] <reppel> (i'm using the complex-event-config branch)
[12:51] <reppel> any idea? i really don't understand the whole autohell stuff...
[12:51] <reppel> i've just run autoconf into the upstart directory
[12:51] <reppel> and it created a configure script
[12:51] <reppel> but it gives this error
[12:52] <AlexExtreme> you shouldn't run autoconf
[12:52] <AlexExtreme> wait a sec
[12:53] <AlexExtreme> read this: https://lists.ubuntu.com/archives/upstart-devel/2007-February/000230.html
[12:53] <reppel> thanks again AlexExtreme 
[12:54] <AlexExtreme> once you've done the nihify part of that, run this from the root of the complex-event-config branch:
[12:54] <AlexExtreme> autoreconf -i
[12:54] <AlexExtreme> then configure should work right
[01:13] <reppel> worked
[01:13] <reppel> nice
[01:19] <AlexExtreme> reppel, what distro are you using, just out of curiousity?
[01:20] <reppel> AlexExtreme: i'm cross-compiling upstart from etch to a custom mips one
[01:20] <AlexExtreme> wow
[01:20] <reppel> debian etch
[01:20] <AlexExtreme> cool :)
[01:21] <reppel> i had to do some small modification to allow cross-compiling on mips
[01:21] <reppel> SIGSTKFLT is not defined on this platform
[01:21] <reppel> 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] <reppel> also SIGUNUSED seems undefined
[01:24] <reppel> Making all in nih
[01:24] <reppel> make[2] : Entering directory `/home/ciotta/upstart/libnih/nih'
[01:24] <reppel> make[2] : *** No rule to make target `../m4/codeset.m4', needed by `Makefile.in'.  Stop.
[01:24] <reppel> make[2] : Leaving directory `/home/ciotta/upstart/libnih/nih'
[01:24] <reppel> make[1] : *** [all-recursive]  Error 1
[01:24] <reppel> ideas?
[01:28] <AlexExtreme> nope
[01:28] <AlexExtreme> sorry
[01:28] <AlexExtreme> you'll have to ask keybuk when he's around
[01:29] <reppel> i suspect is a problem with nihify
[01:30] <AlexExtreme> yes
[01:36] <reppel> You don't know how much i don't like auto-* stuff
[01:36] <AlexExtreme> I don't like it either
[01:42] <reppel> there are also other erros
[01:42] <reppel> AlexExtreme: can you actually compile this branch?
[01:42] <AlexExtreme> no idea :)
[01:43] <reppel> I bet on it :)
[01:47] <reppel> start on stopped mount-kernel-filesystems ok <-- what's the meaning of ok? is it mandatory?
[01:49] <AlexExtreme> i think that means that it should only run if that is stopped but it exited normally
[01:49] <AlexExtreme> i.e, if it exited with an error that wouldn't be run
[01:57] <reppel> 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] <Keybuk> which version of autoconf, automake, libtool, gettext, etc. do you have installed?
[01:58] <Keybuk> make sure they're the same rough versions as noted in HACKING
[01:58] <reppel> ok
[01:58] <reppel> I'm going to check, thanks
[01:59] <reppel> 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] <Keybuk> reppel: update the libnih tree, there's a patch for that already
[02:00] <Keybuk> (bzr pull)
[02:00] <reppel> nice thanks
[02:22] <reppel> Keybuk: same error :|
[02:23] <reppel> dpkg -l autoconf automake libtool gettext |awk '/^ii/ {print $3}'
[02:23] <reppel> 2.61-4
[02:23] <reppel> 1.10+nogfdl-1
[02:23] <reppel> 0.16.1-1
[02:23] <reppel> 1.5.22-4
[02:25] <Keybuk> did you run autoreconf inside libnih?
[02:25] <reppel> uhm I only did it in the upstart dir/
[02:25] <reppel> i'm going to try
[02:26] <Keybuk> right
[02:26] <Keybuk> you need to do the libnih one as well I think
[02:26] <Keybuk> just run autoreconf -i there, and try running "configure" again from upstart
[02:29] <reppel> ok you also have to run configure in the libnih dir to install libtool and other stuff
[02:29] <reppel> if you need to update the wiki, here is the sequence i use:
[02:29] <reppel> bzr branch http://www.netsplit.com/bzr/libnih libnih
[02:29] <reppel> bzr branch http://bazaar.launchpad.net/~keybuk/upstart/complex-event-config
[02:29] <reppel> cd libnih/
[02:29] <reppel> autoreconf -i
[02:29] <reppel> ./configure
[02:29] <reppel> cd ../complex-event-config
[02:29] <reppel> ../libnih/nihify
[02:29] <reppel> autoreconf -i
[02:30] <reppel> ./configure
[02:30] <reppel> make
[02:31] <Keybuk> is there a wiki page on this?
[02:31] <Keybuk> (if not, go ahead and add one :p)
[02:32] <reppel> http://upstart.ubuntu.com/wiki/ContributingCode
[02:32] <reppel> Ok i'm registering in launchpad so i can make modifications myself
[02:32] <reppel> *by
[02:33] <reppel> uhm that page is marked as "immutable"
[02:33] <Keybuk> do you have a wiki account?
[02:33] <Keybuk> click Login at the top, fill in the fields and click Create Profile
[02:33] <reppel> ok thanks :)
[02:36] <reppel> Keybuk: you think it's better to add instructions to ContributingCode or create a page called CompilingUpstart into CategoryDoc ?
[02:38] <Keybuk> either works
[02:38] <Keybuk> CompilingUpstart would be useful and link to it
[02:41] <reppel> ok
[05:55] <AlexExtreme> hmm
[05:55] <Keybuk> ?
[05:55] <AlexExtreme> is it possible to use CIA (as in http://cia.navi.cx) with Bazaar on launchpad?
[05:59] <Keybuk> I've no idea
[05:59] <AlexExtreme> ah well
[05:59] <Keybuk> their site doesn't mention Launchpad
[06:00] <AlexExtreme> well, it's not host specific, it's specific to the VCS
[06:00] <Keybuk> there's a bzr plugin, but that's client-side
[06:00] <AlexExtreme> hmm
[06:00] <AlexExtreme> it's client side...
[06:00] <AlexExtreme> that would be good
[06:01] <Keybuk> that'd involve me running it
[06:01] <Keybuk> which would seem to defeat the point, no?
[06:01] <AlexExtreme> i'm not talking about for upstart
[06:01] <Keybuk> the plugin runs on commit, not push
[06:01] <AlexExtreme> i'm considering moving my project's source to bazaar on launchpad
[06:01] <Keybuk> ah
[06:02] <reppel> why did ubuntu choose bzr over svn?
[06:02] <reppel> is it more oriented to the distributed model?
[06:02] <reppel> 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] <Keybuk> reppel: simple; with bzr I can commit on my laptop whenever I like
[06:05] <Keybuk> on trains, planes, etc.
[06:05] <Keybuk> and I can choose when I push it to the archive
[06:05] <reppel> oh nice
[06:06] <Keybuk> Ubuntu didn't choose bzr anyway :)  we developed it
[06:06] <reppel> Keybuk: when you started it, there was no other option? (svn,arch,git,mercurial)
[06:06] <Keybuk> mercurial is a fork of bzr
[06:06] <Keybuk> at least, they took the original bzr design documents and wrote a separate implementation
[06:07] <Keybuk> git didn't exist at the time either
[06:07] <Keybuk> svn is useless, and should die a horrible death
[06:07] <_ion> darcs is pretty old, isn't it?
[06:07] <AlexExtreme> svn is horrible
[06:07] <Keybuk> the only two useful revision control systems were CVS and Arch
[06:07] <Keybuk> CVS doesn't do distributed, merging or branching
[06:08] <Keybuk> Arch does, so we hired and funded that -- but found that it was just too much like hard work
[06:08] <Keybuk> so we forked it and called the fork "Bazaar"
[06:08] <AlexExtreme> _ion, darcs is great, but the choice of programming language was a bit wrong imo ;) also it's rather slow
[06:08] <Keybuk> but it soon became apparent that though there were good ideas there, it still wasn't tenable to use
[06:08] <Keybuk> so we designed from scratch a new one called "Bazaar NG" / "bzr", which has since inherited the "Bazaar" name
[06:08] <Keybuk> _ion: we'd never heard of darcs at the time
[06:08] <AlexExtreme> is the old bazaar still in use?
[06:09] <Keybuk> though I think Martin (who designed bzr) had
[06:09] <Keybuk> nah, old bazaar is basically dead
[06:09] <AlexExtreme> ah
[06:09] <AlexExtreme> ok
[06:09] <AlexExtreme> frugalware uses darcs for everything
[06:09] <Keybuk> the reason upstart uses bzr is simply that I like it :)
[06:10] <Keybuk> I don't really have any major 
[06:10] <AlexExtreme> and at this moment, I agree that SVN should die a horrible death
[06:10] <Keybuk> annoyances with bzr, which says a lot
[06:10] <Keybuk> SVN is no better than CVS
[06:10] <AlexExtreme> 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] <Keybuk> 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] <AlexExtreme> so
[06:11] <AlexExtreme> i'm switching to bzr
[06:11] <Keybuk> (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)
[06:14] <AlexExtreme> i'm liking bzr already
[06:30] <phsdv> 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] <Keybuk> currently:
[06:47] <Keybuk> whichever of the two events comes second
[06:48] <Keybuk> so if event1 happens, then event2, the job only knows about event2
[06:48] <Keybuk> UPSTART_EVENT=event2, $n are the arguments to event2 and the environment comes from event2
[07:11] <Keybuk> that's mostly down to the design of the way that events are transferred into jobs
[07:11] <Keybuk> the EventEmission is referenced by the job when the goal changes
[07:12] <Keybuk> the arguments and environment are taken directly from the EventEmission structure
[07:12] <Keybuk> and when the job reaches a rest state, it unreferences the EventEmission
[07:12] <Keybuk> this all predates complex-event-config :)
[07:12] <Keybuk> assuming that we want to fix it so that:
[07:13] <Keybuk>   on block-device-added and some-other-event
[07:13] <Keybuk> can still see what block device was added ...
[07:13] <Keybuk> we need to come up with a solution, which could be anything of:
[07:13] <Keybuk>  1. permit multiple event emissions on a job, collate them all (what does UPSTART_EVENT contain?)
[07:14] <Keybuk>     - 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] <Keybuk>  2. collate the event information some other way in the job (eww, copying)
[07:14] <Keybuk> complex-event-config also affects instance jobs in a similar way
[07:14] <Keybuk> e.g. do you spawn an instance when the *first* event happens in a complex set, or the last? :p
[07:19] <phsdv> the block-device-added was the example that triggered my question
[07:21] <Keybuk> (there's a reason the code is in a branch :p)
[07:21] <phsdv> whould haveing an UPSTART_EVENT1+UPSTART_ARG1,  UPSTART_EVENT2 + UPSTART_ARG2 be an option? 
[07:38] <Keybuk> the problem is a coding one
[07:39] <Keybuk> at least, from my pov :p
[07:39] <Keybuk> though, having just done the washing up, I thought of a possible solution
[07:40] <Keybuk> 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] <Keybuk> 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] <Keybuk> 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] <Keybuk> 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] <Keybuk> 5) iterate the tree and seed the environment with all other emissions than the current one
[07:45] <phsdv> I have not looked into the implementation details before, but I see where you are going.
[07:45] <phsdv> you need 4, in the case you have multiple scripts waiting for the same event?
[07:48] <Keybuk> the reason you need 4 is because of the way event emission works
[07:49] <Keybuk> take for example "on block-device-added and some-other-event"
[07:49] <Keybuk> if you just ref'd the eventemission in the normal way, the emission would be blocked until some-other-event occurred
[07:49] <Keybuk> so the process ("initctl" or just udev directly) that was emitting that event would be blocked
[07:49] <Keybuk> since it's waiting to hear progress on the event
[07:50] <Keybuk> if some-other-event never happens, they can be blocked indefinitely
[07:51] <phsdv> ok, clear. We do not want things to block ;-) and for sure not forever
[07:51] <Keybuk> of course, the problem with above is that any event participating can never fail :)
[07:51] <Keybuk> because success would be toggling a flag in the tree
[07:51] <Keybuk> rather than the associated job reaching its goal rest state
[07:56] <phsdv> so we are stuck for the moment? No (predictable) arguments with complex events.
[07:57] <Keybuk> it depends on your definition of "moment" :p
[07:58] <phsdv> :-)  I am sure you can think of a solution
[08:06] <Keybuk> yeah, is just one of the problems with that spec
[08:06] <Keybuk> and why it's still drafting
[08:08] <phsdv> no problem. That is why I try to write some script, to find unforseen issues. 
[08:13] <Keybuk> yeah
[08:13] <Keybuk> it's why I did a trial implementation
[08:13] <Keybuk> to make sure it just worked, which it doesn't