=== slangase` is now known as slangasek
[06:02] <RAOF> Hm. Queubot *may* have gone slightly mad.
[06:04] <cjwatson> stgraber: ^- please fix
=== benonsoftware is now known as Guest30663
=== \b is now known as benonsoftware
=== ogra_` is now known as ogra_
=== kip_ is now known as kip_busy
=== knome_ is now known as knome
=== s8321414_ is now known as s8321414
[12:17] <Trevinho> SRU team, please can you move bamf (xenial) and unity (trusty) sync to proposed?
[12:18] <Trevinho> bdmurray, pitti ^
[12:19] <Trevinho> It would be nice if you guys could provide a "single name" to ping the team alltogether, as it's not so easy to figure out who is in charge. And for xenial we'd need to do quite a lot of SRUs, and I'd like the process to be agile.
[12:32] <Trevinho> Ah, it seems I missed https://wiki.ubuntu.com/StableReleaseUpdates#Publishing...
[12:32] <Trevinho> Then... RAOF ^^ :)
=== alex-abreu|off is now known as alex-abreu
[12:38] <seb128> Trevinho, he's in .au so likely called it a day by now
[12:43] <Trevinho> seb128: yeah... well, leaving that for tomorrow then
[12:44] <seb128> well maybe bdmurray or arges can help you and have a look, would be nice to get those in since LTS users missing menus is not nice and we should already have landed that earlier
[12:44] <seb128> but yeah, let's see
[13:21] <LocutusOfBorg> please accept hexchat merge from new :)
[14:19] <flexiondotorg> Laney, I've just uploaded a bug fixed mate-panel 1.12.2-2 to xenial.
[14:19] <flexiondotorg> Do I need to file an SRU for that?
[14:19] <flexiondotorg> One patch has been added.
[14:21] <Laney> flexiondotorg: You need to make all linked bugs contain the required SRU information
[14:22] <flexiondotorg> So create an SRU.
[14:22] <flexiondotorg> And a comment in the original bug with a link to the SRU?
[14:22] <flexiondotorg> And, an SRU is required.
[14:22] <Laney> No need to file a new bug if the changelog already contains one
[14:22] <Laney> Just edit it
[14:23] <flexiondotorg> Change has the link to the bug.
[14:23] <flexiondotorg> *Changelog
[14:23] <Laney> Then use that one
[14:23] <flexiondotorg> OK, so convert the existing bug into an SRU?
[14:24] <Laney> nod
[14:24] <flexiondotorg> Thanks,.
[14:25] <rbasak> Technically it's the act of uploading to Xenial (or another stable release) that makes it an SRU. One might consider a bug to have SRU information if it has SRU template style description and one or more bug tasks for stable releases.
[14:25] <rbasak> (if that helps make anything clearer)
[14:33] <flexiondotorg> rbasak, I've editted the original bug opening post to include the SRU template.
[15:23] <stgraber> restarting queuebot, lets see if it's happier
[15:38] <cjwatson> stgraber: thanks
=== kip_busy is now known as kip_
=== Patrick is now known as SorryPat
=== SorryPat is now known as Patrick
[17:03] <slangasek> cjwatson, infinity: the spikes on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg where c-m wanted to demote a number of source packages approximately equal to the number of source packages in main are artifacts in the data, right? any objections to me cleaning those out?
[17:05] <slangasek> cjwatson, infinity: sorry, not http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, I mean http://people.canonical.com/~ubuntu-archive/component-mismatches.csv
[17:06] <cjwatson> slangasek: fine by me
[17:08] <slangasek> done
[17:08] <slangasek> (backup taken, so revertible)
[18:00] <robru> ^^ please reject these qtmir-gles uploads for xenial/vivid, those are mistakes.
[18:12] <apw> robru, done
[18:12] <slangasek> robru: done
[18:13] <slangasek> :)
[18:13] <apw> oh i wonder what that will do :)
[18:13] <slangasek> apw: you got them first, that explains why the commands silently succeeded for me ;)
[18:13] <apw> ahh :)
[18:26] <Saviq> hi can someone please cancel/restart https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu23/+build/9668581 - it's building for 10h already where it should take ~25mins
[18:26] <Saviq> not sure why the error in the first place, but it shouldn't be stuck for 10h anyway
[18:28] <slangasek> Saviq: retrying the build just increases the chances of us getting stuck with upstart binaries again on s390x, which were deliberately removed
[18:28] <slangasek> Saviq: I guess you care about this for ubuntu-app-launch + ubuntu-ui-toolkit?
[18:28] <Saviq> slangasek, yeah http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch
[18:29] <slangasek> is this a new dependency introduced in the new ubuntu-app-launch in -proposed?
[18:29] <Saviq> tedg, ↑↑?
[18:30] <Saviq> slangasek, I doubt it, u-a-l was based on upstart since the beginning
[18:30] <Saviq> we'll need to remove u-a-l and ubuntu-ui-toolkit s390x IIUC?
[18:31] <slangasek> Saviq: yes, that's probably what we want to do; but we don't want to just remove binaries and have them build again (and get stuck again) on the next upload. Can we have these packages declare a build-dep on upstart?
[18:31] <slangasek> (I can remove the binaries now so as not to require a new landing, but I don't want to do this without a committment to fix the underlying issue)
[18:33] <Saviq> slangasek, u-a-l already does
[18:33] <slangasek> haha
[18:33] <slangasek> so it got built during the window when the upstart/s390x binary was in the archive before we removed it, fail
[18:35] <slangasek> Saviq: ok, ual binaries removed from yakkety-proposed for s390x; that should unblock, assuming there aren't other revdeps on ual that have also built on s390x and will also now need removal
[18:36] <Saviq> slangasek, but indeed ubuntu-ui-toolkit does not B-D on upstart - not sure if it should D on it in the first place
[18:36] <slangasek> also, it's awfully unfriendly of proposed-migration to refuse to consider this package a candidate given that the same package is uninstallable already in yakkety on s390x
[18:47]  * tedg back
[18:47] <tedg> Thanks slangasek
[19:59]  * pitti sighs at the xenial-proposed queue, ok, let's go
[20:04] <pitti> much of it is just xnox doing half an archive rebuild :)
[20:04] <slangasek> pitti: hmm, did you see my notes on all of those SRU bugs? :)
[20:05] <slangasek> those were !accepted because they're lacking autopkgtests and therefore an SRU regression test plan
[20:05] <slangasek> so, test plan still missing, but now they're in -proposed so at increased risk of publication without ever being tested <shrug>
[20:06] <pitti> right, so they need to be smoketested maunally
[20:07] <pitti> slangasek: ah, ok (and no, didn't see your comment in the middle of the bug trail, sorry)
[20:07] <pitti> it seemed to me that without proposed binaries there's little chance of actually testing them
[20:08] <pitti> leaving the others in -proposed then, resuming at cacti-spine
[20:11] <bdmurray> slangasek: Could you fully phase this systemd SRU for xenial? the problems are all package install failures
[20:11] <Saviq> slangasek, do you need to delete the u-a-l packages too http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch ?
[20:14] <pitti> bdmurray: indeed, I saw another instance of bug 1560797, one instance of bug 1584751, and two failures of pam-auth-update; none of that was touched in the SRU, these were old bugs
[20:14] <ubot5> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797
[20:14] <ubot5> bug 1584751 in systemd (Ubuntu) "package systemd 229-4ubuntu5 failed to install/upgrade: le sous-processus script pre-removal installé a retourné une erreur de sortie d'état 2" [Undecided,New] https://launchpad.net/bugs/1584751
[20:16] <slangasek> Saviq: dohh, I removed them from yakkety instead of yakkety-proposed? fixed now
[20:17] <slangasek> bdmurray: done
[20:20] <Saviq> slangasek, is this a new thing that we don't want upstart for s390x? it seems it was happily there for xenial?
[20:20] <Saviq> except for the -proposed versions that died on power and s390x...
[20:21] <slangasek> Saviq: it's only used for client sessions in xenial and beyond, which do not apply on s390x.  It built by chance on s390x before, then regressed due to problems apparently outside control of upstart itself
[20:22] <Saviq> slangasek, ack, filing a bug for uitk
[20:43] <pitti> arges: SRU handover for xenial: upower is from myself (review appreciated), everything else up to unity-control-center (my current top) is blocked on something and has bug followups
[20:43] <pitti> ah, forgot some
[20:53] <pitti> jamespage: crmsh in wily-proposed queue> this is essentially a backport, and wily seems mostly uninteresting for servers (even more now that xenial is released); does bug 1445616 still actually make sense to SRU?
[20:53] <ubot5> bug 1445616 in crmsh (Ubuntu Wily) "[SRU] crmsh in vivid/wily/xenial is not compatible with pacemaker" [High,Triaged] https://launchpad.net/bugs/1445616
[20:54]  * pitti sees a bunch of similar major new upstream releases in https://launchpad.net/ubuntu/wily/+queue?queue_state=1
[21:02] <Saviq> hrm should this not have gone away by now http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch ¿?
[21:03] <pitti>  ubuntu-app-launch          | 0.9+16.04.20160510.2-0ubuntu1 | yakkety-proposed/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[21:03] <pitti> Saviq: no ^
[21:03] <pitti> s390x was removed from yakkety, but not yakkety-proposed
[21:03] <Saviq> slangasek, ↑?
[21:03] <pitti> or it was and this is publisher/mirror lag
[21:03] <Saviq> ack
[21:08] <pitti> arges: wily SRU handover> IMHO all the remaining packages in the queue (manila is my top one) should be rejected and not be an SRU
[21:08] <pitti> bugs commented on
[21:17] <pitti> caribou: ping @ bug 1532789
[21:17] <ubot5> bug 1532789 in multipath-tools (Ubuntu Trusty) "Trusty multipath-tools suffering seg faults" [High,Fix committed] https://launchpad.net/bugs/1532789
[21:34] <slangasek> pitti, Saviq: yes, publisher + proposed-migration delay; should look better on the next run
[21:34] <Saviq> ack
[21:35] <Saviq> indeed it's already gone
[21:41] <pitti> *phew, SRU queues all processed
[21:47] <arges> pitti: ack