[12:52] <Trevinho> tjaalton, slangasek: hey, could you please publish compiz and unity SRUs that have just hit the queue: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 ?
[13:00] <tjaalton> Trevinho: it's too fresh for sru-review
[13:01] <tjaalton> and I'm about to EOD
[13:01] <seb128> tjaalton, you mean?
[13:01] <tjaalton> ERROR: queue does not have a debdiff
[13:01] <Trevinho> tjaalton: it won't have it, since it's a ppa sync
[13:01] <seb128> it's not going to
[13:01] <seb128> what Trevinho said
[13:01] <tjaalton> what's the rush?
[13:02] <seb128> none I guess
[13:02] <Trevinho> tjaalton: various xenial fixes
[13:02] <Trevinho> but, ok... I just wanted to clear the queu
[13:02] <seb128> would be nice to see it approved today
[13:02] <seb128> it's overdue from our side
[13:02] <tjaalton> fine, acked
[13:02] <Trevinho> tjaalton: debdiffs are at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-036/+packages though
[13:02] <seb128> Trevinho is being a big eager now :p
[13:02] <tjaalton> my shift is tomorrow btw, don't mind the queue being a bit shorter then ;)
[13:03] <Trevinho> tjaalton: thanks then
[13:03] <seb128> queue is fairly short thanks to p_itti rounds ;-)
[13:05] <Trevinho> indeed... :)
[14:51] <coreycb> hello, can an archive admin please promote python3-ply and python3-dateutil to main?  python-ply and python-dateutil are already in main.  this will help us with our MIR for bug 1586061
[14:51] <ubot5`> bug 1586061 in python-microversion-parse (Ubuntu) "[MIR] python-microversion-parse" [Undecided,New] https://launchpad.net/bugs/1586061
[14:53] <coreycb> apologies, that bug is not related ^ , however we'd like to have these promoted for an upcoming MIR
[15:03] <cjwatson> coreycb: Would prefer them to show up in one of the component-mismatches reports first.
[15:03] <cjwatson> coreycb: You don't need them to be promoted in advance of an MIR.
[15:03] <coreycb> cjwatson, ok
[15:41] <Trevinho> seb128: do you know why, although unity/compiz are in xenial-proposed now, there have been no bug comments for verification requests?
[15:41] <seb128> Trevinho, I guess because tjaalton didn't use the tool right
[15:42] <Trevinho> seb128: oh... you know who could trigger that?
[15:43]  * Trevinho can send them too, in case... But, it's a little annoying
[15:43] <seb128> Trevinho, sru team probably knows, try to see if bdmurray or arges can help you
[15:50] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/britney/britney2-ubuntu/+merge/295847 - I couldn't JFDI
[15:50] <arges> Trevinho: looks like https://launchpadlibrarian.net/261667453/unity_7.4.0+16.04.20160526.1-0ubuntu1_source.changes shows the correct Launchpad-Bugs-Fixed  . maybe 'sru-review' script didn't append those correctly.
[15:51] <Trevinho> arges: yeah, it's weird... same for compiz
[15:51] <Trevinho> arges: or maybe because it was a ppa sync?
[15:51] <bdmurray> Its worked in the past with PPA syncs
[15:52] <bdmurray> I got some cronmail about LP timeouts over my night
[15:52] <arges> I've had this happen to me due to Launchpad timeouts. I had to manually copy and paste the call for testing message
[15:52] <arges> yea
[15:52] <bdmurray> As an example bug 1491913 from a previous SRU was commented on
[15:52] <ubot5`> bug 1491913 in Unity 7.2 "Force high gfx mode with UNITY_LOW_GFX_MODE == 0" [Low,Fix committed] https://launchpad.net/bugs/1491913
[15:53] <Trevinho> also in previous release we didn't get the "fix released" msg for all the bugs, it will be another script, but maybe it's the same issue?
[15:56] <bdmurray> Launchpad itself does the Fix Released change e.g. https://bugs.launchpad.net/unity/+bug/1491913/comments/4 so that shouldn't time out.
[15:56] <ubot5`> Launchpad bug 1491913 in Unity 7.2 "Force high gfx mode with UNITY_LOW_GFX_MODE == 0" [Low,Fix committed]
[15:57] <bdmurray> The "Update Released" message is an SRU team tool.
[15:57] <Trevinho> bdmurray: ah, ok... that didn't happen for some recent changes though
[15:58] <bdmurray> Trevinho: if you show me something I could have a look
[15:58] <Trevinho> bdmurray: for example https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.04.20160526-0ubuntu1 fixed bugs #1521302 and #1574866, but nothing was updated there
[15:58] <ubot5`> bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302
[15:58] <ubot5`> bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866
[15:58] <Trevinho> (and other bugs either, but I don't recall them all since I've set them as fix released manually)
[15:59] <bdmurray> Trevinho: that's the one that was published 2 hours and arges and I were just talking about possible LP timeouts
[15:59] <stgraber> infinity: someone just did the whole reverting SRU thing again in the archive...
[15:59] <stgraber> infinity: this time with eglibc in trusty (at least)
[16:00] <Trevinho> bdmurray: I'm speaking of the fix in yakkety, not the SRU msg
[16:00] <Trevinho> bdmurray: well, both in fact
[16:00] <Trevinho> none of them arrived there
[16:00] <stgraber> infinity: got all my machines reporting that they're running a version of eglibc which doesn't exist in the archive (2.19-0ubuntu6.8)
[16:00] <stgraber> infinity: according to LP, wgrant is to blame this time around for doing a straight delete and not uploading a revert
[16:00] <bdmurray> Trevinho: I don't see any bug numbers in the changelog for yaketty
[16:00] <cjwatson> that was an emergency, it was killing lots of DC machines; there was discussion in #security I believe
[16:01] <Trevinho> bdmurray: oh, sorry I pasted the wrong link
[16:01] <stgraber> cjwatson: yeah, I figured it was, but usually part of dealing with the emergency is to upload the old thing as a newer version immediately to -updates, so people can actually downgrade to the non-broken version
[16:01] <Trevinho> bdmurray: here it is https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.10.20160517-0ubuntu1
[16:01] <cjwatson> yeah but given the nature of the problem I think that might actually have caused similar problems in reverse
[16:02] <cjwatson> it was a subtle thing to do with binaries that have one version of libc in memory and try to dynamically load something involving the other version of libm, I believe
[16:03] <stgraber> ah right, so if someone fixed those services (by bouncing them I guess), then uploading the revert will break them again
[16:04] <cjwatson> this is speculation but it seems at least plausible
[16:04] <cjwatson> somebody was working on a proper fix
[16:05] <bdmurray> Trevinho: bug 1521302 doesn't have a compiz bug task, only unity.  The janitor looks at source package name and bug number.
[16:05] <ubot5`> bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302
[16:06] <bdmurray> Trevinho: and it looks like bug 1574866 had the ubuntu compiz task added after the yakkety upload
[16:06] <ubot5`> bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866
[16:07] <Trevinho> bdmurray: yeah, i just added that...
[16:07] <Trevinho> bdmurray: it wasn't there before. But generally in these cases LP added the tasks
[16:08] <bdmurray> Trevinho: I don't think Launchpad automatically adds tasks to bugs
[16:08] <Trevinho> mh, weird... I think it did. Although i used to run a script to keep downstream and upstream bugs in sync
[16:14] <bdmurray> Trevinho: with the Xenial SRU it looks like there are similar issues https://launchpadlibrarian.net/261667453/unity_7.4.0+16.04.20160526.1-0ubuntu1_source.changes is a unity upload referencing a bug with only a compiz task 1580212
[16:16] <Trevinho> bdmurray: mh, I've fixed some of them, but still we didn't get messages either for the bugs that had proper tasks
[16:17] <Trevinho> bdmurray: there were no Xenial tasks, maybe... but that used to be added automatically (i've not the powers for doing that I can only suggest series)
[16:19] <bdmurray> Trevinho: Could you show me a bug with a proper task?
[16:23] <Trevinho> bdmurray: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1574689
[16:23] <ubot5`> Launchpad bug 1574689 in unity (Ubuntu) "Middle-clicking application icon in switcher, doesn't close it" [Low,Fix released]
[16:26] <bdmurray> Trevinho: okay, that one doesn't have a Xenial task and iirc the tool won't add one.  I've personally just been manually adding tasks when they are missing but will look at improving the tools.
[16:27] <Trevinho> bdmurray: it would be nice if you could add distro tasks automatically, since only few people can do that (/me excluded), so it just makes the process longer
[16:30] <slangasek> bdmurray: though you could JFDI consolidate the files in the hints branch into 'freeze' :)
[16:35] <slangasek> (though it indeed seems we would need to adjust the perms on the 'freeze' file then)
[16:48] <slangasek> Laney: do you have any idea why http://autopkgtest.ubuntu.com/packages/l/linux-keystone/trusty/armhf/ didn't find the linux-keystone package in trusty-updates when I tried to manually trigger this?  AFAICS from the logs the adt-run invocation is materially the same between the latest run and the previous run
[16:50] <Laney> slangasek / bdmurray: consolidating> It's useful to be able to see who added a hint on excuses.html, IMO
[16:50] <Laney> linux-keystone> looking, but I'm not sure I'll know
[16:51] <tjaalton> Trevinho, seb128, arges: i didn't use sru-review because there was no debdiff
[16:51] <slangasek> Laney: useful, but IMHO this doesn't outweigh the annoyance of a) having to manage hints across a stack of files, b) having to manually update permissions in the britney branch if the team membership changes
[16:51] <slangasek> there's a hint -> bzr blame, works just as well for me, YMMV
[16:51] <slangasek> Laney: and for reference, my full command was 'run-autopkgtest -s trusty -a armhf --trigger eglibc/2.19-0ubunt6.8 linux-keystone'
[16:51] <bdmurray> tjaalton: there's a --no-diff switch
[16:51] <slangasek> -s trusty-updates doesn't work
[16:52] <slangasek> this is a package that didn't exist in the trusty release pocket; previous runs somehow managed to get it right
[16:52] <Trevinho> tjaalton: not sure if you can use it with that tool, but the ppa generates one
[16:52] <Laney> It's annoying for a smaller set of people than those that look at excuses
[16:53] <tjaalton> bdmurray: oh, ok
[16:53] <slangasek> people who look at excuses but aren't part of the team usually don't need to directly care which member of the release team added a hint :)
[16:54] <tjaalton> Trevinho: point was that sru-review didn't work, because i didn't use --no-diff
[16:54] <Trevinho> tjaalton: ah I see... bdmurray what's the way to fix it?
[16:54] <Trevinho> I mean, can we just post the msg from sru-tool, or should I hack it to do that?
[16:56] <bdmurray> tjaalton, Trevinho: sru-accept could be used to comment on the bugs after the fact, just need to pass it a whole mess of options
[16:57] <bdmurray> tjaalton, Trevinho: actually let me do that as I can work on adding the release tasks w/ it too
[16:57] <Trevinho> bdmurray: ok, thanks a lot then
[16:59] <Trevinho> bdmurray, tjaalton: I'm sorry to create such annoyance with Ci-train based SRUs, but I'd like the proces to be as smooth as possible, since I expect quite a lot of SRU for xenial. And it would be nice if we can get it done both quickly and properly.
[17:00] <slangasek> yes, it's really a launchpad bug (feature request) that the queue can't give us diffs
[17:00] <slangasek> these are always going to lag a bit so long as we don't have diffs to review
[17:00] <slangasek> s/lag a bit/require more effort from the SRU team/
[17:02] <Laney> slangasek: sorry, I don't see immediately what's wrong with linux-keystone - perhaps some delicate problem with the pinning
[17:03] <Laney> apw might be able to help if he's around
[17:03] <Laney> and I've got to go, o/
[17:04] <apw> slangasek, linux-keystone might be in a mess, as in linux-meta does not match linux for that ...
[17:04] <slangasek> apw: it indeed might be - but none of that should cause autopkgtest to fail to find the source package :)
[17:05] <apw> slangasek, well linux-meta is in general a bit magical, there is a lot of implying tests up from linux -> linux-meta and the like going on, having missmatched linux/linnux-meta pairs might well find new bugs
[17:06]  * apw goes see if he can make the missmatch go away yet
[17:13] <infinity> stgraber: A revert would be as harmful as the upgrade was.
[17:13] <infinity> stgraber: A new version will be coming, but it can't be a straight and simple revert.
[18:32] <slangasek> Laney, apw: not sure why it should have mattered, but I just noticed I typoed the version of the eglibc trigger for the linux-keystone test; retrying now with the right version to see if it makes a difference
[18:51] <slangasek> Laney, apw: right, using a real eglibc package version in the trigger somehow sorted it
[18:52] <slangasek> (test is running now)
[20:13] <ginggs> any archive admins around to remove some packages please?
[20:41] <bdmurray> slangasek: Looking at https://wiki.ubuntu.com/SnapdUpdates I would have expected bug 1583085 to have the "Packaging QA" section done.
[20:41] <ubot5`> bug 1583085 in snapd (Ubuntu) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085
[20:46] <slangasek> bdmurray: hmm indeed
[20:46] <slangasek> ginggs: possibly - what do you have for us?
[20:47] <ginggs> hi slangasek!
[20:47] <bdmurray> slangasek: Okay, I wanted to make sure I was understanding things
[20:48] <ginggs> for starters here's LP: #1580039 ,  LP: #1580041 and LP: #1580047
[20:48] <ubot5`> Launchpad bug 1580039 in syfi (Ubuntu) "Please remove syfi - obsolete" [Undecided,New] https://launchpad.net/bugs/1580039
[20:48] <ubot5`> Launchpad bug 1580041 in ufc (Ubuntu) "Please remove ufc - superceded by ffc" [Undecided,New] https://launchpad.net/bugs/1580041
[20:48] <ubot5`> Launchpad bug 1580047 in swig2.0 (Ubuntu) "swig2.0 removal" [Undecided,New] https://launchpad.net/bugs/1580047
[20:52] <ginggs> and then there's LP: #1584717 LP: #1585795 LP: #1586043  LP: #1586047
[20:52] <ubot5`> Launchpad bug 1584717 in pion-net (Ubuntu) "Please remove pion-net" [Undecided,New] https://launchpad.net/bugs/1584717
[20:52] <ubot5`> Launchpad bug 1585795 in python-glpk (Ubuntu) "Please remove python-glpk" [Undecided,New] https://launchpad.net/bugs/1585795
[20:52] <ubot5`> Launchpad bug 1586043 in elmerfem (Ubuntu) "Please remove elmerfem" [Undecided,New] https://launchpad.net/bugs/1586043
[20:52] <ubot5`> Launchpad bug 1586047 in pyviennacl (Ubuntu) "Please remove pyviennacl" [Undecided,New] https://launchpad.net/bugs/1586047
[20:53] <ginggs> and lastly (for now) there's LP: #1586038 where the maintainer asked that we just remove the binaries
[20:53] <ubot5`> Launchpad bug 1586038 in faumachine (Ubuntu) "Please demote faumachine to -proposed" [Undecided,New] https://launchpad.net/bugs/1586038
[20:54] <slangasek> ginggs: is someone racing me to these? syfi isn't in yakkety
[20:54] <slangasek> nor ufc
[20:55] <slangasek> ginggs: looks like cjwatson has processed some of these via process-removals, not seeing your bugs :)
[20:55] <ginggs> ah, and that was only yesterday
[20:56] <slangasek> ginggs: in the case of ufc, this package was in sync - there's usually no need to file a removal request for such a package as it will be semi-automatically removed by an AA
[20:57] <ginggs> great, so swig2.0 can go now, the merge of subversion has just landed
[20:57] <slangasek> (unless there are revdeps that aren't sorted, but then, sort those and the AA will do the rest)
[21:05] <slangasek> ginggs: heh, these bug reports suggest there was a dead spot in 2013 when we failed to do process-removals :/
[21:06] <slangasek> how does a pyviennacl compare to a posixacl
[21:14] <ginggs> thanks slangasek.  so that swig2.0 has a -1ubuntu4 version, so does that mean it has to be removed manually (or were you still getting to that one?)
[21:14] <slangasek> ginggs:
[21:15] <slangasek> ginggs: it's a manual removal, and I'm looking at it still
[21:15] <ginggs> sorry, carry on then :)
[21:18] <slangasek> ginggs: if someone were to improve http://qa.ubuntuwire.org/rdepends to report alternate dependencies, it would be easier to process these ;)
[21:18] <slangasek> (less manual review of the output of reverse-depends)
[21:19] <ginggs> tumbleweed: ^^^
[21:20] <slangasek> I've mentioned this to tumbleweed before and he was ENOTIME
[21:20] <ginggs> yeah, and he's organizing a debconf now
[21:21] <tumbleweed> erm, IIRC it does report alternate dependencies, but doesn't resolve virtual ones
[21:21] <tumbleweed> I seem to remember some people wanting it to *not* report alternate dependencies
[21:24] <slangasek> tumbleweed: well, for my purposes it would be very useful *to* report alternate dependencies
[21:24] <slangasek> who are these other people and how can I bribe them to agree with me ;)
[21:53] <cjwatson> slangasek: yeah, one of these days we should beef up the removal tools to deal with bugs better
[21:54] <cjwatson> it's kind of deeply annoying to deal with the two worlds in parallel
[21:56] <bdmurray> slangasek: so fpc seems to be a bad test (http://autopkgtest.ubuntu.com/packages/f/fpc/xenial/amd64/) and its listed as a regression for binutils.  It deserves a hint then?
[22:20] <cyphermox> hmm, perhaps that version number for ipmitool for xenial isn't so great
[22:26] <bdmurray> I'm happy to reject it for you ;-)
[22:26] <cyphermox> please :)
[23:22] <wgrant> stgraber: As Colin says, there was no other option. Uploading a newer package with the patches reverted would have caused problems too. It took several hours for the security team to devise and validate a proper fix that could safely upgrade from both.
[23:22] <wgrant> We had dozens of dead apaches, so it was pretty important to pull it ASAP.
[23:33] <slangasek> bdmurray: hint> only question is, why does it show up as a regression given that this test never succeeded on xenial
[23:34] <slangasek> bdmurray: so, fine to hint, but please also talk to pitti about why it's a "regression"