[00:01] -queuebot:#ubuntu-release- New: accepted libva-utils [sync] (artful-proposed) [1.8.1+ds1-1]
[00:01] -queuebot:#ubuntu-release- New: accepted vine [sync] (artful-proposed) [1.1.3+dfsg-2]
[00:03] -queuebot:#ubuntu-release- New binary: libva-utils [ppc64el] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: libva-utils [amd64] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: libva-utils [i386] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: libva-utils [armhf] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:05] -queuebot:#ubuntu-release- New binary: libva-utils [s390x] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:08] -queuebot:#ubuntu-release- New binary: libva-utils [arm64] (artful-proposed/universe) [1.8.1+ds1-1] (no packageset)
[00:17] <bdmurray> cyphermox: I verified bug 1676547. Do you think another verification is needed? e.g. the ignored devices you mention
[00:17] <ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
=== tsimonq2alt is now known as tsimonq2
[04:07] <zx2c4> okay im super dumb
[04:08] <zx2c4> LocutusOfBorg sponsored https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 and now it's in https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=wireguard . I read https://wiki.ubuntu.com/StableReleaseUpdates a few times and there are things about bug templates and adding bug tags, but does that even apply in this case or make any
[04:08] <zx2c4> sense? i cant figure it out
[04:08] <ubot5> Ubuntu bug 1685522 in wireguard (Debian) "out of date snapshot" [Unknown,Confirmed]
[04:09] <zx2c4> this process must be really intuitive for you guys but it's quite overwhelming for me
[04:14] <apw> zx2c4, you had a fix for wireguard and LoB sponsored it for you right ?  into zesty-proposed ?  it is waiting for SRU team approval
[04:14] <zx2c4> apw: its an "empty package" update
[04:15] <apw> zx2c4, i think i saw you saying that you had discussed this with someone, perhaps s-langasek, and was going to ask you to make sure that information is in the SRU bug, but there does not appear to be one
[04:16] <zx2c4> apw: i just added a section?
[04:16] <zx2c4> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522/comments/5
[04:16] <ubot5> Ubuntu bug 1685522 in wireguard (Debian) "out of date snapshot" [Unknown,Confirmed]
[04:16] <zx2c4> apw: is that correct?
[04:17] <apw> zx2c4, bah, there is an SRU bug, but it is not mentioned in the upload
[04:17] <zx2c4> apw: oh,erm, well what now
[04:18] <zx2c4> apw: i seriously have no idea how to grok this
[04:18] <zx2c4> tons of different websites and trackers and processes and tools
[04:18] <zx2c4> im totally lost
[04:19] <apw> zx2c4, when LoB did the sponsorship he should have noticed that the SRU Bug was not in the changelog
[04:19] <zx2c4> oh
[04:19] <zx2c4> changelog
[04:19] <zx2c4> gotcha
[04:19] <zx2c4> he made a few changes to the package
[04:19] <zx2c4> but i guess he didnt notice
[04:19] <zx2c4> so now what
[04:19] <zx2c4> it's in bureaucracy purgatory?
[04:19] <apw> (yes the process must seem archane to the uninitiated)
[04:19] <apw> heh, we are in that
[04:19] <zx2c4> holy moses
[04:19] <zx2c4> cant you just press the button and make it all just go through smoothly
[04:20] <zx2c4> or, uh, is there a real human who we could just speak to instead of going through all these hoops?
[04:20] <zx2c4> seems like that would save hours of time
[04:20] <apw> heh, well i am a real human, at least last time i checked
[04:21] <zx2c4> oh, cool, and you're part of the team and stuff who can do things?
[04:21] <zx2c4> sorry - i thought you were just a kind soul helping me navigate the waters, but otherwise just another user like me
[04:22] <apw> yep, i am able to review that upload, and indeed was
[04:22] <zx2c4> nice!
[04:23] <zx2c4> my original .tar.gz source package was much more minial than the LoB one -- he added back the original source and quilt stuff that was supposed to be removed, for some reaosn, even though he kept my blank makefile and whatnot
[04:23] <zx2c4> i assume this is more convention/process stuff
[04:25] <apw> zx2c4, that keeps the visual delta for review to a minimum i guess
[04:25] <zx2c4> oh, thats silly
[04:25] <zx2c4> but okay
[04:26] <zx2c4> makes the package look super sloppy IMHO
[04:26] <zx2c4> doesnt really matter now i guess
[04:26] <zx2c4> so what is happening right now in terms of kicking this along?
[04:26] <apw> indeed, i assume because he wanted to keep the orig
[04:27] <zx2c4> keeping the orig makes _no_ sense at all
[04:28] <zx2c4> ohwell
[04:28] <apw> on that you'd want to argue with LoB
[04:31] <zx2c4> apw: yea as i said it doesnt really matter any more
[04:31] <zx2c4> i just want to keep this thing moving along the pipeline
[04:31] <zx2c4> and now its evidently stopped
[04:31] <zx2c4> but you're doing something to move it forward since you're on the sru team?
[04:34] <apw> zx2c4, i am
[04:34] <zx2c4> yay!
[04:34] <zx2c4> thanks a bunch
[04:35] -queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1 => 0.0.20170214-1ubuntu0.17.04] (no packageset)
[04:35] <zx2c4> woah whats that mean
[04:35] <zx2c4> wait now there are two in there
[04:35] <apw> zx2c4, yep, don't sweat it
[04:36] <apw> zx2c4, that is me just adding the bug number to the changelog
[04:36] <zx2c4> nice added the LP #
[04:36] <zx2c4> excellent
[04:38] -queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04]
[04:39] <zx2c4> cool so thats the old one going away
[04:40] <apw> yep
[04:42] -queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04]
[04:42] <zx2c4> accepted!
[04:42] <zx2c4> now it's in done!
[04:42] <apw> zx2c4, yep, looks tollerable and i assume that whats there is some kind of mess which will kill kittens from the bug description, so it has to be better than that
[04:43] <apw> zx2c4, it'll build and publish into zesty-proposed now, and can be double checked that it works for the purpose (people can upgrade to it and get fixed) etc
[04:43] <apw> zx2c4, and then it'll get released once that is done to -updates
[04:44] <zx2c4> what what kittens what better than that error:didnotparse
[04:44] <zx2c4> okay cool
[04:44] <zx2c4> so do i need to run a zesty machine and explicitly pull the package from zesty-proposed to try it and report back on the bug or something?
[04:44] <apw> from teh bug i assume the version in -release is toxic
[04:45] <apw> zx2c4, the bug will request someone tests it yes, if you can do that then that is helpful indeed
[04:46] <zx2c4> apw: oh, no, the issue is just that wireguard is experimental software and the contract that's made with distros is that it's fine to package if and only if each snapshot is updated and doesn't go stale. so the idea here would be to always track debian sid, which is maintained by dkg who is active with the project
[04:46] <zx2c4> so i very much would have preferred the ubuntu package to track debian sid
[04:46] <zx2c4> but evidently that's not how it works or something? so infinity just said to remove the package all together
[04:46] <zx2c4> that seemed a bit harsh and bad to me, but i'd rather have that then have an unacceptably outdated package in there
[04:47] <zx2c4> and now seeing the huge amount of paperwork involved to just make a simple version bump, it's making more sense to me that it might not just be "trivial" to track debian sid
[04:47] <apw> people would normally use a PPA for that kind of thing, for a development snapshot you want to update without having to jump thorough process hoops
[04:47] <zx2c4> yea
[04:48] <zx2c4> so that was the plan in the first place. it never was supposed to migrate out of sid anyway. so this whole business is just rectifying that error.
[04:48] <apw> ahh did it leak in debian as well ?
[04:50] <zx2c4> apw: no, dkg did the right hting and set it up not to do so
[04:50] <zx2c4> apw: oh, no
[04:50] <zx2c4> this package is wrong
[04:50] <zx2c4> i just checked the build
[04:50] <zx2c4> it's still instlaling files
[04:50] <zx2c4> because of LoB's changes!
[04:51] <zx2c4> im going to add a launchpad # to the changelog of the original minimal one
[04:53] <apw> zx2c4, there are nolonger any binaries in there, but yes, there looks to be an example in there, sigh
[04:53] <zx2c4> not good
[04:53] <zx2c4> im uploading a new tar.gz to the bug report
[04:54] <apw> zx2c4, you will need to increment the version of course
[04:54] <zx2c4> oh, ugh
[04:54] <zx2c4> really
[04:54] <zx2c4> ?
[04:54] <zx2c4> the other one is stuck in there?
[04:54] <zx2c4> okay ill submit two
[04:54] <zx2c4> this is nuts!
[04:54] <apw> does debian let you have two packages with the same version number and different contents ...
[04:54] <zx2c4> do i have to append the changelog, or can i just change the existing entry
[04:55] <apw> i'd just add a .1 on the end of teh 0.17.04 bit myself
[04:55] <zx2c4> apw: okay
[04:55] <zx2c4> so
[04:55] <zx2c4> 0.17.04.1
[04:55] <zx2c4> thats fine
[04:56] <zx2c4> do i need to add an entry to the top of the changelog, or can i simply modify the existing descriptive changelog entry?
[04:56] <apw> its pretty normal to have an incremental upload # in there
[04:56] <zx2c4> okay
[04:56] <apw> if we are killing the previous one without releasing i don't care if there is a new section or not
[04:56] <zx2c4> okay great
[04:57] <apw> zx2c4, you can delete the attachments if they are wrong
[04:58] <zx2c4> apw: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522/+attachment/4867673/+files/wireguard_0.0.20170214-1ubuntu0.17.04.1.tar.gz
[04:58] <ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
[04:58] <zx2c4> done.
[05:00] <zx2c4> apw: the .deb that those generate are perfect
[05:01] <zx2c4> so now we do the queue again?
[05:10] -queuebot:#ubuntu-release- Unapproved: wireguard (zesty-proposed/universe) [0.0.20170214-1ubuntu0.17.04 => 0.0.20170214-1ubuntu0.17.04.1] (no packageset)
[05:10] <zx2c4> nice!
[05:11] <zx2c4> its happening
[05:13] -queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (zesty-proposed) [0.0.20170214-1ubuntu0.17.04.1]
[05:14] <zx2c4> thanks apw
[05:21] <zx2c4> i really appreciate it
[05:24] <zx2c4> apw: so im supposed to wait for SRU to change the tag to -->verification-done, right? testers arent supposed to do it themselves?
[05:27] <apw> zx2c4, no you can test it and do that
[05:27] <zx2c4> oh, cool, okay
[05:27] <zx2c4> the -dkms package is changing from _amd64 -> _all
[05:27] <zx2c4> presumably that is okay though
[05:27] <zx2c4> rather, the -tools package is doing so
[05:28] <zx2c4> this is intended, since there's no platform specific code in the new package
[05:28] <apw> zx2c4, it will either work in testing or not, that is the key test
[05:29] <zx2c4> haha indeed
[05:29] <zx2c4> i manually dpkg -i'd the .deb but
[05:29] <zx2c4> i want to wait for it to sync to the index
[05:29] <zx2c4> so i can see precisely what hpapens with `apt install`
[05:29] <zx2c4> (i dont want to accidently accept this and then have to go through the whole process again)
[05:29] <apw> takes about 40m
[05:29] <zx2c4> cronjob i guess?
[05:30] <zx2c4> okay, so it's 7:30am in the morning here. i stayed up all night trying to figure out ubuntu build system (and failed, but then you saved me)
[05:30] <zx2c4> going to get some rest and then check&adjusttag first thing when i wake up
[05:31] <apw> its not much better here
[05:32] <zx2c4> :-D
[05:32] <zx2c4> Well thank you so so so much for your help
[05:32] <zx2c4> Very much appreciated
[05:32] <apw> np
[08:20] <Laney> 25/04 05:14:05 <apw>
[08:20] <Laney> !!!!
[08:21] <apw> Laney: happens ... ugg
[08:21] <acheronUK> insomnia strikes?
[08:21] <acheronUK> I know that feeling
[08:21]  * Laney pats apw 
[08:46] <apw> acheronUK, something like that
=== cjwatson_ is now known as cjwatson
[09:24] -queuebot:#ubuntu-release- Unapproved: ding-libs (xenial-proposed/main) [0.5.0-1 => 0.5.0-1ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[10:01] -queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (zesty-proposed) [1.164.1]
[10:12] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (yakkety-proposed) [1.28~16.10.1]
[10:14] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.28~16.04.1]
[10:15] <apw> slangasek, ^ you did that backport as far as xenial did you intend to go further ?
[10:19] -queuebot:#ubuntu-release- Unapproved: accepted caja [source] (zesty-proposed) [1.18.1-0ubuntu2]
[10:26] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (zesty-proposed) [1.164.1]
[10:56] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (zesty-proposed/main) [0.93.1ubuntu2 => 0.93.1ubuntu2.1] (desktop-core, ubuntu-server)
[11:31] <sergiusens> can I get snapcraft into -updates please? On pending SRU there's an ubuntu-image failure on i386 which I cannot relate to a snapcraft problem
[11:31] <sergiusens> apw: maybe you don't mind taking a look? ^
[11:31]  * apw looks
[11:37] <apw> sergiusens, ok all released ... remember artful is now open and to throw that in as well next time round
[11:41] <sergiusens> apw: thanks, and yeah, I was going to do it for this one to (push it to a) but it was still frozen at the time
[11:41] <apw> sergiusens, not a complaint, just a reminder
[11:41] <sergiusens> that said, can't wait for Y to EOL :-)
[11:42] <sergiusens> thanks again!
[11:57] <ginggs> would someone please 'force-badtest python-asdf/all/s390x' - looking at old test logs, it seems the tests have always failed on s390x, but only recently did the exit status starting getting returned
[11:59] <apw> it is very unsatisfactory that we have only /all/ for that, as it may start not being broken sometime
[11:59] <apw> Laney, ^ is there any way we can apply different fire to make that into always-failed ?
[11:59] <Laney> no
[12:00] <Laney> that would probably be a nice feature
[12:00] <Laney> but it's not there
[12:00] <Laney> we've talked about that before
[12:00] <apw> Laney, should we have some markup to say "remove this on this date" so we at least re-check every month/cycle/millenia
[12:02] <Laney> why is that python-asdf log a 404?
[12:04] <apw> Laney, oh has someone applied actual fire to the results perhaps ?
[12:04] <apw> Laney, http://autopkgtest.ubuntu.com/packages/p/python-asdf/artful/s390x
[12:04] <apw> as we only seem to have literally one result now, sadly a good one
[12:05] <Laney> what's that about
[12:05] <apw> oh and that one result the log is also gone
[12:05] <ginggs> old results here http://autopkgtest.ubuntu.com/packages/python-asdf/zesty/s390x
[12:05] <apw> Laney, oh it seems to systemic, i cannot hit any of the others either
[12:05] <ginggs> the first result for the new series always seems to 404
[12:05] <ginggs> happened with zesty too
[12:06] <xnox> apw, looking at zesty the logs are there and failed.
[12:06] <xnox> apw, i think artful logs links are broken, as they are copy of previous release or some such, no? or was everything retriggered?
[12:06] <Laney> I think it's copying the status from the previous release
[12:06] <Laney> that makes sense
[12:06] <ginggs> e.g. try hitting the log at the bottom of the zesty page, dated 2016-10-05 06:42:50 UTC
[12:06] <apw> oh and looking in teh wrong swift bucket for the result
[12:07] <xnox> apw, it seems to me that -2 is broken, as the only passes are with -1
[12:07] <xnox> and -2 was supposed to fix CI tests
[12:07] <xnox> hm
[12:07] <xnox> http://launchpadlibrarian.net/302710801/python-asdf_1.2.1-1_1.2.1-2.diff.gz
[12:07] <rbasak> bdmurray: opinion on releasing bug 1611816 to xenial-updates? It's not verified on Yakkety, and it seems unlikely that anyone will. So that would create a feature regression on Xenial->Yakkety upgrade ("any such feature must then also be added to any newer supported Ubuntu release")
[12:07] <ubot5> bug 1611816 in cifs-utils (Ubuntu Yakkety) "pam_cifscreds.so not supplied in package" [Medium,Fix committed] https://launchpad.net/bugs/1611816
[12:08] <rbasak> So should I hold releasing pending verification of Yakkety as well?
[12:08] <xnox> ginggs, why do you want force badtest? or why do you want -2 python-asdf?
[12:09] <ginggs> compare a -1 and a -2 log on s390x, they both have the same FAILURES
[12:09] <xnox> true
[12:09] <xnox> ginggs, but asdf is asserting things on as binary checksums and i clearly see bigendian fails.
[12:10] <Laney> looks like we managed to miss a bug before, and now we know about it
[12:11] <xnox> Laney, apw - i really wish we did not have :all packages auto published into all arches, idealy i'd make python-asdf:all to not be published into s390x, as clearly it is broken on that arch.
[12:11] <xnox> indeed, needs a bug report. I will follow up.
[12:11] <ginggs> xnox, yeah i'm not saying its not broken on big endian, i'm saying it's always been broken - so not a regression
[12:12] <Laney> Might as well get it out of proposed by fixing the bug rather than ignoring the test
[12:13] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92ubuntu1.3 => 0.92ubuntu1.4] (desktop-core, ubuntu-server)
[12:20] <xnox> https://bugs.launchpad.net/ubuntu/+source/python-asdf/+bug/1686079
[12:20] <ubot5> Ubuntu bug 1686079 in python-asdf (Ubuntu) "python-asdf is broken on big endian architectures" [High,Confirmed]
[12:20] <xnox> opened upstream bug report too on github
[12:20] <xnox> https://github.com/spacetelescope/asdf/issues/235
[12:21] <ginggs> xnox: thanks
[12:23] <Laney> <3
[12:24] <zx2c4> apw: verification done state! horrah https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1685522 -- everything worked perfectly
[12:24] <ubot5> Ubuntu bug 1685522 in wireguard (Ubuntu) "out of date snapshot" [Undecided,Confirmed]
[12:26] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.4 => 0.90ubuntu0.5] (desktop-core, ubuntu-server)
[12:45] <ahasenack> rbasak: I can try verifying that on yakkety
[12:45] <ahasenack> https://launchpad.net/bugs/1611816 I mean
[12:45] <ubot5> Ubuntu bug 1611816 in cifs-utils (Ubuntu Yakkety) "pam_cifscreds.so not supplied in package" [Medium,Fix committed]
[12:45] <rbasak> ahasenack: thanks!
[13:09] <rbasak> RAOF: I thought it was Wednesday for some reason. I've been releasing SRUs from the proposed report.
[13:22] <apw> rbasak, the sru table doesn't seem to have people assigned anymore
[13:29]  * sil2100 needs to finally assign himself to a day
[13:30] <zx2c4> apw: so is the next step pushing the button to move from -proposed to main?
[13:30] <zx2c4> or is that another team typically?
[13:33] <rbasak> apw: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing ?
[13:34] <sil2100> I added myself on Monday, since I assume Adam might be too occupied for SRU publishing usually
[13:43]  * apw boggles at what he was reading
[13:44] <apw> zx2c4, that will happen as a matter of course if you have verified it
[13:44] <zx2c4> i changed the tag to verified-done
[13:45] <zx2c4> hopefully thats correct
[13:45] <apw> oh it was archive admin days
[13:50] <mitya57> It should be ‘verification-done’, not ‘verified-done’.
[13:54] -queuebot:#ubuntu-release- Unapproved: rejected iproute2 [source] (yakkety-proposed) [4.3.0-1ubuntu3.16.10.1]
[13:54] -queuebot:#ubuntu-release- Unapproved: sbuild (yakkety-proposed/universe) [0.71.0-2ubuntu1 => 0.71.0-2ubuntu1.1] (no packageset)
[13:55] <rbasak> Archive admins have days? :)
[13:55] <ogra_> periodical :)
[13:56] <apw> yeah it should be archive admin nights really
[14:01] <bdmurray> rbasak: that type of bug seems trivial enough to verify on yakkety that I, as an SRU team member, might just do it
[14:05] <rbasak> bdmurray: fair enough, but what about the general case?
[14:09] <xnox> slangasek, both sbuild and autopkgtest "regressions" are either test failures themself; or interaction failure of autopkgtest with autopkgtest...
[14:09] <xnox> Laney, is on the case to fix autopkgtest/xenial test failure.
[14:09] <xnox> i have uploaded sbuild/yakkety fix into unapproved queue.
[14:09] <xnox> still need to figure out how to backport the test fixes to sbuild/xenial, given older sbuild there.
[14:11] <bdmurray> rbasak: I'd think about how long the interim release, Y in this case, is supported.
[14:16] <bdmurray> rbasak: People aren't likely to upgrade from X to Y at this point in time, take bug 1676547 for example. ;-)
[14:16] <ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
[14:17] <bdmurray> cyphermox: speaking of is there some more testing that should be done to cover "if devices that should be explicitly ignored by" NM?
[14:18] <cyphermox> no, it's pretty much just the upgrade test
[14:18] <bdmurray> okay I wasn't sure if an upgrade with a special configuration should be tested
[14:18] <cyphermox> the intent is to not break people's systems on upgrade, if they then want to start using netplan, it will still require manual intervention
[14:19] <cyphermox> well, you could enable netplan and then upgrade.
[14:19] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.4]
[14:19] <cyphermox> let me add that to the testcase, and then I'll spin up a VM to do that test
[14:19] <bdmurray> cyphermox: sounds good, thanks!
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.5]
[14:22] <jbicha> bdmurray: if someone wants to upgrade to Z, they have to go through Y, right?
[14:23] <bdmurray> jbicha: not if Y is EoL
[14:27] <jbicha> so in a few months, you can upgrade directly from X to Z?
[14:32] -queuebot:#ubuntu-release- Unapproved: autopkgtest (xenial-proposed/main) [4.3~ubuntu16.04.1 => 3.20.4ubuntu1] (core)
[14:37] <bdmurray> jbicha: Yes
[15:04] -queuebot:#ubuntu-release- Unapproved: sbuild (xenial-proposed/universe) [0.67.0-2ubuntu7 => 0.67.0-2ubuntu7.1] (no packageset)
[15:24] <Laney> What's the haps on autosync?
[15:26] -queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.2-2~ubuntu14.04.1 => 3.4-1~ubuntu14.04.1] (ubuntu-desktop)
[15:26] -queuebot:#ubuntu-release- Unapproved: sosreport (yakkety-proposed/main) [3.3-1 => 3.4-1~ubuntu16.10.1] (ubuntu-desktop, ubuntu-server)
[15:26] -queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.2+git276-g7da50d6-3ubuntu1 => 3.4-1~ubuntu16.04.1] (ubuntu-desktop, ubuntu-server)
[15:28] -queuebot:#ubuntu-release- Unapproved: sosreport (zesty-proposed/main) [3.3+git50-g3c0349b-2 => 3.4-1~ubuntu17.04.1] (ubuntu-desktop, ubuntu-server)
[15:31] <infinity> Laney: I'll be turning it on soon.  Was just giving people a chance to do some manual merges and mini-transitions if they felt the urge.
[15:32] <Laney> I feel the urge for some hot de-tangling action
[15:32] <infinity> Oh baby.
[15:33] <Laney> Stupid freeze probably limits the fun though
[15:35] <infinity> Which freeze?
[15:36] <davmor2> all of them
[15:36] <infinity> Oh, the Debian freezew.
[15:36] <infinity> s/w//
[15:38] <slangasek> apw: backport> that's in reference to shim-signed?  I hadn't yet because IIRC there's still another shim-signed in process for trusty and it's not critical right now
[15:42] <apw> slangasek, ahh yes shim-signed indeed ... thanks
[16:27] -queuebot:#ubuntu-release- Unapproved: binutils (trusty-proposed/main) [2.24-5ubuntu14.1 => 2.24-5ubuntu14.2] (core)
[16:45] <slangasek> infinity: why is gcc spitting noise about ignoring /usr/share/dpkg/ in the colord testsuite in artful? http://autopkgtest.ubuntu.com/packages/c/colord/artful/armhf
[16:45] <slangasek> that's /usr/share/dpkg/pie-compile.specs, /usr/share/dpkg/pie-link.specs
[16:46] <slangasek> I thought it was resolved that dpkg would not be trying to mangle specs anymore
[16:50] <infinity> slangasek: That's not entirely how that bug played out, no.
[16:51]  * tsimonq2 high-fives Laney - merge fun! :D
[16:51] <infinity> slangasek: In the end, with PIE being enabled on all Debian arches, I think we need to revert that gcc patch.
[16:52] <slangasek> infinity: can you elaborate?  I thought doko's position was very clear, that dpkg should not be overriding specs.  And in those build logs I see gcc being passed a -spec option courtesy of dpkg-buildflags
[16:58] <infinity> slangasek: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848129 is a "fun" read.
[16:58] <ubot5> Debian bug 848129 in dpkg-dev "pie-link specs should not be passed when pie is not enabled" [Important,Fixed]
[17:05] <infinity> slangasek: So, basically, the (broken, IMO) gcc patch will trip for arches where PIE isn't the default and hardening=+pie (or +all) is passed.  I could switch that to -fPIE -pie instead, but that will, as guillem points out, cause other build regressions.  This all got papered over in Debian because there are no official Debian arches that aren't PIE-by-default anymore, and the patch doesn't filter the spec file for pie *disabling*, just the ...
[17:05] <infinity> ... inverse.
[17:08] <infinity> slangasek: I guess when I asked doko if he was okay with the current state of dpkg, I had wrongly assumed he'd backed out this patch, since the two are clearly not compatible. :/
[17:09] <slangasek> ok
[17:11] <slangasek> infinity: trying to understand exactly what was changed here, it seems that pie was moved out of Dpkg/Vendor/Default.pm and into Dpkg/Vendor/Debian.pm; but doesn't that just mean that Ubuntu inherits from there?
[17:11] -queuebot:#ubuntu-release- Unapproved: rejected binutils [source] (trusty-proposed) [2.24-5ubuntu14.2]
[17:11] <slangasek> so for places where Ubuntu and Debian have different PIE behavior, dpkg is still wrong AIUI
[17:12] <infinity> slangasek: Nah, cause I also changed the whitelist.
[17:12] <slangasek> ah
[17:12] <slangasek> ok
[17:12] <infinity> slangasek: (Yes, the whitelist should be a vendor var, but it's not, so oh well)
[17:12] <slangasek> infinity: then I think I will ignore this until doko is back
[17:13] <infinity> I'm tempted to pull out the gcc patch and suffer his wrath on return.
[17:13] <infinity> Because as it stands, hardening=+pie will not work on 3/6 of our arches.
[17:13] <infinity> Which is not ideal as I'm about to turn on autosyncs.
[17:14] <slangasek> ah is that the impact - yeah, that seems worth backing out the patch then
[17:14] <slangasek> infinity: you'll flag it to him as well?
[17:14] <infinity> I'll let him know.  And put on a helmet.
[17:14] <slangasek> ok
[17:15] <infinity> The other option, as I said, is to make +pie use -fPIE -pie flags instead of specs.
[17:15] <infinity> Which is more error-prone, but also less controversial in the short term.
[17:16] <infinity> Likely to blow up a bunch of library builds, though.
[17:16] <infinity> So, perhaps less than ideal. :P
[17:35] <bdmurray> cyphermox: with regards to bug 1676547 - will people with only -security enabled upgrading from 16.04 be affected?
[17:35] <ubot5> bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
[17:45] <slangasek> xnox: so the sbuild sru is a wholesale backport of the autopkgtest?
[17:48] <xnox> slangasek, yeap; as is in yakkety; with a further tweak in xenial.
[17:49] <xnox> slangasek, there are about 5-6 upstream commits; cherry-picking individual fixes, exposes other bugs, that were fixed up later. Thus imho updating to latest version of the test is the best course of action.
[17:49] <xnox> the actual amount of testing of /sbuild/ is the same.
[17:49] <xnox> e.g. both before and after, it is verified that it can create $devel and build procenv in it.
[17:49]  * slangasek nods
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted sbuild [source] (yakkety-proposed) [0.71.0-2ubuntu1.1]
[17:51] -queuebot:#ubuntu-release- Unapproved: accepted sbuild [source] (xenial-proposed) [0.67.0-2ubuntu7.1]
[17:53] <cyphermox> bdmurray: no, they wouldn't be affected.
[17:55] <slangasek> xnox: and autopkgtest^2 failure is due to wrong assumptions about /proc/cpuinfo?
[17:56] <xnox> he?
[17:56] <slangasek> xnox: autopkgtest/armhf autopkgtest failed for apt
[17:56] <slangasek> and it's looking for cpu_model and can't find it
[17:56] <slangasek> just confirming if that matches your understanding of the root cause
[17:58] <slangasek> the xenial one is different
[18:00] <xnox> well xenial has that too on armhf only
[18:00] <xnox> FAILED (failures=2, skipped=141)
[18:00] <xnox> maybe Laney and I should have looked at armhf and cherrypick a fix for that too.
[18:00] <xnox> there is no cpu_model on arm64
[18:01] <xnox> i got disconnected, what was the last message that got through?
[18:01] <xnox> well, i guess arm64 is not armv7l =)
[18:02] <xnox> https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=1f619a921083f4f9992adeb007257db50b6530a2
[18:02] <xnox> https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/commit/?id=37030cd0ee15151307dfe4b8416bf3dff9525c6b
[18:02] <xnox> arm64 should fake armhf harder =)
[18:04] <infinity> xnox: kernel personalities have never altered cpuinfo, that way lies madness.
[18:04] <infinity> (people relying on cpuinfo to be anything other than casually informative are usually wrong)
[18:05] <xnox> infinity, cool, can i haz real armhf in scalingstack? =) kthxbye
[18:05]  * xnox EOD
[18:06] <slangasek> xnox: no
[18:06] <slangasek> HTH HAND
[18:07] <xnox> i had to google both HTH and HAND
[18:07] <nacc> heh
[18:08] <xnox> infinity, lxc does fake things in /proc e.g. it fakes uptime.
[18:21] <slangasek> infinity: if you are doing the gcc patch revert, can you let me know once that's published so I can retry colord autopkgtests?
[18:23] <infinity> xnox: s/lxc/namespaces/ yeah.  But namespaces and personalities don't relate at all.
[18:23] <infinity> slangasek: I'll get on that in a sec.
[18:24] <slangasek> infinity: no hurry, just asking for the signal to be raised :)
[19:06] <bdmurray> infinity: speaking of cpuinfo does what we are collecting in zesty look good?
[19:08] <bdmurray> an example - https://launchpadlibrarian.net/316253544/ProcCpuinfoMinimal.txt
[19:17] <infinity> bdmurray: Have any from ~x86 systems?
[19:18] <infinity> bdmurray: But that LGTM for x86.
[19:18] <infinity> bdmurray: Oh, except...
[19:18] <infinity> bdmurray: Didn't one iteration of this take the *last* cpu instead of the *first*, so we'd pick up on the fact that there were more than one?
[19:18] <infinity> Oh, that celeron might only have one.
[19:19] <infinity> May have been a bad example. :)
[19:23] <bdmurray> infinity: I think the first CPU is 0.
[19:23] <infinity> bdmurray: Oh, it is indeed.  So that Celeron, being a Celeron, is just dinky and has two cores.
[19:24] <infinity> bdmurray: So, yes, that collected info is a +1 from me for x86.
[19:24] <bdmurray> infinity: Okay, I'll look for non-x86 then think about SRU'ing apport.
[19:24] <infinity> bdmurray: But x86 doesn't have the CPU\n\nExtra_info bit that some !x86 arches do, so that Extra_info is the bit I'd also like to make sure we're collecting.
[19:26] <bdmurray> infinity: bug 1680507 seems fine too
[19:26] <ubot5> bug 1680507 in linux (Ubuntu Zesty) "breakpoint test from ubuntu_kernel_selftest failed to build on aarch64 " [Medium,Confirmed] https://launchpad.net/bugs/1680507
[19:27] <infinity> bdmurray: arm64 is the same layout as x86. ;)
[19:28] <nacc> ppc64el has the weird stuff at the end, iirc
[19:28] <nacc> about the fw level and stuff
[19:28] <infinity> bdmurray: Any hope for ppc... What he said.
[19:28] <infinity> sparc does too, but we don't support sparc. :P
[19:28] <infinity> So does armv7.
[19:29] <infinity> And s390x is just entirely bizarre.
[19:29] <bdmurray> Now I'm sorry I asked.
[19:29] <nacc> heh
[19:30] <nacc> and they are all different
[19:31] <infinity> s390x cpuinfo is beyond different.
[19:31] <infinity> We need a time machine to actually define a format for that.
[19:31] <nacc> :)
[19:51] <cjwatson> We might want to look at switching cdimage to python3 soon now that nusakan's on xenial.
[19:51] <cjwatson> The code's been tested with both for ages.
[19:51] <cjwatson> I just didn't want to deal with 3.2 in production ...
[19:55] <infinity> slangasek: Oh, this might not be super contentious.  doko disabled the patch on Debian, just forgot (I presume) to do so on Ubuntu.
[19:57] <bdmurray> slangasek: looking at http://cdimage.ubuntu.com/lubuntu/releases/16.10/release/ some of the wording between 64 bit / 32 bit could use an update too
[19:58] <slangasek> bdmurray: the current wording is generated from scripts in lp:ubuntu-cdimage; if the existing language is wrong we should fix that there
[19:58] <slangasek> infinity: ah ok
[19:59] <bdmurray> slangasek: ack it seems to direct people to the 32 bit image e.g. "if you need support for 32-bit code" and "For almost all PCs".
[20:01] <infinity> bdmurray: We could just update i386 to say "don't use this; if you use this, you're bad and should feel bad"
[20:02] <bdmurray> infinity: "and upgrading in the future will be terrible"
[20:02] <ginggs> I know many people who are caught out by the 64-bit description mentioning AMD, and the 32-bit description mentioning Intel/AMD
[20:02] <infinity> bdmurray: (I don't think the "if you need full support for 32-bit" part is out of line, but the bits about which ports run on which machines could use an update)
[20:03] <infinity> A bit of wikipedia research to figure out when all Intel machine supported long mode and then updating amd64 to say "for all modern PCs manufactured after 2007" or whatever might be better.
[20:03] <infinity> s,PCs,Intel/AMD PCs,'
[20:03] <infinity> Since the term "PC" is stupidly overloaded and meaningless.
[20:56] -queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.20 => 1.2.21] (core)
[20:57] -queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3.5 => 1.3.6] (core)
[20:57] -queuebot:#ubuntu-release- Unapproved: apt (zesty-proposed/main) [1.4 => 1.4.1~17.04.1] (core)
[21:02] -queuebot:#ubuntu-release- Unapproved: binutils (trusty-proposed/main) [2.24-5ubuntu14.1 => 2.24-5ubuntu14.2] (core) (sync)
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (trusty-proposed) [2.24-5ubuntu14.2]
[21:27] <mwhudson> can someone (infinity, slangasek?) review golang-defaults on https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text= please
[23:07] <robert_ancell> jbicha, hey, was just about to restart into GNOME so wasn't on IRC
[23:08] <robert_ancell> argh, wrong channel
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [amd64] (artful-proposed) [2:1.8~1ubuntu1]
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [armhf] (artful-proposed) [2:1.8~1ubuntu1]
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [ppc64el] (artful-proposed) [2:1.8~1ubuntu1]
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [arm64] (artful-proposed) [2:1.8~1ubuntu1]
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [s390x] (artful-proposed) [2:1.8~1ubuntu1]
[23:13] -queuebot:#ubuntu-release- New: accepted golang-defaults [i386] (artful-proposed) [2:1.8~1ubuntu1]
[23:22] -queuebot:#ubuntu-release- New: accepted libva-utils [arm64] (artful-proposed) [1.8.1+ds1-1]
[23:22] -queuebot:#ubuntu-release- New: accepted libva-utils [s390x] (artful-proposed) [1.8.1+ds1-1]
[23:22] -queuebot:#ubuntu-release- New: accepted libva-utils [armhf] (artful-proposed) [1.8.1+ds1-1]
[23:22] -queuebot:#ubuntu-release- New: accepted case [amd64] (artful-proposed) [1.5.3+dfsg-1]
[23:22] -queuebot:#ubuntu-release- New: accepted libva-utils [i386] (artful-proposed) [1.8.1+ds1-1]
[23:23] -queuebot:#ubuntu-release- New: accepted libva-utils [amd64] (artful-proposed) [1.8.1+ds1-1]
[23:23] -queuebot:#ubuntu-release- New: accepted libva-utils [ppc64el] (artful-proposed) [1.8.1+ds1-1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [i386] (artful-proposed) [1.18.1-0ubuntu1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [ppc64el] (artful-proposed) [1.18.1-0ubuntu1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [amd64] (artful-proposed) [1.18.1-0ubuntu1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [armhf] (artful-proposed) [1.18.1-0ubuntu1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [arm64] (artful-proposed) [1.18.1-0ubuntu1]
[23:24] -queuebot:#ubuntu-release- New: accepted caja-extensions [s390x] (artful-proposed) [1.18.1-0ubuntu1]
[23:36] -queuebot:#ubuntu-release- Unapproved: golang-github-gosexy-gettext (zesty-proposed/main) [0~git20130221-0ubuntu12 => 0~git20130221-0ubuntu13] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:37] -queuebot:#ubuntu-release- Unapproved: golang-gopkg-flosch-pongo2.v3 (zesty-proposed/main) [3.0+git20141028.0.5e81b81-0ubuntu7 => 3.0+git20141028.0.5e81b81-0ubuntu8] (edubuntu, ubuntu-server)
[23:38] -queuebot:#ubuntu-release- Unapproved: golang-context (zesty-proposed/main) [1.1-1ubuntu8 => 1.1-1ubuntu9] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:38] -queuebot:#ubuntu-release- Unapproved: golang-gopkg-lxc-go-lxc.v2 (zesty-proposed/main) [0.0~git20161126.1.82a07a6-0ubuntu3 => 0.0~git20161126.1.82a07a6-0ubuntu4] (edubuntu, ubuntu-server)
[23:38] -queuebot:#ubuntu-release- Unapproved: golang-goprotobuf (zesty-proposed/main) [0.0~git20161116.0.224aaba-3ubuntu1 => 0.0~git20161116.0.224aaba-3ubuntu2] (edubuntu, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-github-mattn-go-colorable (zesty-proposed/main) [0.0.6-1ubuntu5 => 0.0.6-1ubuntu6] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-gocapability-dev (zesty-proposed/main) [0.0~git20150716.0.2c00dae-1ubuntu7 => 0.0~git20150716.0.2c00dae-1ubuntu8] (edubuntu, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-petname (zesty-proposed/main) [2.6-0ubuntu1 => 2.6-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-yaml.v2 (zesty-proposed/main) [0.0+git20170125.0.4c78c97-0ubuntu1 => 0.0+git20170125.0.4c78c97-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-github-olekukonko-tablewriter (zesty-proposed/main) [0.0~git20151029.0.a5eefc2-1ubuntu6 => 0.0~git20151029.0.a5eefc2-1ubuntu7] (edubuntu, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-github-pborman-uuid (zesty-proposed/main) [0.0+git20150824.0.cccd189-1ubuntu7 => 0.0+git20150824.0.cccd189-1ubuntu8] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:40] -queuebot:#ubuntu-release- Unapproved: golang-x-text (zesty-proposed/main) [0.0~git20161013.0.c745997-2ubuntu1 => 0.0~git20161013.0.c745997-2ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:59] <slangasek> tsimonq2: are you sure that the rationale given for the healpix-cxx name revert is correct?  It doesn't seem to match the upstream (Debian) rationale, which rather says "ehhh we already were building with g++6 so there's no compatibility issue"