[02:39] <aschmitz> Is it possible to change the permissions on a given job's log at /var/log/upstart/jobname.log?
[02:40] <aschmitz> (Obviously, I can change it manually, but will that stay after rotation?)
[13:25] <afournier> is it possible to disable a job by adding a file (ie /etc/init/myjob.disable) ?
[13:43] <marrusl> afournier, create a file called /etc/init/myjob.override that contains the word "manual" on a line by itself.
[13:45] <marrusl> afournier, see: http://upstart.ubuntu.com/cookbook/#disabling-a-job-from-automatically-starting 
[13:45] <marrusl> (especially section 11.44.1)
[13:45] <afournier> i knew i saw something like this before, just could not find it again
[13:45] <afournier> thanks a lot
[15:02] <stgraber> jodh: ping
[15:02] <jodh> stgraber: hi
[15:03] <stgraber> jodh: do you have some time to spend with doko to figure out the gcc problem?
[15:03] <stgraber> jodh: he identified the broken patch and reverted it, but we need to get a smaller reproducer
[15:03] <stgraber> jodh: https://bugs.launchpad.net/gcc/+bug/1123588
[15:03] <jodh> stgraber: I'll see what I can do. Currently having problems with dbus and the test suite.
[15:04] <stgraber> hey doko 
[15:05] <doko> hanging around like upstart after failed tests? ;p
[15:05] <jodh> doko: is the broken gcc on one of the porter boxes?
[15:05] <stgraber> jodh: it was in the archive up until 3 hours ago, so you probably still have it on your machine (or you can grab it from Launchpad)
[15:06] <doko> jodh, no, grap it from lp. I *think* that the cpp-4.7 and gcc-4.7 debs (cc1) should be enough to install
[15:13] <doko> jodh, is upstart supposed to be built with -Os?
[15:15] <jodh> doko: hmm. I thought that -Os was historically only used for libnih.
[15:16] <jodh> doko: interestingly, I don't get the failure with that gcc version on i386 with ' -O0 -g -ggdb3 -fno-inline'. I'll try with -Os/-O2...
[15:17] <doko> jodh, fails with -O2 too
[15:18] <doko> jodh, stgraber said something about a dump probably failing. which code/file is this?
[15:19] <stgraber> test_job is the failing test, but it's itself testing job.c and in this case some of the stateful re-exec bits
[15:19] <stgraber> it looks like what's wrong is the saved state as the json reports the job as stopped while it's actually running
[15:19] <stgraber> so my guess is that the bug affects one of the functions responsible for saving the state of the job
[15:20] <doko> jodh, fails for me too with -fno-inline
[15:23] <jodh> right - I can recreate it now.
[15:28] <doko> jodh, stgraber: so, building all the test code with -O0 and all other files in init with -O2 lets the tests succeed
[15:29] <stgraber> right, though that probably means that an actual stateful re-exec of init would fail similarly to what the test shows...
[15:33] <doko> removing everything in this file except the two *deserialize* functions still shows the issue
=== xnox is now known as foxtrot
=== foxtrot is now known as xnox
[16:51] <jodh> doko: I've got a minimal C program that uses all the macros and functions in that deserialise code and I cannot make it fail.
[16:52] <doko> :-(
[17:06] <jodh> doko: just thought I'd try a clang build but that explodes in flames with an internal compiler error too :(
[17:07] <doko> jodh, well, -O0 works, but maybe that's not what you want for production
[17:25] <jodh> doko: yeah, not ideal. Can we get some more context on the original problem from the gcc devs? I've looked at the gcc bug, but I don't understand much of it (the change was primarily for C++ right?)
[17:41] <doko> jodh, I don't suspect so
[17:42] <doko> jodh, so your reduced test case doesn't show the error at all?
[18:49] <jodh> doko: sorry, no. It's here if you want to try it: http://paste.ubuntu.com/1645562/. I'll take another look tomorrow.