| === 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 | ||
| 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:49 |
|---|---|---|
| AlexExtreme | jobs-as-states is implemented, yes | 11:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| reppel | thanks | 11:56 |
| reppel | is it possible to define a variable in a job description? | 12:02 |
| AlexExtreme | no idea | 12:02 |
| AlexExtreme | :) | 12:02 |
| reppel | i plan to write down some docs once i get this beast working :) | 12:03 |
| 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:50 |
| 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:51 |
| AlexExtreme | you shouldn't run autoconf | 12:52 |
| AlexExtreme | wait a sec | 12:52 |
| AlexExtreme | read this: https://lists.ubuntu.com/archives/upstart-devel/2007-February/000230.html | 12:53 |
| reppel | thanks again AlexExtreme | 12:53 |
| 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 | 12:54 |
| reppel | worked | 01:13 |
| reppel | nice | 01:13 |
| AlexExtreme | reppel, what distro are you using, just out of curiousity? | 01:19 |
| 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:20 |
| 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:21 |
| reppel | also SIGUNUSED seems undefined | 01:22 |
| 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:24 |
| AlexExtreme | nope | 01:28 |
| AlexExtreme | sorry | 01:28 |
| AlexExtreme | you'll have to ask keybuk when he's around | 01:28 |
| reppel | i suspect is a problem with nihify | 01:29 |
| AlexExtreme | yes | 01:30 |
| reppel | You don't know how much i don't like auto-* stuff | 01:36 |
| AlexExtreme | I don't like it either | 01:36 |
| reppel | there are also other erros | 01:42 |
| reppel | AlexExtreme: can you actually compile this branch? | 01:42 |
| AlexExtreme | no idea :) | 01:42 |
| reppel | I bet on it :) | 01:43 |
| reppel | start on stopped mount-kernel-filesystems ok <-- what's the meaning of ok? is it mandatory? | 01:47 |
| 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:49 |
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| 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:57 |
| 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:58 |
| 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 | 01:59 |
| Keybuk | reppel: update the libnih tree, there's a patch for that already | 02:00 |
| Keybuk | (bzr pull) | 02:00 |
| reppel | nice thanks | 02:00 |
| reppel | Keybuk: same error :| | 02:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:29 |
| reppel | ./configure | 02:30 |
| reppel | make | 02:30 |
| Keybuk | is there a wiki page on this? | 02:31 |
| Keybuk | (if not, go ahead and add one :p) | 02:31 |
| 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:32 |
| 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:33 |
| reppel | Keybuk: you think it's better to add instructions to ContributingCode or create a page called CompilingUpstart into CategoryDoc ? | 02:36 |
| Keybuk | either works | 02:38 |
| Keybuk | CompilingUpstart would be useful and link to it | 02:38 |
| reppel | ok | 02:41 |
| === 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 [] | ||
| 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:55 |
| Keybuk | I've no idea | 05:59 |
| AlexExtreme | ah well | 05:59 |
| Keybuk | their site doesn't mention Launchpad | 05:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| _ion | I don't really see a reason for anyone to choose svn or any other centralized VCS. :-) | 06:03 |
| _ion | Even in a centralized environment, a centralized VCS is a single point of failure. | 06:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| AlexExtreme | so | 06:11 |
| AlexExtreme | i'm switching to bzr | 06:11 |
| === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart | ||
| 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:11 |
| === phsdv [n=paul@dyn-88-123-135-123.ppp.tiscali.fr] has joined #upstart | ||
| AlexExtreme | i'm liking bzr already | 06:14 |
| === int0x0c [n=ben@161.253.47.25] has joined #upstart | ||
| 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:30 |
| Keybuk | currently: | 06:47 |
| Keybuk | whichever of the two events comes second | 06:47 |
| 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 | 06:48 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| phsdv | the block-device-added was the example that triggered my question | 07:19 |
| 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:21 |
| Keybuk | the problem is a coding one | 07:38 |
| Keybuk | at least, from my pov :p | 07:39 |
| Keybuk | though, having just done the washing up, I thought of a possible solution | 07:39 |
| 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:40 |
| 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:41 |
| Keybuk | 5) iterate the tree and seed the environment with all other emissions than the current one | 07:42 |
| 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:45 |
| Keybuk | the reason you need 4 is because of the way event emission works | 07:48 |
| 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:49 |
| Keybuk | if some-other-event never happens, they can be blocked indefinitely | 07:50 |
| 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:51 |
| phsdv | so we are stuck for the moment? No (predictable) arguments with complex events. | 07:56 |
| Keybuk | it depends on your definition of "moment" :p | 07:57 |
| phsdv | :-) I am sure you can think of a solution | 07:58 |
| Keybuk | yeah, is just one of the problems with that spec | 08:06 |
| Keybuk | and why it's still drafting | 08:06 |
| phsdv | no problem. That is why I try to write some script, to find unforseen issues. | 08:08 |
| 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 | 08:13 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!