=== freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === _salem is now known as salem_ === catbus is now known as Guest70252 === salem_ is now known as _salem === jono is now known as Guest53113 [07:22] what dictates that :all builds are run on i386 and not on, say, amd64? [07:23] tjaalton, tradition [07:24] makes sense, but would it then make sense to let amd64 build handle it? [07:24] that would at least fix the libx11 build failure, where w3m crashes on i386 building docs :) [07:24] though not enough of a reason to switch of course [07:56] 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] jodh: ^ maybe we should finally fix https://jenkins.qa.ubuntu.com/job/saucy-adt-upstart/81/ARCH=amd64,label=adt/artifact/results/ ? [07:57] xnox: looking at it now... [07:58] 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 === iahmad_ is now known as iahmad|afk [08:38] xnox, hey, are you looking at https://bugs.launchpad.net/ubuntu/+source/ubuntu-wallpapers/+bug/1216223 ? [08:38] Ubuntu bug 1216223 in ubuntu-wallpapers (Ubuntu) "Wallpapers for saucy salamander are being modified the wrong way, worsening their quality" [Medium,Confirmed] [08:38] (I wonder if that's something we should fix before release) [08:38] I mailed the guy who gave us the compressed versions [08:38] but he didn't get back to me [08:39] Laney, is that somebody from our design team? [08:39] seb128: I don't know who it is [08:39] it was on the mail you forwarded to me [08:39] might have CCed you on my enquiry [08:40] yeah, just found the bug back [08:40] bug->email [08:41] mpt, ^ do you know who in design could help on that? [08:41] seb128, jnick_tait [08:41] mpt, thanks [08:42] 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] some guy did some adjustments to make the size smaller [08:43] xnox, I've no idea what the process is or what happened to them [08:43] =/ i see. [08:43] I think there was a size budget of 5M or so [08:44] Laney: i understand a size budget on the default wallpaper, but not the community ones. [08:44] why? [08:44] they're installed by default too [08:48] 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. === iahmad|afk is now known as iahmad [08:50] xnox, the budget was to spare CD size when we still had that target [08:50] not sure it still makes sense nowadays, though it's good to keep some control there [08:50] otherwise we are going to drift [08:51] I'm not aware that we have just let it go completely === iahmad is now known as iahmad|afk [09:10] tjaalton: Historically we've found that more arch all builds have actually worked on i386. The correlation isn't perfect [09:38] cjwatson: ah, ok [09:49] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox [10:13] slangasek: another nfs/mountall bug #1234613 [10:13] bug 1234613 in mountall (Ubuntu) "NFS shares are not mounted at boot" [Undecided,New] https://launchpad.net/bugs/1234613 [10:29] jodh: hey, I filed a bug on upstart and upstart-dbus-bridge yesterday, have you had a chance to see it? [10:30] 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] jodh: which version of upstart were you running? [10:31] zyga: version in saucy [10:31] jodh: I created a job as described in the bug report [10:31] jodh: and I only saw the stream of events after I started the bridge manually with --always [10:32] zyga: as I say, I cannot recreate that behaviour. [10:32] hmm [10:35] 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] zyga: identified your problem - bug updated. [10:37] jodh: this bug? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234393 [10:37] Ubuntu bug 1234393 in upstart (Ubuntu) "upstart-dbus-bridge never forwards events without passing --always" [Undecided,Invalid] [10:38] zyga: yes [10:38] hmm === iahmad|afk is now known as iahmad [10:38] so how can I get system dbus events? [10:38] can I? [10:41] xnox: can you for me sponsor something @main? [10:42] jodh: so does that mean that it's not possible to listen to signals on the system bus from system jobs? [10:43] 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] jodh: well, why don't we? [10:43] ari-tczew: can I has url/link? [10:44] jodh: and is the solution to have a job that runs that that my other job needs to depend on? [10:44] zyga: what system dbus events are you listening on? [10:44] xnox: I wanted to listen to network manager events [10:44] zyga: more specific? [10:45] 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] xnox: StateChanged [10:45] xnox: https://code.launchpad.net/~ari-tczew/ubuntu/saucy/iptables/lp-1228525-1134554-1187177/+merge/187859 [10:45] zyga: system-wide events we already have "net-device-added|changed|down|removed|up" [10:46] xnox: that's not the same [10:46] 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] that's weird, i would have expected for you to see them. [10:47] xnox: is there a reason why we're not running the system level dbus-upstart bridge or is this just an oversight? [10:47] xnox: I see up events though [10:48] 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] zyga: why are you using a system job? do you have to be root? [10:48] xnox: yes [10:48] xnox: well, it's very powerful, no need to have a silly daemon to lurk for that signal [10:49] xnox: unless there's a security issue I think it's just as valid as the session bus, user bridge [10:49] zyga: problem is that when we start system-dbus bridge on system level, those events are replayed to the session-init's =/ [10:51] hmm? [10:51] I'm not quite sure I understand [10:51] 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] ah [10:52] hmm [10:52] well that's too bad [10:52] I'll think about a workaround [10:52] jodh: is there a bug open on that? === _salem is now known as salem_ [10:54] 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] jodh: I've filed https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1234653 [10:54] 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] Ubuntu bug 1234653 in upstart (Ubuntu) "upstart-dbus-bridge --system is not started on boot" [Undecided,New] === salem_ is now known as _salem [10:54] 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] xnox: yeah, I can confirm that [10:55] xnox: but [10:55] when eth0 went down, from network-manager. [10:55] xnox: could it be possible that nothing is listening to that so it's not being sent somehwo? [10:55] somehow [10:55] 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] zyga: i created "start on net-device-down \n exec env" and it wasn't run. [10:55] zyga: yeap. =) [10:56] xnox: won't that have the security issue that we described by jodh above? [10:56] zyga: you need that bridge, so start it ;-) [10:56] xnox: still it will work :) I'll give that a TRY [10:56] try [10:56] caps [10:56] zyga: sure it will, but that's your choice ;-) [10:59] http://paste.ubuntu.com/6187673/ [11:00] modified session job, I'll give it a try [11:03] yeah, it works like a charm now [11:07] jdstrand: slangasek: psivaa is reporting that today's desktop daily is failing SecureBOot certificate validation: [11:07] $ sbverify --cert microsoft-uefica-public.pem /mnt/EFI/BOOT/BOOTx64.EFI [11:07] warning: data remaining[1230256 vs 1355656]: gaps between PE/COFF sections? [11:07] PKCS7 verification failed [11:07] 139756278539968:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate has expired [11:07] Signature verification failed [11:08] jdstrand: can it be that certs in lp:qa-regression-testing/notes_testing/secure-boot/keys are out of date? [11:12] 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] ari-tczew: this http://release.debian.org/transitions/html/libtiff5.html [11:16] 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] 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 === freeflying is now known as freeflying_away [11:18] 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] Right [11:19] cjwatson: ok thanks [11:24] xnox: jdstrand: slangasek: the shim signature verification happens with today's *both desktop and server images.. [11:25] psivaa: "happens" as in passes or fails? [11:25] xnox: fails [11:25] sorry [11:26] That's expected, same shim [11:26] I mean, I'd be very surprised if they differed :) [11:26] ok :), was thinking if that'd indicate cert expiry [11:30] 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] ari-tczew: ah, that wouldn't suprise me [11:32] tumbleweed: is it possible to get a small whish there? counting search result, like: Sponsorships: 123 [11:52] slangasek: psivaa: precise 12.04.2 and raring are also failing sbverify in the same way (expired cert) [11:59] xnox: should do I update d/changelog @iptables? [12:01] ari-tczew: nah, it's ok. [12:36] xnox: thanks for checking.. we dont have this test for other releases than the dev release [12:36] TheMuso: do we want bug 1231367 and bug 1231365 [12:36] bug 1231367 in at-spi2-atk (Ubuntu) "Sync at-spi2-atk 2.10.0-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1231367 [12:36] bug 1231365 in atk1.0 (Ubuntu) "Sync atk1.0 2.10.0-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1231365 [12:36] psivaa: but precise-daily should have been running this?! [12:37] it might've had a later sig from the last point release? [12:37] xnox: no, precise daily uses different script for the test. may be we should update that [12:40] psivaa: i thought static-iso-validation.py thing is generic enough to run against precise images as well. [12:41] (it has many guards and checks for things that are only application to e.g. precise or quantal and up and etc) [12:41] xnox: yea i think we have two versions of them :) one of which does not have this test [12:42] /o\ [12:42] xnox: i'll try and update that === freeflying_away is now known as freeflying [12:54] xnox: did you upload iptables to saucy-proposed? [12:54] ari-tczew: check the queue. [12:55] ari-tczew: you know where, right? [13:09] xnox: if you mean https://launchpad.net/ubuntu/saucy/+queue then I don't see or have wrong URL [13:09] ?queue_state=1 [13:09] ahh unapproved [13:09] ari-tczew: drop down "unapproved" click apply. [13:09] ok got it [13:10] =) [13:10] freeze... [13:10] xnox: don't mind pm speaking? [13:11] stgraber, So we've got an issue where it seems that, randomly, some upstart jobs can't connect to dbus. [13:12] stgraber, When we get crash signatures they don't seem to have DBUS_SESSION_BUS* in their environment. [13:12] stgraber, Even if they're "start on started dbus" === iahmad is now known as iahmad|afk [13:12] stgraber, Do you have any idea how that could happen? [13:27] hello [13:28] i just read the following article: [13:28] http://www.phoronix.com/scan.php?page=news_item&px=MTQ3NTU [13:28] and i like the suggestion at the end of it: [13:28] "Matthew additionally suggests as an option Canonical just drop XMir entirely and focus their resources on the Mir-based Unity 8 desktop." [13:29] so, any chance you could do that? just drop XMir entirely and focus on pure Mir and Unity 8? === _salem is now known as salem_ [13:39] OK, weird, but I'm seeing the latest 5 blueprints in https://launchpad.net/ubuntu/ about the same thing [13:39] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin === smartboyhw changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 2 released | Archive: frozen | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: xnox, sconklin [13:40] (It's Beta 2 certainly;)) [13:41] I wish I could restrict blueprint registration to developers [13:41] cjwatson, Ubuntu Members maybe [13:41] Maybe [13:43] 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] And various well-meaning bug triagers have been encouraging that behaviour [13:44] cjwatson, I use to try to keep on top of the launchpad bug reports :p [13:44] Yeah :) [13:44] that seems the same sort of fighting windmills [13:45] 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] cjwatson, :( [13:45] (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] 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] I'd rather just ACL it [13:47] cjwatson, ACL it then (to ~ubuntu-members please, community people should still be able to use blueprints) [13:48] The thing that makes it hard is that any ACL we come up with would have to apply sensibly to projects too [13:48] stgraber, I've tried to start collecting data in a bug 1234731 [13:48] bug 1234731 in dbus (Ubuntu) "DBus jobs not setting environment variables" [Undecided,Confirmed] https://launchpad.net/bugs/1234731 [13:48] 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] cjwatson, maybe I should spark the discussion? [13:52] cjwatson: i wonder if that's spamming (~8 equivalent blueprints) or failure to find/realise the blueprint was filed =) [13:52] xnox, I saw 244 proposed blueprints filed for the "sprint" that the registrant has set up [13:52] xnox: it's probably confused good faith [13:53] *very* confused good faith [13:53] smartboyhw: you could file an LP bug at least [13:53] cjwatson, sure, will do later [13:53] ta [13:57] mlankhorst: which xorg-server is good? [13:57] all of them [13:58] erm what exactly do you mean specifically? :P [13:58] there are two [13:58] https://launchpad.net/ubuntu/saucy/+queue?queue_state=1&queue_text= === psivaa is now known as psivaa-afk [13:59] erm tjaalton uploaded [13:59] yes, delete the older one [13:59] oh indeed [13:59] git merge fail, or lack thereof [14:00] they have the same date in .changes [14:00] uh [14:00] drop both then and I'll reupload [14:00] hang on [14:00] cjwatson, xnox Bug 1234738 for you guys [14:00] bug 1234738 in Launchpad itself "Blueprint Registration should have been able to set ACLs" [Undecided,New] https://launchpad.net/bugs/1234738 [14:01] tjaalton: tell me the sha256sum of the .dsc [14:02] a5b80eaf11c98aef6c4b130fcd907b35a0163cbf965464dcba3be40e8ee2f71e [14:03] doesn't match [14:03] huh [14:03] smartboyhw: thanks [14:03] https://launchpadlibrarian.net/152224844/xorg-server_1.14.3-3ubuntu1_source.changes https://launchpadlibrarian.net/152225662/xorg-server_1.14.3-3ubuntu1_source.changes === mterry_ is now known as mterry [14:05] ok drop both then? [14:05] ok [14:05] in fact I have an additional change that fixes a crasher with few dupes [14:05] done [14:09] uploading a refreshed version === salem_ is now known as _salem === psivaa-afk is now known as psivaa === _salem is now known as salem_ === freeflying is now known as freeflying_away === salem_ is now known as _salem [15:06] 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] tedg: are there any upstart variables? [15:07] tedg: certainly sounds like it was not started by upstart :) [15:07] 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] jodh, It's parent PID is upstart... [15:07] jodh, And the shell is weird as well. [15:08] tedg: you're printing environ from the core file right? [15:08] jodh, I believe apport grabs it from proc in the crash files. [15:08] tedg: don't rely on the apport header for the env - it only shows a small (safe) subset of variables. [15:09] jodh, Ah, okay. [15:10] Damn, I had forgotten just how quickly sagari builds stuff - libreoffice in 1h20m [15:10] To get more I need to get to that core then... [15:10] tedg: yup [15:10] Although I notice that libreoffice's build times radically improved in 4.1.2 [15:10] Though on powerpc, not on amd64 [15:11] plars, Do the crash files from the autopilot tests get uploaded to daisy? [15:13] If a crash file is created, but never uploaded to daisy, does it really exist? === mpt_ is now known as mpt [15:16] tedg: no, I don't think it does [15:17] plars, Can it? [15:17] 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] 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] plars, I don't think it is critical, but it would be nice. [15:19] tedg: ack [15:20] 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] Those would be probably more reliable results. [15:20] tedg: couldn't we just look up the reports by machine ID? [15:21] 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] ev, We could, I was more thinking a little canonical logo or something on the crash listing to highlight it. [15:22] cute [15:22] 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] jodh, So I do have UPSTART_SESSION, but I don't have UPSTART_JOB [15:27] Wait, show environment, doesn't seem to show the core's environment. [15:27] Bother [15:27] tedg: print environ [15:28] jodh, That just gives me a big negative number. [15:28] Guessing the core doesn't have? [15:29] tedg: try 'print ((char**)'environ@@GLIBC_2.0')[0]' [15:29] Hmm, no symbol table. [15:29] I guess I need debug packages [15:31] ev: Pinged you while you were away, but I guess it got lost — want to check about whoopsie on touch [15:32] wrt. system-settings - the toggle doesn't work; I guess it needs a pkla to authorise the action [15:32] the diagnostics toggle, that is [15:32] but more broadly, do we have whoopsie working on the images atm? [15:32] Laney: yes, lost much IRC data while on holiday [15:32] no worries [15:32] hope you had a good time ;-) [15:33] Laney: yes, presumably needs pkla [15:33] and yes, it is working on the images [15:33] we just don't have armhf retracers deployed yet [15:33] but we're receiving data [15:33] and thanks, sure did! [15:33] 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] jodh, Nearly impossible to recreate :-/ Everytime we think we have someway it "fixes" itself on that machine. [15:34] 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] tedg: ok :( [15:35] Sadly, this crash file is the best thing that's happened this month for this bug. [15:36] tedg, can you make the apport hook collect the full /proc/pid/environ? [15:36] tedg: can't we rig a system to auto-reboot constantly checking for the required condition? [15:36] seb128, Trying to get debug symbols to see if I can grab it. [15:36] seb128, If not, yes. [15:36] jodh, Good idea, really it'd just be "any crash files" now :-) [15:39] ev: ok, pkla appreciated then :P [15:39] there's efforts to make sure everything visible in the UI works [15:40] tedg, what are you looking for in that env? [15:41] seb128, There was a theory that the session bus address wasn't getting propagated. [15:41] I'm printing it now. [15:41] tedg, ok, I've it as well [15:41] but if you have it you probably don't need me ;-) [15:43] tedg, jodh: http://paste.ubuntu.com/6188605/ [15:44] This does seem more sane overall [15:44] jodh, What's the "JOB" variable for? [15:44] tedg, how did you print it? I've been hacking around, but I would be happy to learn the "clean way" :p [15:44] seb128, I did "print environ[0]" and incremented until I got to NULL [15:45] tedg, ok [15:45] tedg, p (char *)*environ@80 [15:45] tedg, that's better :p [15:45] seb128, You're scary :-) [15:45] lol [15:45] Seems like there should be a way to do NULL terminated lists. But I dont' know it. [15:45] right [15:45] @ works though [15:45] Error: "" is not a valid command. [15:46] you just get a bit of noise at the end [15:46] 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] tedg: whereas UPSTART_JOB is "self". [15:47] K, so that makes sense. [15:48] I wonder if we're just starting faster than DBus can be ready? [16:02] xnox: all the keys in qrt are 13 years or more before being expired [16:08] 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] at least, that's how it appears [16:09] 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] difficult to extract this information with the available tools :/ [16:10] slangasek: ah, that was going to be my next question, if the embedded cert was expired [16:10] so I think this is probably a bug in sbverify [16:11] xnox: ^^ [16:13] xnox: what command did you run on bug #1234649 that managed to show you the full certificate details in one go? :) [16:13] bug 1234649 in shim-signed (Ubuntu) "UEFI shim verification against microsoft-uefica-public.pem fails with 20131003 saucy images" [Undecided,New] https://launchpad.net/bugs/1234649 [16:13] ah, -text -print_certs [16:18] /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] why does saucy hate me so? [16:21] slangasek: yeap, all in the bug, i figured it's a convenient place to document stuff. [16:21] jodh, Is there a way to make the dbus job not register as "started" until it listens on the socket? [16:22] tedg: hm, we can do post-start script where it checks the socket? [16:22] tedg: we do wish kernel could report to upstart when listen was called on the socket. [16:24] xnox, That works for me... I guess we can try to connect in a loop... [16:24] "Are we there yet?" [16:24] tedg: that. [16:24] Laney: where should the pkla live? I don't see any in ubuntu-system-settings [16:26] 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] ev: what's it going to say? [16:27] xnox, K, trying to think of something silly we can do... [16:28] Laney: presumably allow on com.ubuntu.WhoopsiePreferences since we don't have a password dialog (to my knowledge) for auth_admin? [16:28] but we don't want that going to the desktop image [16:28] ev: yeah, I mean are you going to do it for the admin group or what? [16:28] Laney: yeah, I imagine that would be sufficient. [16:29] tedg: dbus-send to succeed to upstart?! [16:29] 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] ev: but you don't want it on the desktop? [16:29] I don't know what package would be good then [16:29] ogra_ might be able to help [16:29] Laney: I guess we could do it for the desktop if we're restricting it to the admin group, actually [16:29] 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] jodh, Why would that be more correct? [16:29] ev: if that, then probably policykit-desktop-privileges [16:29] is on the device [16:30] cool, I'll have a look [16:30] thanks [16:30] 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] Oh, let's do that! [16:30] tedg: i'll upload it, shall I ? [16:30] xnox, Please! [16:31] xnox, bug 1234731 [16:31] bug 1234731 in dbus (Ubuntu) "DBus jobs not setting environment variables" [Undecided,Confirmed] https://launchpad.net/bugs/1234731 [16:31] stgraber: i blame you for our day of chasing dbus ^ [16:31] =)) [16:34] ogra_: ^^^^^ [16:35] xnox, I've updated the bug with the end of the IRC conversation [16:35] ack. [16:49] 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] the last one is a little bit interesting [16:49] Yeah, the first two I'd expect [16:49] Who's its daddy? [16:51] tedg: better, who's is it's environ. UPSTART_JOB=update-notifier-crash =) [16:51] bang bang, I shot you down. [16:53] xnox, Interesting that it'd start it's own bus, could it not see the current session bus? [16:56] tedg: nope, since it's start on file event. [16:56] tedg: and the semantics we agreed for the .crash file is such that on each boot they are re-emitted =/ [16:57] xnox, Ah [16:57] tedg: which is ahead of dbus, so it should do "pre-start exec start dbus" [16:57] xnox, It's almost like dbus needs to be "start on starting starting" [16:57] =))))) === _salem is now known as salem_ [17:04] 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:04] bug 1234743 in upstart (Ubuntu) "init on samsung galaxy nexus is busy and consuming memory when playing an mp4" [High,New] https://launchpad.net/bugs/1234743 [17:23] 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] 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] slangasek: I just noticed that my user has write access to /dev/sda and that scares me a bit [17:27] 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] stgraber: um. that's certainly a bug. [17:27] yeah, would be related to logind [17:27] * stgraber tries a guest session to see how scary that bug is [17:28] oh wow [17:28] http://paste.ubuntu.com/6189025/ [17:29] so that's insanely scary [17:29] holy crap [17:29] * cjwatson runs away for dinner before accidentally getting dragged into this [17:42] jodh: slangasek: is it evil to use wait-for-state in usersessions? bug 1234841 [17:42] bug 1234841 in upstart (Ubuntu) "crash reports pop-up ahead of desktop loading, or atleast dbus being available" [High,Confirmed] https://launchpad.net/bugs/1234841 [17:44] 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] 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] slangasek: so i cannot do " and started dbus" [17:47] xnox: shouldn't that be fixed by starting dbus before the file bridge? [17:47] slangasek: yet, if crash dialog script is executed ahead of dbus, it autolaunches one. [17:50] slangasek: could do. it does seem like it's most wise to make "started dbus" our session startup event to be honest. [17:51] slangasek: but filebridge doesn't need dbus =/ [17:51]