[12:52] 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] Trevinho: it's too fresh for sru-review [13:01] and I'm about to EOD [13:01] tjaalton, you mean? [13:01] ERROR: queue does not have a debdiff [13:01] tjaalton: it won't have it, since it's a ppa sync [13:01] it's not going to [13:01] what Trevinho said [13:01] what's the rush? [13:02] none I guess [13:02] tjaalton: various xenial fixes [13:02] but, ok... I just wanted to clear the queu [13:02] would be nice to see it approved today [13:02] it's overdue from our side [13:02] fine, acked [13:02] tjaalton: debdiffs are at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-036/+packages though [13:02] Trevinho is being a big eager now :p [13:02] my shift is tomorrow btw, don't mind the queue being a bit shorter then ;) [13:03] tjaalton: thanks then [13:03] queue is fairly short thanks to p_itti rounds ;-) [13:05] indeed... :) [14:51] 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] bug 1586061 in python-microversion-parse (Ubuntu) "[MIR] python-microversion-parse" [Undecided,New] https://launchpad.net/bugs/1586061 [14:53] apologies, that bug is not related ^ , however we'd like to have these promoted for an upcoming MIR [15:03] coreycb: Would prefer them to show up in one of the component-mismatches reports first. [15:03] coreycb: You don't need them to be promoted in advance of an MIR. [15:03] cjwatson, ok [15:41] seb128: do you know why, although unity/compiz are in xenial-proposed now, there have been no bug comments for verification requests? [15:41] Trevinho, I guess because tjaalton didn't use the tool right [15:42] 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] Trevinho, sru team probably knows, try to see if bdmurray or arges can help you [15:50] slangasek: https://code.launchpad.net/~brian-murray/britney/britney2-ubuntu/+merge/295847 - I couldn't JFDI [15:50] 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] arges: yeah, it's weird... same for compiz [15:51] arges: or maybe because it was a ppa sync? [15:51] Its worked in the past with PPA syncs [15:52] I got some cronmail about LP timeouts over my night [15:52] 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] yea [15:52] As an example bug 1491913 from a previous SRU was commented on [15:52] 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] 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] 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] Launchpad bug 1491913 in Unity 7.2 "Force high gfx mode with UNITY_LOW_GFX_MODE == 0" [Low,Fix committed] [15:57] The "Update Released" message is an SRU team tool. [15:57] bdmurray: ah, ok... that didn't happen for some recent changes though [15:58] Trevinho: if you show me something I could have a look [15:58] 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] bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302 [15:58] bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866 [15:58] (and other bugs either, but I don't recall them all since I've set them as fix released manually) [15:59] Trevinho: that's the one that was published 2 hours and arges and I were just talking about possible LP timeouts [15:59] infinity: someone just did the whole reverting SRU thing again in the archive... [15:59] infinity: this time with eglibc in trusty (at least) [16:00] bdmurray: I'm speaking of the fix in yakkety, not the SRU msg [16:00] bdmurray: well, both in fact [16:00] none of them arrived there [16:00] 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] infinity: according to LP, wgrant is to blame this time around for doing a straight delete and not uploading a revert [16:00] Trevinho: I don't see any bug numbers in the changelog for yaketty [16:00] that was an emergency, it was killing lots of DC machines; there was discussion in #security I believe [16:01] bdmurray: oh, sorry I pasted the wrong link [16:01] 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] bdmurray: here it is https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.10.20160517-0ubuntu1 [16:01] yeah but given the nature of the problem I think that might actually have caused similar problems in reverse [16:02] 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] ah right, so if someone fixed those services (by bouncing them I guess), then uploading the revert will break them again [16:04] this is speculation but it seems at least plausible [16:04] somebody was working on a proper fix [16:05] Trevinho: bug 1521302 doesn't have a compiz bug task, only unity. The janitor looks at source package name and bug number. [16:05] bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302 [16:06] Trevinho: and it looks like bug 1574866 had the ubuntu compiz task added after the yakkety upload [16:06] bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866 [16:07] bdmurray: yeah, i just added that... [16:07] bdmurray: it wasn't there before. But generally in these cases LP added the tasks [16:08] Trevinho: I don't think Launchpad automatically adds tasks to bugs [16:08] mh, weird... I think it did. Although i used to run a script to keep downstream and upstream bugs in sync [16:14] 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] 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] 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] Trevinho: Could you show me a bug with a proper task? [16:23] bdmurray: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1574689 [16:23] Launchpad bug 1574689 in unity (Ubuntu) "Middle-clicking application icon in switcher, doesn't close it" [Low,Fix released] [16:26] 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] 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] bdmurray: though you could JFDI consolidate the files in the hints branch into 'freeze' :) [16:35] (though it indeed seems we would need to adjust the perms on the 'freeze' file then) [16:48] 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] slangasek / bdmurray: consolidating> It's useful to be able to see who added a hint on excuses.html, IMO [16:50] linux-keystone> looking, but I'm not sure I'll know [16:51] Trevinho, seb128, arges: i didn't use sru-review because there was no debdiff [16:51] 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] there's a hint -> bzr blame, works just as well for me, YMMV [16:51] Laney: and for reference, my full command was 'run-autopkgtest -s trusty -a armhf --trigger eglibc/2.19-0ubunt6.8 linux-keystone' [16:51] tjaalton: there's a --no-diff switch [16:51] -s trusty-updates doesn't work [16:52] this is a package that didn't exist in the trusty release pocket; previous runs somehow managed to get it right [16:52] tjaalton: not sure if you can use it with that tool, but the ppa generates one [16:52] It's annoying for a smaller set of people than those that look at excuses [16:53] bdmurray: oh, ok [16:53] 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] Trevinho: point was that sru-review didn't work, because i didn't use --no-diff [16:54] tjaalton: ah I see... bdmurray what's the way to fix it? [16:54] I mean, can we just post the msg from sru-tool, or should I hack it to do that? [16:56] 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] tjaalton, Trevinho: actually let me do that as I can work on adding the release tasks w/ it too [16:57] bdmurray: ok, thanks a lot then [16:59] 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] yes, it's really a launchpad bug (feature request) that the queue can't give us diffs [17:00] these are always going to lag a bit so long as we don't have diffs to review [17:00] s/lag a bit/require more effort from the SRU team/ [17:02] slangasek: sorry, I don't see immediately what's wrong with linux-keystone - perhaps some delicate problem with the pinning [17:03] apw might be able to help if he's around [17:03] and I've got to go, o/ [17:04] slangasek, linux-keystone might be in a mess, as in linux-meta does not match linux for that ... [17:04] apw: it indeed might be - but none of that should cause autopkgtest to fail to find the source package :) [17:05] 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] stgraber: A revert would be as harmful as the upgrade was. [17:13] stgraber: A new version will be coming, but it can't be a straight and simple revert. === georgelorch2 is now known as georgelorch [18:32] 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] Laney, apw: right, using a real eglibc package version in the trigger somehow sorted it [18:52] (test is running now) [20:13] any archive admins around to remove some packages please? [20:41] slangasek: Looking at https://wiki.ubuntu.com/SnapdUpdates I would have expected bug 1583085 to have the "Packaging QA" section done. [20:41] bug 1583085 in snapd (Ubuntu) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085 [20:46] bdmurray: hmm indeed [20:46] ginggs: possibly - what do you have for us? [20:47] hi slangasek! [20:47] slangasek: Okay, I wanted to make sure I was understanding things [20:48] for starters here's LP: #1580039 , LP: #1580041 and LP: #1580047 [20:48] Launchpad bug 1580039 in syfi (Ubuntu) "Please remove syfi - obsolete" [Undecided,New] https://launchpad.net/bugs/1580039 [20:48] Launchpad bug 1580041 in ufc (Ubuntu) "Please remove ufc - superceded by ffc" [Undecided,New] https://launchpad.net/bugs/1580041 [20:48] Launchpad bug 1580047 in swig2.0 (Ubuntu) "swig2.0 removal" [Undecided,New] https://launchpad.net/bugs/1580047 [20:52] and then there's LP: #1584717 LP: #1585795 LP: #1586043 LP: #1586047 [20:52] Launchpad bug 1584717 in pion-net (Ubuntu) "Please remove pion-net" [Undecided,New] https://launchpad.net/bugs/1584717 [20:52] Launchpad bug 1585795 in python-glpk (Ubuntu) "Please remove python-glpk" [Undecided,New] https://launchpad.net/bugs/1585795 [20:52] Launchpad bug 1586043 in elmerfem (Ubuntu) "Please remove elmerfem" [Undecided,New] https://launchpad.net/bugs/1586043 [20:52] Launchpad bug 1586047 in pyviennacl (Ubuntu) "Please remove pyviennacl" [Undecided,New] https://launchpad.net/bugs/1586047 [20:53] and lastly (for now) there's LP: #1586038 where the maintainer asked that we just remove the binaries [20:53] Launchpad bug 1586038 in faumachine (Ubuntu) "Please demote faumachine to -proposed" [Undecided,New] https://launchpad.net/bugs/1586038 [20:54] ginggs: is someone racing me to these? syfi isn't in yakkety [20:54] nor ufc [20:55] ginggs: looks like cjwatson has processed some of these via process-removals, not seeing your bugs :) [20:55] ah, and that was only yesterday [20:56] 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] great, so swig2.0 can go now, the merge of subversion has just landed [20:57] (unless there are revdeps that aren't sorted, but then, sort those and the AA will do the rest) [21:05] ginggs: heh, these bug reports suggest there was a dead spot in 2013 when we failed to do process-removals :/ [21:06] how does a pyviennacl compare to a posixacl [21:14] 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] ginggs: [21:15] ginggs: it's a manual removal, and I'm looking at it still [21:15] sorry, carry on then :) [21:18] ginggs: if someone were to improve http://qa.ubuntuwire.org/rdepends to report alternate dependencies, it would be easier to process these ;) [21:18] (less manual review of the output of reverse-depends) [21:19] tumbleweed: ^^^ [21:20] I've mentioned this to tumbleweed before and he was ENOTIME [21:20] yeah, and he's organizing a debconf now [21:21] erm, IIRC it does report alternate dependencies, but doesn't resolve virtual ones [21:21] I seem to remember some people wanting it to *not* report alternate dependencies [21:24] tumbleweed: well, for my purposes it would be very useful *to* report alternate dependencies [21:24] who are these other people and how can I bribe them to agree with me ;) [21:53] slangasek: yeah, one of these days we should beef up the removal tools to deal with bugs better [21:54] it's kind of deeply annoying to deal with the two worlds in parallel [21:56] 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] hmm, perhaps that version number for ipmitool for xenial isn't so great [22:26] I'm happy to reject it for you ;-) [22:26] please :) [23:22] 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] We had dozens of dead apaches, so it was pretty important to pull it ASAP. [23:33] bdmurray: hint> only question is, why does it show up as a regression given that this test never succeeded on xenial [23:34] bdmurray: so, fine to hint, but please also talk to pitti about why it's a "regression"