[13:45] <jodh> /topic Upstart 1.9 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv
[13:45] <jodh>  
[15:19] <elmo> jodh: \o/
[15:19] <elmo> jodh: could I safely run upstart 1.9 on raring if I backport it?
[15:22] <xnox> elmo: wait for us to merge 1.9 into saucy & apply ubuntu-specific patches for apparmor, and then backport that package.
[15:22] <elmo> xnox: ok
[15:23] <xnox> elmo: well, i expect you will just be able to recompile for raring.
[15:26] <erkules> ahoi short question. having in his old init script  an own option. Does upstart has any way to have own options? I was thinking about using emit, but that is too fuzzy.
[15:31] <xnox> erkules: what do you want to achieve? and what do you want to do?
[15:32] <xnox> erkules: all common tricks are described here: http://upstart.ubuntu.com/cookbook/#cookbook-and-best-practises
[15:32] <erkules> xnox: hi, I was reading a blogpost. There they patched galera-init with a bootstrap option. So when you start the script with that option it creates a new GTID
[15:34] <erkules> xnox: okidoki
[15:36] <xnox> erkules: i'm still confused what your initial problem/question is. =)
[15:37] <xnox> erkules: if you want to launch different instances of the same daemon you can be using instances
[15:37] <erkules> hehe
[15:37] <xnox> erkules: what is galera-init? what is GTID?
[15:37] <erkules> ok GTID (global transaction id)
[15:37] <erkules> it is a galera thing
[15:38] <erkules> mysql-multi-master
[15:38] <erkules> service mysql start -> starts the server with old GTID
[15:39] <erkules> service mysql start --bootstrap forces the server to create a new GTID
[15:52] <xnox> erkules: if a job is already running, upstart will not try starting it again. Thus you should stop; start.
[15:53] <xnox> erkules: if you want to keep the "old one" running. and run a new one with a different GTID simultaniously. Look into passing variables to jobs and/or instances.
[15:53] <xnox> erkules: it looks like above is an init.d script, are you converting it to a native upstart job?
[15:53] <xnox> erkules: cause under upstart, you can continue using init.d scripts and above should just work as upstream uses it.
[16:04] <erkules> xnox: I would like to implement the idea of extra options in my own upstart script
[16:07] <xnox> erkules: they are not scripts, and are not executed.
[16:08] <xnox> erkules: they are configuration files.
[16:08] <xnox> erkules: you can pass environment variables to them.
[16:08] <xnox> erkules: e.g. you can have $ start myjob BOOTSTRAP=true
[16:09] <xnox> but not arbitrary arguments.
[16:44]  * xnox slowly builds on disk.
[16:48] <xnox> jodh: all 18 tests pass for me with saucy sbuild.
[16:48] <xnox> jodh: please note that for me locally upstart testsuite fails if sbuild is using: overlayfs, tmpfs, eatmydata.
[16:48] <erkules> xnox: thats cool
[16:49] <erkules> xnox++
[16:49] <xnox> jodh: thus to build upstart I always use sbuild with a configuration closer to the distro builders:
[16:50] <xnox> jodh: so my /etc/schroot/chroot.d/sbuild-saucy-amd64 looks like this: http://paste.ubuntu.com/5808343/
[16:50] <xnox> jodh: and I build upstart with sbuild -c saucy-plain-amd64 path-to.dsc
[20:02] <slangasek> xnox: so I confirm your result that the branch builds fine in my sbuild environment; must be something specific to eatmydata or other optimization