[07:22] <tjaalton> what dictates that :all builds are run on i386 and not on, say, amd64?
[07:23] <Noskcaj> tjaalton, tradition
[07:24] <tjaalton> makes sense, but would it then make sense to let amd64 build handle it?
[07:24] <tjaalton> that would at least fix the libx11 build failure, where w3m crashes on i386 building docs :)
[07:24] <tjaalton> though not enough of a reason to switch of course
[07:56] <xnox> slangasek: stgraber: re: upstart-adt, i've seen that test-failure on very fast machines, at the time i was suspecting that libnih time resolution is no longer precise enough for the test in question, but I didn't dig too deep into it.
[07:57] <xnox> jodh: ^ maybe we should finally fix https://jenkins.qa.ubuntu.com/job/saucy-adt-upstart/81/ARCH=amd64,label=adt/artifact/results/ ?
[07:57] <jodh> xnox: looking at it now...
[07:58] <xnox> https://jenkins.qa.ubuntu.com/job/saucy-adt-upstart/81/ARCH=amd64,label=adt/artifact/results/log/*view*/  BAD: wrong value for utmp->ut_tv.tv_usec, got unexpected 487301
[08:38] <seb128> xnox, hey, are you looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1216223 ?
[08:38] <seb128> (I wonder if that's something we should fix before release)
[08:38] <Laney> I mailed the guy who gave us the compressed versions
[08:38] <Laney> but he didn't get back to me
[08:39] <seb128> Laney, is that somebody from our design team?
[08:39] <Laney> seb128: I don't know who it is
[08:39] <Laney> it was on the mail you forwarded to me
[08:39] <Laney> might have CCed you on my enquiry
[08:40] <seb128> yeah, just found the bug back
[08:40] <seb128> bug->email
[08:41] <seb128> mpt, ^ do you know who in design could help on that?
[08:41] <mpt> seb128, jnick_tait
[08:41] <seb128> mpt, thanks
[08:42] <xnox> seb128: thanks for the ping. I don't know how we usually get the wallpapers committed to the branch. Cause there is nothing in the package build that changes quality, and if we didn't take the best available images from flickr that's sad, and/or do we manually resize/crop them at all?
[08:43] <Laney> some guy did some adjustments to make the size smaller
[08:43] <seb128> xnox, I've no idea what the process is or what happened to them
[08:43] <xnox> =/ i see.
[08:43] <Laney> I think there was a size budget of 5M or so
[08:44] <xnox> Laney: i understand a size budget on the default wallpaper, but not the community ones.
[08:44] <Laney> why?
[08:44] <Laney> they're installed by default too
[08:48] <xnox> Laney: well it's memory mapped, so a huge default wallpaper will hinder default benchmarks and somesuch. The rest is just prettiness and we should take highest resolution images we can, think of cinematic iMac displays with huge resolution.
[08:50] <seb128> xnox, the budget was to spare CD size when we still had that target
[08:50] <seb128> not sure it still makes sense nowadays, though it's good to keep some control there
[08:50] <seb128> otherwise we are going to drift
[08:51] <Laney> I'm not aware that we have just let it go completely
[09:10] <cjwatson> tjaalton: Historically we've found that more arch all builds have actually worked on i386.  The correlation isn't perfect
[09:38] <tjaalton> cjwatson: ah, ok
[09:49] <xnox> @pilot in
[10:13] <xnox> slangasek: another nfs/mountall bug #1234613
[10:29] <zyga> jodh: hey, I filed a bug on upstart and upstart-dbus-bridge yesterday, have you had a chance to see it?
[10:30] <jodh> zyga: I cannot recreate the problem you describe. As I say, create a job that specifies "start on dbus" and the bridge will start emitting events which will be visible at that point using upstart-monitor.
[10:31] <zyga> jodh: which version of upstart were you running?
[10:31] <jodh> zyga: version in saucy
[10:31] <zyga> jodh: I created a job as described in the bug report
[10:31] <zyga> jodh: and I only saw the stream of events after I started the bridge manually with --always
[10:32] <jodh> zyga: as I say, I cannot recreate that behaviour.
[10:32] <zyga> hmm
[10:35] <zyga> jodh: is there any chance that your environment is somehow modified and that is concealing the problem, I'm running a fresh install of saucy and I can just reproduce that bug over and over
[10:35] <jodh> zyga: identified your problem - bug updated.
[10:37] <zyga> jodh: this bug? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234393
[10:38] <jodh> zyga: yes
[10:38] <zyga> hmm
[10:38] <zyga> so how can I get system dbus events?
[10:38] <zyga> can I?
[10:41] <ari-tczew> xnox: can you for me sponsor something @main?
[10:42] <zyga> jodh: so does that mean that it's not possible to listen to signals on the system bus from system jobs?
[10:43] <jodh> zyga: no, it simply means we don't start an instance of the dbus bridge connected to the system bus at the system level.
[10:43] <zyga> jodh: well, why don't we?
[10:43] <xnox> ari-tczew: can I has url/link?
[10:44] <zyga> jodh: and is the solution to have a job that runs that that my other job needs to depend on?
[10:44] <xnox> zyga: what system dbus events are you listening on?
[10:44] <zyga> xnox: I wanted to listen to network manager events
[10:44] <xnox> zyga: more specific?
[10:45] <zyga> xnox: but that's not relevant really, it's about if that feature is available or not, is there a reason why this is restricted to session bus?
[10:45] <zyga> xnox: StateChanged
[10:45] <ari-tczew> xnox: https://code.launchpad.net/~ari-tczew/ubuntu/saucy/iptables/lp-1228525-1134554-1187177/+merge/187859
[10:45] <xnox> zyga: system-wide events we already have "net-device-added|changed|down|removed|up"
[10:46] <zyga> xnox: that's not the same
[10:46] <zyga> xnox: and I don't seem to see 'down' events when I disable my network from nm (but I do see the associated network manager dbus signal)
[10:47] <xnox> that's weird, i would have expected for you to see them.
[10:47] <zyga> xnox: is there a reason why we're not running the system level dbus-upstart bridge or is this just an oversight?
[10:47] <zyga> xnox: I see up events though
[10:48] <xnox> zyga: we had it, and then removed. As far as I we figured, both dbus system & session events are only useful in user-session jobs. You are the first one to be using it in a system job.
[10:48] <xnox> zyga: why are you using a system job? do you have to be root?
[10:48] <zyga> xnox: yes
[10:48] <zyga> xnox: well, it's very powerful, no need to have a silly daemon to lurk for that signal
[10:49] <zyga> xnox: unless there's a security issue I think it's just as valid as the session bus, user bridge
[10:49] <xnox> zyga: problem is that when we start system-dbus bridge on system level, those events are replayed to the session-init's =/
[10:51] <zyga> hmm?
[10:51] <zyga> I'm not quite sure I understand
[10:51] <jodh> zyga: we don't run that a dbus bridge at the system level is security-related: see https://code.launchpad.net/~jamesodhunt/upstart/upstart-dbus-bridge/+merge/161772/comments/382554
[10:52] <zyga> ah
[10:52] <zyga> hmm
[10:52] <zyga> well that's too bad
[10:52] <zyga> I'll think about a workaround
[10:52] <zyga> jodh: is there a bug open on that?
[10:54] <jodh> zyga: not that I'm aware of; if you think there is a good reason to run that bus at the system level, feel free to raise a bug.
[10:54] <zyga> jodh: I've filed https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234653
[10:54] <xnox> zyga: well, you just need to add system level dbus-bridge job, and then you can add yours jobs on top of it.
[10:54] <xnox> zyga: jodh: strange thing is there is "net-device-up IFACE='eth0' LOGICAL='eth0' ADDRFAM='NetwokManager' METHOD='NetworkManager'" yet there is no matching "net-device-down" upstart event from network-manager.
[10:55] <zyga> xnox: yeah, I can confirm that
[10:55] <zyga> xnox: but
[10:55] <xnox> when eth0 went down, from network-manager.
[10:55] <zyga> xnox: could it be possible that nothing is listening to that so it's not being sent somehwo?
[10:55] <zyga> somehow
[10:55] <zyga> xnox: as for your comment, are you saying that I can just run the bridge myself as a separate job (not part of default install)
[10:55] <xnox> zyga: i created "start on net-device-down \n exec env" and it wasn't run.
[10:55] <xnox> zyga: yeap. =)
[10:56] <zyga> xnox: won't that have the security issue that we described by jodh above?
[10:56] <xnox> zyga: you need that bridge, so start it ;-)
[10:56] <zyga> xnox: still it will work :) I'll give that a TRY
[10:56] <zyga> try
[10:56] <zyga> caps
[10:56] <xnox> zyga: sure it will, but that's your choice ;-)
[10:59] <zyga> http://paste.ubuntu.com/6187673/
[11:00] <zyga> modified session job, I'll give it a try
[11:03] <zyga> yeah, it works like a charm now
[11:07] <xnox> jdstrand: slangasek: psivaa is reporting that today's desktop daily is failing SecureBOot certificate validation:
[11:07] <xnox> $ sbverify --cert microsoft-uefica-public.pem /mnt/EFI/BOOT/BOOTx64.EFI
[11:07] <xnox> warning: data remaining[1230256 vs 1355656]: gaps between PE/COFF sections?
[11:07] <xnox> PKCS7 verification failed
[11:07] <xnox> 139756278539968:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate has expired
[11:07] <xnox> Signature verification failed
[11:08] <xnox> jdstrand: can it be that certs in lp:qa-regression-testing/notes_testing/secure-boot/keys are out of date?
[11:12] <ari-tczew> cjwatson: I'm encouraging one maintainer in Debian to get our delta (use B-D libtiff-dev rather than libtiff4-dev) applied there, as well. However, he has to get an extra reason to. is there a documentation/discuss for?
[11:14] <xnox> ari-tczew: this http://release.debian.org/transitions/html/libtiff5.html
[11:16] <cjwatson> ari-tczew: Short / more readable version of the above: it means that when the libtiff5 transition starts in Debian, his package will only need a binNMU (which can be done in bulk by the release team) rather than a coordinated upload
[11:17] <cjwatson> There's only a single provider of libtiff-dev at any one time, so it's fine to build-depend directly on it without additionally stating a real alternative
[11:18] <ari-tczew> cjwatson: ok, so I'll write that and additional he doesn't need to update B-D version every time - is it ok?
[11:19] <cjwatson> Right
[11:19] <ari-tczew> cjwatson: ok thanks
[11:24] <psivaa> xnox: jdstrand: slangasek: the shim signature verification happens with today's *both desktop and server images..
[11:25] <xnox> psivaa: "happens" as in passes or fails?
[11:25] <psivaa> xnox: fails
[11:25] <psivaa> sorry
[11:26] <cjwatson> That's expected, same shim
[11:26] <cjwatson> I mean, I'd be very surprised if they differed :)
[11:26] <psivaa> ok :), was thinking if that'd indicate cert expiry
[11:30] <ari-tczew> tumbleweed: I didn't know where should do I to report a bug to ubuntu-sponsorship-miner, so I'm writing here: since we upload things to *-proposed, your script recognizes syncs als sru.
[11:31] <tumbleweed> ari-tczew: ah, that wouldn't suprise me
[11:32] <ari-tczew> tumbleweed: is it possible to get a small whish there? counting search result, like: Sponsorships: 123
[11:52] <xnox> slangasek: psivaa: precise 12.04.2 and raring are also failing sbverify in the same way (expired cert)
[11:59] <ari-tczew> xnox: should do I update d/changelog @iptables?
[12:01] <xnox> ari-tczew: nah, it's ok.
[12:36] <psivaa> xnox: thanks for checking.. we dont have this test for other releases than the dev release
[12:36] <xnox> TheMuso: do we want bug 1231367 and bug  1231365
[12:36] <xnox> psivaa: but precise-daily should have been running this?!
[12:37] <cjwatson> it might've had a later sig from the last point release?
[12:37] <psivaa> xnox: no, precise daily uses different script for the test. may be we should update that
[12:40] <xnox> psivaa: i thought static-iso-validation.py thing is generic enough to run against precise images as well.
[12:41] <xnox> (it has many guards and checks for things that are only application to e.g. precise or quantal and up and etc)
[12:41] <psivaa> xnox: yea i think we have two versions of them :) one of which does not have this test
[12:42] <xnox>  /o\
[12:42] <psivaa> xnox: i'll try and update that
[12:54] <ari-tczew> xnox: did you upload iptables to saucy-proposed?
[12:54] <xnox> ari-tczew: check the queue.
[12:55] <xnox> ari-tczew: you know where, right?
[13:09] <ari-tczew> xnox: if you mean https://launchpad.net/ubuntu/saucy/+queue then I don't see or have wrong URL
[13:09] <cjwatson> ?queue_state=1
[13:09] <ari-tczew> ahh unapproved
[13:09] <xnox> ari-tczew: drop down "unapproved" click apply.
[13:09] <ari-tczew> ok got it
[13:10] <xnox> =)
[13:10] <ari-tczew> freeze...
[13:10] <ari-tczew> xnox: don't mind pm speaking?
[13:11] <tedg> stgraber, So we've got an issue where it seems that, randomly, some upstart jobs can't connect to dbus.
[13:12] <tedg> stgraber, When we get crash signatures they don't seem to have DBUS_SESSION_BUS* in their environment.
[13:12] <tedg> stgraber, Even if they're "start on started dbus"
[13:12] <tedg> stgraber, Do you have any idea how that could happen?
[13:27] <guest560139> hello
[13:28] <guest560139> i just read the following article:
[13:28] <guest560139> http://www.phoronix.com/scan.php?page=news_item&px=MTQ3NTU
[13:28] <guest560139> and i like the suggestion at the end of it:
[13:28] <guest560139> "Matthew additionally suggests as an option Canonical just drop XMir entirely and focus their resources on the Mir-based Unity 8 desktop."
[13:29] <guest560139> so, any chance you could do that? just drop XMir entirely and focus on pure Mir and Unity 8?
[13:39] <smartboyhw> OK, weird, but I'm seeing the latest 5 blueprints in https://launchpad.net/ubuntu/ about the same thing
[13:39] <sconklin> @pilot in
[13:40] <smartboyhw> (It's Beta 2 certainly;))
[13:41] <cjwatson> I wish I could restrict blueprint registration to developers
[13:41] <smartboyhw> cjwatson, Ubuntu Members maybe
[13:41] <cjwatson> Maybe
[13:43] <cjwatson> I used to try to garden the list of Ubuntu blueprints, but it's just been a total mess for a long time because people think it's a good way to make random feature requests
[13:44] <cjwatson> And various well-meaning bug triagers have been encouraging that behaviour
[13:44] <seb128> cjwatson, I use to try to keep on top of the launchpad bug reports :p
[13:44] <cjwatson> Yeah :)
[13:44] <seb128> that seems the same sort of fighting windmills
[13:45] <cjwatson> At this point it would be about a month of work doing nothing else just to get the Ubuntu blueprint list vaguely reasonable
[13:45] <smartboyhw> cjwatson, :(
[13:45] <cjwatson> (Not that I don't think users should be able to make feature requests or anything, but blueprints are an awful way to do it)
[13:46] <smartboyhw> We should have a big big note on blueprint registration pages that says "If you want to make feature requests, please report a bug. We can only accept blueprints which are worked on." (That sort of thing, you guys write the wordings)
[13:47] <cjwatson> I'd rather just ACL it
[13:47] <smartboyhw> cjwatson, ACL it then (to ~ubuntu-members please, community people should still be able to use blueprints)
[13:48] <cjwatson> The thing that makes it hard is that any ACL we come up with would have to apply sensibly to projects too
[13:48] <tedg> stgraber, I've tried to start collecting data in a bug 1234731
[13:48] <cjwatson> The members slot might not be terrible, but it'd require discussion and probably argument, and I have so many other things to do ...
[13:52] <smartboyhw> cjwatson, maybe I should spark the discussion?
[13:52] <xnox> cjwatson: i wonder if that's spamming (~8 equivalent blueprints) or failure to find/realise the blueprint was filed =)
[13:52] <smartboyhw> xnox, I saw 244 proposed blueprints filed for the "sprint" that the registrant has set up
[13:52] <cjwatson> xnox: it's probably confused good faith
[13:53] <cjwatson> *very* confused good faith
[13:53] <cjwatson> smartboyhw: you could file an LP bug at least
[13:53] <smartboyhw> cjwatson, sure, will do later
[13:53] <cjwatson> ta
[13:57] <Laney> mlankhorst: which xorg-server is good?
[13:57] <mlankhorst> all of them
[13:58] <mlankhorst> erm what exactly do you mean specifically? :P
[13:58] <Laney> there are two
[13:58] <Laney> https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text=
[13:59] <mlankhorst> erm tjaalton uploaded
[13:59] <tjaalton> yes, delete the older one
[13:59] <Laney> oh indeed
[13:59] <tjaalton> git merge fail, or lack thereof
[14:00] <Laney> they have the same date in .changes
[14:00] <tjaalton> uh
[14:00] <tjaalton> drop both then and I'll reupload
[14:00] <Laney> hang on
[14:00] <smartboyhw> cjwatson, xnox Bug 1234738 for you guys
[14:01] <Laney> tjaalton: tell me the sha256sum of the .dsc
[14:02] <tjaalton> a5b80eaf11c98aef6c4b130fcd907b35a0163cbf965464dcba3be40e8ee2f71e
[14:03] <Laney> doesn't match
[14:03] <tjaalton> huh
[14:03] <cjwatson> smartboyhw: thanks
[14:03] <Laney> https://launchpadlibrarian.net/152224844/xorg-server_1.14.3-3ubuntu1_source.changes https://launchpadlibrarian.net/152225662/xorg-server_1.14.3-3ubuntu1_source.changes
[14:05] <tjaalton> ok drop both then?
[14:05] <Laney> ok
[14:05] <tjaalton> in fact I have an additional change that fixes a crasher with few dupes
[14:05] <Laney> done
[14:09] <tjaalton> uploading a refreshed version
[15:06] <tedg> jodh, So I'm looking at this url-dispatcher crash file, and what's weird to me is that there isn't an UPSTART_JOB env var set.  Does that seem odd to you if it was started by Upstart?
[15:07] <jodh> tedg: are there any upstart variables?
[15:07] <jodh> tedg: certainly sounds like it was not started by upstart :)
[15:07] <tedg> jodh, No, there aren't: https://jenkins.qa.ubuntu.com/job/saucy-touch_ro-maguro-smoke-music-app-autopilot/101/artifact/clientlogs/_usr_lib_arm-linux-gnueabihf_url-dispatcher_url-dispatcher.32011.crash/*view*/
[15:07] <tedg> jodh, It's parent PID is upstart...
[15:07] <tedg> jodh, And the shell is weird as well.
[15:08] <jodh> tedg: you're printing environ from the core file right?
[15:08] <tedg> jodh, I believe apport grabs it from proc in the crash files.
[15:08] <jodh> tedg: don't rely on the apport header for the env - it only shows a small (safe) subset of variables.
[15:09] <tedg> jodh, Ah, okay.
[15:10] <cjwatson> Damn, I had forgotten just how quickly sagari builds stuff - libreoffice in 1h20m
[15:10] <tedg> To get more I need to get to that core then...
[15:10] <jodh> tedg: yup
[15:10] <cjwatson> Although I notice that libreoffice's build times radically improved in 4.1.2
[15:10] <cjwatson> Though on powerpc, not on amd64
[15:11] <tedg> plars, Do the crash files from the autopilot tests get uploaded to daisy?
[15:13] <tedg> If a crash file is created, but never uploaded to daisy, does it really exist?
[15:16] <plars> tedg: no, I don't think it does
[15:17] <tedg> plars, Can it?
[15:17] <plars> tedg: pitti worked on some stuff to make that possible a while back but I had issues with it last time I tried to integrate it. It hasn't been a huge issue so far I don't think but if it important, I can prioritize fixing that
[15:18] <plars> tedg: but it's not going to be something that happens today, for instance, so for now you do have the crash file at least
[15:19] <tedg> plars, I don't think it is critical, but it would be nice.
[15:19] <plars> tedg: ack
[15:20] <tedg> plars, Perhaps ev can add something to errors to note when it's recreated with a know machine ID in the QA lab.
[15:20] <tedg> Those would be probably more reliable results.
[15:20] <ev> tedg: couldn't we just look up the reports by machine ID?
[15:21] <plars> tedg: I'll see about talking to pitti tomorrow (he's eod by now I think) and get unstuck on it as soon as possible
[15:21] <tedg> ev, We could, I was more thinking a little canonical logo or something on the crash listing to highlight it.
[15:22] <ev> cute
[15:22] <plars> tedg: given the hoops necessary to jump through for getting these things uploaded at the moment, I think you can just assume that anything touch on there is one in the lab once we get it working
[15:25] <tedg> jodh, So I do have UPSTART_SESSION, but I don't have UPSTART_JOB
[15:27] <tedg> Wait, show environment, doesn't seem to show the core's environment.
[15:27] <tedg> Bother
[15:27] <jodh> tedg: print environ
[15:28] <tedg> jodh, That just gives me a big negative number.
[15:28] <tedg> Guessing the core doesn't have?
[15:29] <jodh> tedg: try 'print ((char**)'environ@@GLIBC_2.0')[0]'
[15:29] <tedg> Hmm, no symbol table.
[15:29] <tedg> I guess I need debug packages
[15:31] <Laney> ev: Pinged you while you were away, but I guess it got lost — want to check about whoopsie on touch
[15:32] <Laney> wrt. system-settings - the toggle doesn't work; I guess it needs a pkla to authorise the action
[15:32] <Laney> the diagnostics toggle, that is
[15:32] <Laney> but more broadly, do we have whoopsie working on the images atm?
[15:32] <ev> Laney:  yes, lost much IRC data while on holiday
[15:32] <Laney> no worries
[15:32] <Laney> hope you had a good time ;-)
[15:33] <ev> Laney: yes, presumably needs pkla
[15:33] <ev> and yes, it is working on the images
[15:33] <ev> we just don't have armhf retracers deployed yet
[15:33] <ev> but we're receiving data
[15:33] <ev> and thanks, sure did!
[15:33] <jodh> tedg: how easy is it for you to reproduce the problem? You could try the procenv re-exec trick if it's relatively easy: http://upstart.ubuntu.com/cookbook/#determining-why-your-service-fails-to-start
[15:34] <tedg> jodh, Nearly impossible to recreate :-/  Everytime we think we have someway it "fixes" itself on that machine.
[15:34] <jodh> tedg: ie change your job to specify "exec procenv --file=/tmp/procenv.log --exec -- hud...". Rather than --file you can specify --output=syslog or --output=stdout, etc.
[15:34] <jodh> tedg: ok :(
[15:35] <tedg> Sadly, this crash file is the best thing that's happened this month for this bug.
[15:36] <seb128> tedg, can you make the apport hook collect the full /proc/pid/environ?
[15:36] <jodh> tedg: can't we rig a system to auto-reboot constantly checking for the required condition?
[15:36] <tedg> seb128, Trying to get debug symbols to see if I can grab it.
[15:36] <tedg> seb128, If not, yes.
[15:36] <tedg> jodh, Good idea, really it'd just be "any crash files" now :-)
[15:39] <Laney> ev: ok, pkla appreciated then :P
[15:39] <Laney> there's efforts to make sure everything visible in the UI works
[15:40] <seb128> tedg, what are you looking for in that env?
[15:41] <tedg> seb128, There was a theory that the session bus address wasn't getting propagated.
[15:41] <tedg> I'm printing it now.
[15:41] <seb128> tedg, ok, I've it as well
[15:41] <seb128> but if you have it you probably don't need me ;-)
[15:43] <seb128> tedg, jodh: http://paste.ubuntu.com/6188605/
[15:44] <tedg> This does seem more sane overall
[15:44] <tedg> jodh, What's the "JOB" variable for?
[15:44] <seb128> tedg, how did you print it? I've been hacking around, but I would be happy to learn the "clean way" :p
[15:44] <tedg> seb128, I did "print environ[0]" and incremented until I got to NULL
[15:45] <seb128> tedg, ok
[15:45] <seb128> tedg, p (char *)*environ@80
[15:45] <seb128> tedg, that's better :p
[15:45] <tedg> seb128, You're scary :-)
[15:45] <seb128> lol
[15:45] <tedg> Seems like there should be a way to do NULL terminated lists.  But I dont' know it.
[15:45] <seb128> right
[15:45] <seb128> @<len> works though
[15:45] <udevbot> Error: "<len>" is not a valid command.
[15:46] <seb128> you just get a bit of noise at the end
[15:46] <jodh> tedg: that's the event variable that that was set when your job started (recall that 'start on starting foo' actually means 'start on starting JOB=foo').
[15:46] <jodh> tedg: whereas UPSTART_JOB is "self".
[15:47] <tedg> K, so that makes sense.
[15:48] <tedg> I wonder if we're just starting faster than DBus can be ready?
[16:02] <jdstrand> xnox: all the keys in qrt are 13 years or more before being expired
[16:08] <slangasek> jdstrand: so the issue we're seeing is that the certificate embedded in the shim data itself, which chains from Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 to the key actually used for signing (subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher), is expired
[16:08] <slangasek> at least, that's how it appears
[16:09] <slangasek> the other possibility is that we're verifying the expiry on Microsoft Windows UEFI Driver Publisher, but it's not actually in the verification chain
[16:09] <slangasek> difficult to extract this information with the available tools :/
[16:10] <jdstrand> slangasek: ah, that was going to be my next question, if the embedded cert was expired
[16:10] <slangasek> so I think this is probably a bug in sbverify
[16:11] <slangasek> xnox: ^^
[16:13] <slangasek> xnox: what command did you run on bug #1234649 that managed to show you the full certificate details in one go? :)
[16:13] <slangasek> ah, -text -print_certs
[16:18] <lamont>  /usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed
[16:18] <lamont> why does saucy hate me so?
[16:21] <xnox> slangasek: yeap, all in the bug, i figured it's a convenient place to document stuff.
[16:21] <tedg> jodh, Is there a way to make the dbus job not register as "started" until it listens on the socket?
[16:22] <xnox> tedg: hm, we can do post-start script where it checks the socket?
[16:22] <xnox> tedg: we do wish kernel could report to upstart when listen was called on the socket.
[16:24] <tedg> xnox, That works for me... I guess we can try to connect in a loop...
[16:24] <tedg> "Are we there yet?"
[16:24] <xnox> tedg: that.
[16:24] <ev> Laney: where should the pkla live? I don't see any in ubuntu-system-settings
[16:26] <xnox> tedg: i'm not proud of my address, and no post-code envy, but here is an example from mysql daemon that does post-start check: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/mysql-5.5/saucy/view/head:/debian/mysql-server-5.5.mysql.upstart
[16:26] <Laney> ev: what's it going to say?
[16:27] <tedg> xnox, K, trying to think of something silly we can do...
[16:28] <ev> Laney: presumably allow on com.ubuntu.WhoopsiePreferences since we don't have a password dialog (to my knowledge) for auth_admin?
[16:28] <ev> but we don't want that going to the desktop image
[16:28] <Laney> ev: yeah, I mean are you going to do it for the admin group or what?
[16:28] <ev> Laney: yeah, I imagine that would be sufficient.
[16:29] <xnox> tedg: dbus-send to succeed to upstart?!
[16:29] <jodh> tedg: once you can recreate the problem, I wonder if it is worth tweaking the session dbus.conf job to "expect fork" and "--fork" like the system dbus job already does. That may give a "more correct" started event time.
[16:29] <Laney> ev: but you don't want it on the desktop?
[16:29] <Laney> I don't know what package would be good then
[16:29] <Laney> ogra_ might be able to help
[16:29] <ev> Laney: I guess we could do it for the desktop if we're restricting it to the admin group, actually
[16:29] <xnox> jodh: oh, yeah, one must use --fork or daemon with dbus, or patch it to do sigstop, otherwise dbus is declared as started ahead of time.
[16:29] <tedg> jodh, Why would that be more correct?
[16:29] <Laney> ev: if that, then probably policykit-desktop-privileges
[16:29] <Laney> is on the device
[16:30] <ev> cool, I'll have a look
[16:30] <ev> thanks
[16:30] <xnox> tedg: dbus forks after it starts to listen, thus expect fork with --fork will make sure started is emitted only after dbus is ready.
[16:30] <tedg> Oh, let's do that!
[16:30] <xnox> tedg: i'll upload it, shall I ?
[16:30] <tedg> xnox, Please!
[16:31] <tedg> xnox, bug 1234731
[16:31] <xnox> stgraber: i blame you for our day of chasing dbus ^
[16:31] <xnox> =))
[16:34] <xnox> ogra_: ^^^^^
[16:35] <tedg> xnox, I've updated the bug with the end of the IRC conversation
[16:35] <xnox> ack.
[16:49] <xnox> tedg: hm. so i've upgraded and rebooted, there are still 3 session dbus'es started: one by session upstart, one by at-spi2 a11y, one done by "dbus-launch --autolaunch=f07f2326128b8865ee7446354f0f2bcd --binary-syntax --close-stderr"
[16:49] <xnox> the last one is a little bit interesting
[16:49] <tedg> Yeah, the first two I'd expect
[16:49] <tedg> Who's its daddy?
[16:51] <xnox> tedg: better, who's is it's environ. UPSTART_JOB=update-notifier-crash =)
[16:51] <xnox> bang bang, I shot you down.
[16:53] <tedg> xnox, Interesting that it'd start it's own bus, could it not see the current session bus?
[16:56] <xnox> tedg: nope, since it's start on file event.
[16:56] <xnox> tedg: and the semantics we agreed for the .crash file is such that on each boot they are re-emitted =/
[16:57] <tedg> xnox, Ah
[16:57] <xnox> tedg: which is ahead of dbus, so it should do "pre-start exec start dbus"
[16:57] <tedg> xnox, It's almost like dbus needs to be "start on starting starting"
[16:57] <xnox> =)))))
[17:04] <slangasek> jodh: bug #1234743 - so upstart-monitor is out for phone debugging because it depends on gtk; what's the best way for cking to get debugging information about what events upstart is spending its time on?
[17:23] <stgraber> slangasek: initctl log-priority debug and look at whatever log file is used to record upstart's output (equivalent of ~/.xsession_errors on a desktop install)?
[17:26] <stgraber> slangasek: do you know anything about a udev rule that'd currently make the active session user have write access to pretty much all of /dev?
[17:26] <stgraber> slangasek: I just noticed that my user has write access to /dev/sda and that scares me a bit
[17:27] <stgraber> slangasek: (then I checked and I can't find a single file in /dev I don't have write access to... switching to another VT reverts that ACL, so it looks like some logind/udev thing)
[17:27] <slangasek> stgraber: um.  that's certainly a bug.
[17:27] <slangasek> yeah, would be related to logind
[17:27]  * stgraber tries a guest session to see how scary that bug is
[17:28] <stgraber> oh wow
[17:28] <stgraber> http://paste.ubuntu.com/6189025/
[17:29] <stgraber> so that's insanely scary
[17:29] <cjwatson> holy crap
[17:29]  * cjwatson runs away for dinner before accidentally getting dragged into this
[17:42] <xnox> jodh: slangasek: is it evil to use wait-for-state in usersessions? bug 1234841
[17:44] <slangasek> xnox: if you can avoid it, that would certainly be better.  Are you trying to instantiate the system service from the user session...?
[17:46] <xnox> slangasek: no, crash reporter is an instances job starting on file events. On inital login, if there are .crash reports, all of the crash dialogs are launched before anything else.
[17:47] <xnox> slangasek: so i cannot do " and started dbus"
[17:47] <slangasek> xnox: shouldn't that be fixed by starting dbus before the file bridge?
[17:47] <xnox> slangasek: yet, if crash dialog script is executed ahead of dbus, it autolaunches one.
[17:50] <xnox> slangasek: could do. it does seem like it's most wise to make "started dbus" our session startup event to be honest.
[17:51] <xnox> slangasek: but filebridge doesn't need dbus =/
[17:51] <xnox> only crash-reporter needs it, which may or may not be installed (well it is on ubuntu desktop)
[17:52] <slangasek> xnox: what's the downside of making file-bridge start after dbus?
[17:52] <slangasek> we already assume all user sessions have dbus, right?  So an artificial ordering constraint just means certain jobs will start a little later
[17:53] <slangasek> I think that's way better than pulling wait-for-state into the mix
[17:55] <xnox> slangasek: the downside will be that update-notifier-crash, unicast-local-avahi, update-notifier-release - are started later, and/or miss (modified, deleted events) [the latter doesn't matter as they only match on create at the moment)
[17:55] <xnox> but yeah, it's more lightweight than adding wait-for-state.
[17:57] <slangasek> xnox: right, I don't think we really need to care about triggering jobs on file modifications / deletions that happen before the session is even fully started
[17:58] <xnox> slangasek: ack. i'll do that then.
[17:59] <ari-tczew> is there any bug-fixed statistic?
[18:01] <ari-tczew> in the past was a page with bug fixed per e-mail address, but I didn't find it now
[18:01] <xnox> ari-tczew: there are some, but they are vague, as launchpad doesn't track bug-fixed per-package-version. So sometimes it's hard to tell if the bugs were fixed in current dev release, or a clean-up of bugs was done (e.g. 'oh this was fixed for years')
[18:21] <stgraber> for anyone who read my messsage earlier about /dev being writable for any logged in user, the cause was a broken udev rule in the adb package, fixed with: https://launchpad.net/ubuntu/+source/android-tools/4.2.2+git20130218-3ubuntu15
[18:31] <INdek> hey, i want to improve my coding skills and i thought about contributing to the ubuntu project would be a good idea, how do i start
[18:31] <robru> jdstrand, ping
[18:38] <robru> jdstrand, I'm heading out for lunch, but in case you're around: https://bugs.launchpad.net/ubuntu/+source/unity-webapps-qml/+bug/1206268/comments/35
[18:44] <jdstrand> robru: ack. I'll respond in the bug
[18:48] <barry> doko: https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/5014145
[18:48] <barry> doko: is that still a problem?  (built fine locally in sbuild with both --arch amd64 and i386)
[19:13] <chiluk> hey guys unmodified mysql sources  get a build failure from tests failing.. is there a trick to make it build?  Clearly launchpad can get it to build.
[19:14] <lamont> after saucy's brasero says that it's 100% don buring the data disk, and that it's "creating image checksum", I find myself wondering what it's been doing for the last several minutes
[19:31] <chiluk> mdeslaur.. I can't build the mysql that you checked in for precise using pbuilder or sbuild... a few testcases are failing... do you have any insite on what needs to happen to get it to build?
[19:31] <lenios> chiluk, you mean the mysql package source or the mysql sources?
[19:33] <lenios> mysql source package would be the correct term, though
[19:33] <chiluk> the mysql-5.5 sources that get pulled by pull-lp-source mysql-5.5 precise can not be built into binaries using sbuild or pbuilder
[19:34] <lenios> you mean 5.5.34?
[19:34] <chiluk> i in particular am running pbuilder-dist precise build mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
[19:35] <chiluk> lenios no the sources that are currently in ubuntu archive are versioned mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
[19:35] <lenios> 5.5.32-0ubuntu0.12.04.2 is available
[19:36] <lenios> i don't see why you woudn't be able to build
[19:36] <chiluk> ok lenios now try building the dsc file that you grabbed.  it doesn't build.
[19:36] <chiluk> lenios why don't you just try it..
[19:36] <chiluk> and if you get it to work let me know how you did it.
[19:37] <chiluk> because it's not building for me or another person I know.
[19:37] <chiluk> if you figure out what is going wrong for us let me know
[19:37] <chiluk> or better yet create a patch .
[19:44] <infinity> chiluk: Which kernel are you using to build?  Note that the buildds run precise.
[19:44] <chiluk> running on precise
[19:44] <chiluk> hmm I am running the 3.11 kernel.
[19:45] <infinity> chiluk: (Testing here on saucy now to see, but if it fails tests on saucy and not precise, I'm assuming the kernel is to blame)
[19:45] <chiluk> infinity that's a really good insite.
[19:45] <chiluk> I'll reboot to something much earlier.
[19:45] <chiluk> infinity, they build takes forever..
[19:46] <chiluk> you are in for a world of hurt fyi
[19:46] <infinity> chiluk: Given that it built on all arches on the buildds only two months ago, if it does fail now due to a userspace change, shouldn't be hard to track down.  But the kernel's the most likely culprit.
[19:46] <chiluk> that's a good check
[19:47] <chiluk> it's failing trying to pull cores
[19:47] <infinity> chiluk: You consider 58 minutes "forever"?  Kids these days. :)
[19:47] <chiluk> seriously man you aren't that much older than me... I just age more gracefully
[19:47] <infinity> Ouch.
[19:47] <chiluk> also on my machine it's more like 4 hours till it hits the failure
[19:49] <chiluk> also the test don't seem to be multi-threaded, and are heavily IO dependent
[19:49] <infinity> chiluk: multicore machine where you neglected to export DEB_BUILD_OPTIONS="parallel=$(nproc)" before running sbuild?
[19:49] <chiluk> infinity that's in my bashrc.
[19:49] <infinity> (58 minutes on the x86 buildds, I expect just shy of 2h on my laptop)
[19:49] <chiluk> the tests aren't multi-threaded
[19:49] <chiluk> maybe my hard drive is just crap.
[19:49] <chiluk> it's building on a spinning disk
[19:50] <infinity> So are the buildds.
[19:50] <infinity> And my laptop. :P
[19:50] <chiluk> I think I'll put the pbuilder builddir in tmpfs
[19:50] <infinity> I do build in tmpfs though, yes.
[19:50] <chiluk> I bet that's it.
[19:50] <lamont> infinity: the buildds are taking full advantage of the cciss caching, though
[19:50] <infinity> Anyhow.  I expect my test on a saucy kernel will also fail.
[19:50] <chiluk> my hard drive is just pegged
[19:50] <infinity> lamont: Only roseapple and allspice.
[19:50] <lamont> oh
[19:50] <infinity> lamont: The other x86 buildds have much slower cheap SATA.
[19:50] <chiluk> the build is not the slow part
[19:50] <chiluk> it's all the tests
[19:50] <lamont> ah
[19:52] <infinity> chiluk: Anyhow, I'm into the testsuite now on 3.11 to see if my system agrees with yours.  If you try on a 3.2 kernel, that would be nice.
[19:52] <chiluk> yeah going to cancel my build.. add tmpfs and reboot into 3.2... I hope it still works.
[19:53] <infinity> chiluk: Depending on the failure, it could be just a broken test that does something newer kernels don't like, or an actual bug we should fix in the package to work sanely on newer kernels.  I guess we'll see.
[19:53] <lenios> i don't see why the kernel would create such a difference
[19:53] <infinity> lenios: Depends on what test is failing...
[19:54] <chiluk> infinity
[19:54] <chiluk> mysql-5.5_5.5.32-0ubuntu0.12.04.1.dsc
[19:54] <chiluk> fuck damn cp/paste
[19:54] <chiluk> worker[1] Trying to dump core for [mysqltest - pid: 7596, winpid: 7596]
[19:54] <chiluk> worker[1] Trying to dump core for [mysqld.1 - pid: 7504, winpid: 7504]
[19:54] <chiluk> worker[1] Trying to dump core for [mysqld.2 - pid: 7507, winpid: 7507]
[19:54] <chiluk> rpl.rpl_innodb_bug28430 'mix'            [ fail ]  timeout after 900 seconds
[19:55] <chiluk> my world for a mouse and middle click
[19:55] <chiluk> that's one of the tests that's failing
[19:55] <infinity> chiluk: Curious.
[20:27] <jono> hi everyone
[20:27] <jono> FYI: UDS dates announced on ubuntu-devel
[20:37] <jtaylor> is it a virtual uds or a real one? neither the mail nor the page make that easy to find out
[20:38] <jtaylor> hm 2pm-8pm probably means virtual
[20:44] <infinity> chiluk: So, back to the drawing board on that theory.  mysql-5.5/precise just built fine here in a precise sbuild w/ saucy kernel.
[20:45] <infinity> chiluk: http://lucifer.0c3.net/~adconrad/mysql-5.5_5.5.32-0ubuntu0.12.04.1_amd64.build
[20:48] <infinity> chiluk: And also only took an hour.  Your hardware hates you. :P
[20:51] <chiluk> yes it does.
[20:51] <chiluk> I swear I was a tester in another life
[20:53] <chiluk> infinity as you seem to be the only one I know that can actually successfully build can you attempt building any of the patches available here? http://bugs.launchpad.net/bugs/1121874
[20:54] <chiluk> I was asked to take a look at why it wasn't building by stokachu,
[21:36] <bdmurray> seb128: could you update bug 1075923 with SRU information?
[21:36] <seb128> bdmurray, oh, sure, sorry about that
[21:36] <bdmurray> seb128: no problem
[21:37] <seb128> bdmurray, I though about it after upload the other day, and then got busy and forgot about it
[21:38] <chiluk> infinity crazy question do you have jumbo frames enabled?
[21:42] <seb128> bdmurray, done
[21:43] <infinity> chiluk: If that's something I have to do manually, probably not.
[21:43] <chiluk> it is.
[21:43] <chiluk> it's a stab in the dark
[21:43] <chiluk> but it tends to shoot me in the foot often.
[21:43] <chiluk> it's the sacrifice I make for 120mb/sec to my nfs server
[21:46] <seb128> ev, could you look at https://bugs.launchpad.net/activity-log-manager/+bug/1198681? it's high ranked on the saucy issues on e.u.c
[21:53] <ev> seb128: will do in the morning
[21:53] <seb128> ev, thanks
[21:53] <ev> sure thing
[22:48] <sconklin> @pilot out