[00:03] <cjwatson> ddebs> Ah, now that I catch up on one of the sysadmin channels I see it was handled there.
[00:52] <slangasek> stgraber: you have bug #1181789 assigned to yourself for raring; do you still mean to follow through on it
[00:52] <ubot2`> Launchpad bug 1181789 in upstart (Ubuntu Raring) "second call of 'initctl start' leads to fork instead of exec ('mount: / is busy' during shutdown)" [Critical,Triaged] https://launchpad.net/bugs/1181789
[00:52] <slangasek> ?
[02:14] <infinity> cjwatson: Agreed on carobness.  However I go about that.
[02:41] <stgraber> slangasek: ah yeah, I suppose I should SRU that.
[02:41] <stgraber> slangasek: it's one of those tasks I opened because the bug is bad and really should be SRUed, but AFAIK nobody other than me reported it on raring so it's not very pressing.
[06:07] <slangasek> stgraber: no, there were lots of other reports of this issue in raring (see the now-duped bug); if you're not going to SRU it, please tell me and I'll take care of it.
[08:15] <xnox> slangasek: stgraber: we should push out raring sru with all the fixes that needed to go in. as far as I remember raring sru never validated.
[09:09] <cjwatson> infinity: According to RT#53566 you should actually have carob access already ...
[09:10] <cjwatson> infinity: As in, it's supposed to be based on ubuntu_archive group membership, which you have
[10:28] <xnox> Which kylin seeds are authoritative? lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-meta or lp:~ubuntukylin-members/ubuntu-seeds/ubuntukylin.saucy ?
[10:28] <smartboyhw> xnox, I heard that seeds will be used at 14.04 LTS
[10:28] <smartboyhw> So, probably the first link
[10:29] <smartboyhw> (For Kylin)
[10:29] <cjwatson> I sincerely hope it's the second
[10:29] <cjwatson> Maintaining metapackages by hand in bzr is daft
[10:29] <smartboyhw> I actually questioned them before
[10:29] <xnox> cjwatson: both have recentish commits =/
[10:29] <cjwatson> Send them to me, I can supply clue on these matters :)
[10:30] <xnox> cjwatson: i guess they do maintain something for their precise spins.
[12:59] <infinity> cjwatson: Ahh, well, then maybe I just need to figure out what that means and use it. :P
[12:59] <infinity> cjwatson: I do indeed have access to the machine.
[13:00] <cjwatson> infinity: Logs are in /srv/launchpad.net-logs/production/<blah>
[13:00] <cjwatson> infinity: You may want to lift ~cjwatson/bin/rtail (which I cargo-culted from wgrant, in turn)
[13:01] <cjwatson> infinity: Stuff in /home/archvsync/scripts/ shows where the logs are rsynced from, in cases where you can't wait for the regular rsyncs
[13:01] <infinity> cjwatson: Shiny.  This should prove handy.
[13:02] <cjwatson> The copy logs from yesterday were in production/ackee/launchpad/celeryd-production_launchpad_job.log*
[13:02] <cjwatson> And of course you'll probably like production/alphecca/buildd-manager.log*
[13:03] <infinity> Very tempted to symlink alpaca to alphecca.
[13:05] <cjwatson> It's owned by archvsync, you can't :P
[13:05] <cjwatson> Though I guess you have a homedir
[13:18] <tumbleweed> what needs to be kicked to get ncbi-tools6 to migrate? It's complaining about libvibrant6 being out of date, but I don't see that in Packages
[13:21] <cjwatson> Oh, I think last time I looked at that it was proposed-internal NBS
[13:21] <cjwatson> Let me have a poke
[13:22] <tumbleweed> I'd understand libvibrant6a being NBS, but libvibrant6 is long gone
[13:22]  * tumbleweed has no idea what proposed-internal NBS means :P
[13:22] <cjwatson> So
[13:22] <cjwatson> We track not-built-from-source (NBS) binaries in saucy
[13:22] <cjwatson> http://people.canonical.com/~ubuntu-archive/nbs.html
[13:22] <tumbleweed> yes
[13:23] <cjwatson> And if a binary is in saucy but not in saucy-proposed, proposed-migration assumes that the NBS binaries are removed when deciding whether the source can be migrated
[13:23] <tumbleweed> right
[13:23] <cjwatson> But, there is a corner case here
[13:24] <cjwatson> Let's say we have version 1 in saucy, version 2 in saucy-proposed which never migrated, and now version 3 in saucy-proposed which is trying to migrate
[13:24] <cjwatson> If version 2 built a binary not in version 3, we don't track that
[13:24] <cjwatson> So the binary needs to be checked by hand and removed from saucy-proposed
[13:24] <tumbleweed> ah, that's possibly the case here
[13:25] <cjwatson> It's basically an awkward side-effect of -proposed being a partial suite
[13:25] <cjwatson> It's exactly the case here
[13:25] <cjwatson> ncbi-tools6 | 6.1.20120620-2 | saucy/universe | source
[13:25] <cjwatson> ncbi-tools6 | 6.1.20120620-5 | saucy-proposed/universe | source
[13:25] <cjwatson> libvibrant6 | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc
[13:25] <cjwatson> libvibrant6-dbg | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc
[13:25] <tumbleweed> aah, libvibrant6 was never removed from -proposed
[13:25] <tumbleweed> that makes sense
[13:25] <cjwatson> Exactly
[13:25] <cjwatson> Just checking for rdepends now
=== didrocks1 is now known as didrocks
[13:31] <cjwatson> tumbleweed: removed, thanks
[13:33] <tumbleweed> cjwatson: thank you
[13:37] <stgraber> slangasek,xnox: oh, apparently I'm not subscribed to bugs for the upstart package in Ubuntu, that'd explain why I didn't see any bug trafic.
[13:44] <stgraber> slangasek: I believe at the time we had an SRU in proposed so that's why I didn't upload it directly, though I see that's no longer the case, so I'll at least push the cherry-pick to the branch and update the bug with a testcase (not sure if it has the SRU headers already)
[13:46] <xnox> right. and we might be missing a few other bug-fixes on the SRU that should go in.
=== blitzkrieg3 is now known as jmleddy
[14:59] <cjwatson> stgraber: ^-
[14:59] <stgraber> looking
[15:01] <stgraber> cjwatson: there you go ^
[15:01] <infinity> cjwatson: Want to add any-ppc64el to debian/control upstream so we don't forget later?
[15:01] <infinity> cjwatson: Hrm, and any-x32 ... How did no one complain about that yet?
[15:02] <infinity> I suppose I have commit, don't I.  Maybe I'll do that.
[15:02] <infinity> Not a branch: "bzr+ssh://bzr.debian.org/bzr/pkg-grub/branches/2.00/"
[15:02] <cjwatson> Uh, are you sure upstream configure would handle that?
[15:02] <infinity> grump.
[15:03] <cjwatson> bzr+ssh://bzr.debian.org/bzr/pkg-grub/trunk/grub/
[15:03] <infinity> cjwatson: Oh, fair point on the ppc64el thing, might need to check.  (Though, it should work with a sufficiently new config.{sub,guess})
[15:03] <infinity> cjwatson: But I'm confused that no one's complained about the missing x32...
[15:03] <cjwatson> Anyway it needs a bit more than a control tweak - there'll be stuff in rules and files in debian/ too.
[15:04] <infinity> Yeah, so I'm seeing upon a grep.
[15:04] <infinity> I'll poke it $later, it's certainly not urgent.
[15:04] <cjwatson> I can do it nowish.
[15:06] <infinity> For 14.04, I need to make some time to see if I can switch to grub2 on all yaboot subarches.
[15:06] <infinity> I certainly don't want to bring up any new PPC ports with yaboot.
[15:09] <cjwatson> What's x32 in config.{guess,sub} speak?
[15:09] <infinity> x86_64-linux-gnux32
[15:09] <infinity> I believe.
[15:10] <cjwatson> infinity: Actually, I've uncommitted my ppc64el change.  This needs actual build-testing first, because configure.ac does need to be updated.
[15:10] <infinity> cjwatson: Yeah, hence my "$later" thing.
[15:11] <cjwatson> Ditto I'd really rather be able to see whether x32 works first.
[15:11] <infinity> cjwatson: Yeah, don't worry about it.  It was an observation in passing when I saw the arches in .dsc
[15:11] <infinity> cjwatson: x32 doesn't matter deeply to me, but I can test it in Debian sometime.  And ppc64el, I'll argue with it when we have a port.
[15:12] <infinity> (The latter will definitely happen due to my previously-mentioned not wanting to have another yaboot port)
[15:12] <cjwatson> It's probably just a matter of powerpc64-* -> powerpc64-*|powerpc64le-* and similar in configure
[15:12] <infinity> Probably.
[15:12] <cjwatson> Oh, heck, it might be more than that, maybe the ELF relocator needs porting
[15:13] <infinity> And x32 might be a zero issue thing, since it's x86_64, and the ILP32 part doesn't factor in for the bootloader bit, just for the userspace tools.
[15:13] <cjwatson> Yeah, just install it via multiarch
[15:13] <cjwatson> Might be nice to build it though
[15:13]  * infinity nods.
[15:14] <cjwatson> Wouldn't be too surprising to find a wrong type size somewhere though
[15:23] <slangasek> stgraber: yes, 1.8-0ubuntu1.2 had a regression, bug #1199778; so we should get a re-SRU... :)
[15:24] <ubot2`> Launchpad bug 1199778 in upstart (Ubuntu Raring) "upstart crashes if re-exec'ed with active chroot sessions" [Undecided,New] https://launchpad.net/bugs/1199778
[15:28] <stgraber> slangasek: ok, if I push the bugfix for the restart bug to the branch and update the bug report with the SRU paperwork, can you or xnox take it from there?
[15:28] <xnox> ok, by me.
[15:32] <slangasek> stgraber: yes
[15:35] <slangasek> stgraber, cjwatson: so I'm happy to see that bug #1187233 is indeed resolved in saucy with the new shim-signed, which means it's time for me to start worrying about SRUs.  I'm considering that the best option might be: 1) pull back the gnu-efi source; 2) verify that all revdeps (including shim) build in precise with the updated gnu-efi; 3) pull back sbsigntool; 4) binary copy shim from saucy (so we don't have to submit a new binary to 
[15:35] <ubot2`> Launchpad bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [High,Confirmed] https://launchpad.net/bugs/1187233
[15:35] <slangasek> ... reupload shim-signed, with the build-deps adjusted for sbsigntool
[15:35] <slangasek> does that sound reasonable / possible?
[15:37] <cjwatson> Yeah, unless you think you can figure out a gnu-efi backport
[15:39] <infinity> Does your sbsigntool alignment fix also apply to kernel signing?  Should we make sure the new version is on ftpmaster?
[15:40] <infinity> We've had this discussion, I think.  Was the concensus just "meh, wait until ftpmaster is upgraded to precise"?
[15:40] <cjwatson> Not sure what the timescale on that's going to be.  Might be better to push to lucid-cat.
[15:46] <slangasek> infinity: we don't care about the sbsigntool alignment except in the case where we're trying to reproduce the MS-signed output
[15:47] <slangasek> the current sbsigntool already produces perfectly valid signed objects that work fine
[15:47] <slangasek> so yes, I don't care about pushing this back to lucid-cat
[15:50] <infinity> Mmkay, so it's not producing buggy output, per se, just slightly weird output?
[15:51] <slangasek> not even weird, just not identical to MS
[15:51]  * infinity nods.
[15:51] <infinity> Though, "identical to MS" seems like what you want for SB stuff.
[15:52] <slangasek> cjwatson: "does anyone feel desperately that we have to keep this or shall I just go ahead and drop it" - surely those are not mutually exclusive!
[15:53] <cjwatson> maybe not well-phrased :)
[16:01] <stgraber> xnox: is lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring the right branch to use for the upstart raring SRU?
[16:03] <xnox> stgraber: yes, it is.
[16:09] <stgraber> cjwatson: did you upload grub2-signed? I can't remember seeing it on saucy-changes
[16:10] <cjwatson> Oh, no, I'll go and do that now
[16:10] <tjaalton> could someone have a look at glamor-egl in NEW, phoronix is making fun of us still not supporting 3d on newest radeons..
[16:11] <tjaalton> it was uploaded before FF
[16:11] <tjaalton> (barely=
[16:11] <tjaalton> )
[16:15] <cjwatson> stgraber: done
[17:50] <barry> hi folks.  i have one package that entered new before ff (nose2) and two packages i submitted ffe's on (pip and virtualenv).  i don't mean to be a noodge (and will happily wait patiently) but i just want to make sure they aren't waiting on something from me.
[20:03] <rsalveti> in case someone has the time to review another FFe :-), bug 1224665
[20:03] <ubot2`> Launchpad bug 1224665 in gst-plugins-bad1.0 (Ubuntu) "[FFe] Android media support over hybris for gst-plugins-bad1.0" [Undecided,New] https://launchpad.net/bugs/1224665
[20:03] <rsalveti> needed for touch to have hardware decode & rendering support in gstreamer, using the android video hal (over libgstagefright)
[20:06] <Laney> rsalveti: what is [i386 armhf] about?
[20:07] <rsalveti> Laney: it uses hybris (android), so it can only be tested in i386 and armhf because we only have android devices for those archs
[20:07] <rsalveti> that's why I didn't enable it for all archs
[20:12] <Laney> sorry, got to leave - no time to review
[20:12] <Laney> but what would the harm be in building it everywhere it can? (seems that means !ppc)
[20:12]  * Laney leaves it for others
[20:13] <rsalveti> Laney: wouldn't cause any harm I guess, but I know it could only work i386 and armhf as of now
[20:15] <infinity> I'm fine with the arch restriction for now.