[00:02] <bdmurray> nope, build-tarball.sh
[00:02] <slangasek> but the signing is done somewhere else, and the current/ symlink is published before the signing is done?
[00:03] <bdmurray> I guess, I'm not sure where the signing is done
[00:03] <slangasek> I suppose the bug lies somewhere in launchpad then
[00:03] <bdmurray> any upgrade without the .gpg file will fail though
[00:05] <slangasek> sure, it's certainly a bug to be doing this out of order
[00:05] <bdmurray> agreed
[00:06] <slangasek> bdmurray: bug #1289604, this is in the twisty maze of upgrades that always confuses me.  Can you document in the bug description which upgrade paths this SRU is supposed to fix?
[00:06] <ubot2`> Launchpad bug 1289604 in update-manager (Ubuntu) "ubuntu-release-upgrader doesn't depend on python-apport" [High,In progress] https://launchpad.net/bugs/1289604
[00:08] <bdmurray> slangasek: this affects a Saucy system trying to upgrade to Trusty as a default Saucy system does not have python-apport installed, subsequently not all or maybe no crashes of the release upgrader are caught.
[00:09] <slangasek> bdmurray: but why is this run under python instead of python3 for the saucy->trusty upgrade path?
[00:12] <bdmurray> slangasek: is python3 installed by default on Precise?
[00:12] <slangasek> bdmurray: no, but you said this was for saucy->trusty
[00:13] <bdmurray> slangasek: yes, but Precise and Saucy use the trusty.tar.gz
[00:13] <slangasek> ah
[00:13] <slangasek> didn't we discuss at some point a clever plan to make trusty.tar.gz automatically use the correct interpreter based on the source distribution?
[00:14] <bdmurray> I don't recall the clever plan.
[00:14] <slangasek> ok
[00:15] <slangasek> maybe I'm confusing it with some other clever plan for things that reexec themselves
[00:18] <bdmurray> slangasek: description updated
[00:19] <bdmurray> slangasek: should I email our team (since someone might know more) about the gpg file?
[00:20] <slangasek> bdmurray: thanks, u-r-u accepted
[00:20] <slangasek> bdmurray: yeah - I would say #launchpad-ops, but it's a bit late in the week for that
[00:21] <bdmurray> thanks
[00:31] <xnox> slangasek: would you be able to review debian-installer in precise unapproved queue? it's a kernel version bump across the board, but it's needed to resolve
[00:31] <xnox> bug #1276739
[00:31] <ubot2`> Launchpad bug 1276739 in debian-installer (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,In progress] https://launchpad.net/bugs/1276739
[00:32] <slangasek> xnox: ok, looking
[00:33] <xnox> i think it did it right... (it's my first d-i itself upload)
[00:36] <slangasek> xnox: if this is for bug #1276739, why no reference to that in the changelog?
[00:36] <ubot2`> Launchpad bug 1276739 in debian-installer (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,In progress] https://launchpad.net/bugs/1276739
[00:37] <slangasek> (there's even an open bug task... so the upload should really reference it for SRU tracking)
[00:38] <xnox> slangasek: well i added the bug task, and none of the other kernel bumps had sru bug numbers. (e.g. well d-i/ubiquity rebuilds rarely include bug numbers of sru's of included components).
[00:39] <slangasek> ok
[00:39] <xnox> slangasek: affected people will have to update their pxe-boot setup anyway, it's not like it's something that apt-get dist-upgrade resolves.
[00:39] <slangasek> accepted
[00:46] <apw_> hv-kvp-daemon-init was erroneously building on i386 when we have not been building the hv daemons for that arch, this upload cleans that up but it is therefore now NBS on i386.
[02:32] <infinity> apw: hv-kvp-daemon-init NBS cleaned up.
[10:07] <apw> infinity, thanks a lot
[19:57] <Noskcaj> Can someone please look at bug 1282937 ?
[19:57] <ubot2`> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937