[15:41] <stgraber> xnox: so did you spend any more time on that qt theming issue? I'm poking at it now but don't want to duplicate debugging effort ;)
[21:57] <tartar> Why would initctl emit mounting MOUNTPOINT=/blah fail?
[21:58] <tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1
[21:58] <tartar> Err
[21:58] <tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: + /sbin/initctl emit mounting MOUNTPOINT=/var/build/ramdisk
[21:58] <tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: initctl: Event failed
[21:58] <tartar> 2013-02-21 15:14:45-05:00 1116 ramdisk: EXITCODE=1
[21:59] <tartar> Ubuntu Lucid here
[21:59] <tartar> Will looping till success work this around?
[22:00] <tartar> (I saw few mounting hooks with same MOUNTPOINT coming to my block-dependants task.  I wonder if mountall already does the same work-around).
[22:01] <xnox> tartar: I am sorry, but what are you trying to do?
[22:02] <tartar> I am sticking centrify and couple more things early into the startup.
[22:02] <xnox> mountall emits these events for all mountpoints in /lib/init/fstab as well as anything in your fstab.
[22:03] <tartar> In particular, my ramdisk.conf simulates the mountall behavior by emitting a mounting hook
[22:04] <tartar> I need my ramdisk to block until centrify is ready and for this I added a block-dependants task
[22:04] <tartar> But I see that ramdisk's initctl emit fails to block returning the error above
[22:05] <xnox> have you seen: http://upstart.ubuntu.com/cookbook/#block-another-job-until-yours-has-started
[22:05] <xnox> emitting events will simply spawn more stuff to happen & get activated not less.
[22:05] <tartar> Yup, that's where I got the block-dependants thing
[22:07] <tartar> (BTW instance $JOB resulted in an error message saying that JOB did not exist.  Perhaps my Lucid upstart is too old for the cook book)
[22:07] <tartar> I replaced that with instance mounting-$MOUNTPOINT
[22:09] <tartar> Should better read as mountall-$MOUNTING as I expect that mountall emits mounting hooks, and $JOB would receive "mountall"
[22:10] <tartar> err mountall-$MOUNTPOINT
[22:10] <tartar> ...if I understand this correctly
[22:11] <tartar> Actually now I see I went against the recipe by instantiating too many instances
[22:12] <tartar> should my block-dependants task use "instance mountall"?
[22:48] <tartar> I wish upstart clearly stated own mechanisms and those expected from other processes.
[22:48] <tartar> For now the cook book reflects its name giving mostly recipes rather than architectural knowledge.
[22:50] <tartar> To illustrate, the following phrase has unnecessary complications.  The change of the mode from educational to instructional and back brings confusion.
[22:50] <tartar> "What you will find is that if you run the script above under /bin/sh, in all likelihood the file will never be created since regardless of whether you specify "-e" or not, the dash(1) shell (which /bin/sh is linked to on Ubuntu systems) has different semantics when it comes to sourcing compared with /bin/bash."
[22:52] <tartar> I would steer away from giving any instruction in a text about a thing that I would need to understand.
[22:54] <tartar> (I failed to understand the quoted phrase).
[22:56] <tartar> Enough vitriolic ranting....
[23:38] <tartar> The section block-another-job-until-yours-has-started assumes that the blocker task multiplies itself to block each job emitting one of the hooks.  Why?
[23:38] <tartar> Can a single blocker task block all hook emitters?
[23:39] <tartar> s/task/instance/