[00:02] -queuebot:#ubuntu-release- New binary: vine [amd64] (artful-proposed/universe) [1.1.3+dfsg-2] (no packageset)
[00:12] <tsimonq2> slangasek: For what it's worth, I hate to put blame on anyone, but look at the bug report associated with my upload.
[00:12] <tsimonq2> slangasek: I originally just wanted to keep the delta as-is and just merge from Debian, but what mapreri said seemed to make sense.
[00:13] <tsimonq2> slangasek: Also, as a question for you, what is the difference between healpix-cxx and freehdl irt this?
[00:13] <tsimonq2> slangasek: Because I'm not seeing a difference myself (but I could be wrong).
[00:15] <tsimonq2> slangasek: (and I used freehdl as a model for my follow-up fix, as I noted in the bug report)
[00:19] <tsimonq2> slangasek: Also, I could be wrong, but I have to do what I did because it was *already* renamed...
[00:22] <tsimonq2> slangasek: fwiw here's a bug report bug 1685546
[00:22] <ubot5> bug 1685546 in healpix-cxx (Ubuntu) "Merge 3.30.0-6 from Debian Sid" [Wishlist,Fix committed] https://launchpad.net/bugs/1685546
[00:23] <tsimonq2> slangasek: So to answer your question, yes, I'm pretty sure. Please, if I'm mistaken, prove me wrong. :)
[00:28] <mwhudson> oh haha all those golang uploads were meant to be for artful :(
[00:28] <jbicha> mwhudson: did you do "dch -r"?
[00:29] <mwhudson> i did not
[00:29] <mwhudson> i also need to find the hammer to get dch to stop complaining about a distribution name it doesn't know about
[00:30] <mwhudson> oh "yes |" works
[00:36] <Ukikie> mwhudson: Don't have the latest distro-info-data..?
[00:40] <nacc> mwhudson: --force-distribution
[00:58] <tsimonq2> Oh, and Lintian.
[00:58] <tsimonq2> I hate how Lintian keeps yelling at me... :P
[01:10] <slangasek> tsimonq2: right; so the argument in Debian AIUI is "we don't need a transition because it was never in a stable release", not "we don't need a transition because the ABI didn't change"
[01:11] <tsimonq2> !info healpix-cxx xenial
[01:11] <ubot5> Package healpix-cxx does not exist in xenial
[01:11] <tsimonq2> OH
[01:11] <tsimonq2> Hmmm
[01:11] <tsimonq2> Wait nevermind.
[01:12] <tsimonq2> !info libhealpix-cxx0v5 xenial
[01:12] <ubot5> libhealpix-cxx0v5 (source: healpix-cxx): representation of spherical data - C++ shared library. In component universe, is optional. Version 3.11.2-7.1ubuntu1 (xenial), package size 289 kB, installed size 958 kB
[01:12] <tsimonq2> slangasek: But it's in an LTS release, I thought that meant we have to keep our delta until Artful+1?
[01:13] <slangasek> tsimonq2: whereas in Ubuntu, libhealpix-cxx0 *was* in a stable release (vivid); so if there is an ABI change when rebuilding with g++6 vs. 5, that is relevant to us but not to Debian
[01:13] <tsimonq2> slangasek: Sure.
[01:13] <slangasek> g++5 vs. g++4.9 actually
[01:13] <tsimonq2> slangasek: So what's the problem?
[01:14] <slangasek> tsimonq2: the Provides: is possibly the problem
[01:14] <slangasek> tsimonq2: sorry, I should have led with that - have you checked that the ABI of libhealpix-cxx0 in vivid matches the ABI of libhealpix-cxx0v5 in xenial+?
[01:16] <tsimonq2> slangasek: I have not personally verified that, no.
[01:16] <tsimonq2> slangasek: But we have carried the delta through 17.04.
[01:16] <tsimonq2> slangasek: So I guess I'm failing to understand what the problem is.
[01:17] <slangasek> tsimonq2: your merge has *changed* the package layout; you are declaring a Provides that wasn't there before; I am asking for proof that it is correct
[01:17] <slangasek> you can only say Provides: if the ABIs are functionally identical
[01:18] <slangasek> oops, hang on
[01:18] <slangasek> ok, the Provides is certainly correct ;)
[01:18] <slangasek> because the ABI of the new libhealpix-cxx0 is necessarily the same as the ABI of the previous libhealpix-cxx0v5
[01:18] <slangasek> but it's not necessarily the same as the ABI of the previous libhealpix-cxx0
[01:18] <tsimonq2> slangasek: So then tell me, what says that it's correct?
[01:19] <tsimonq2> slangasek> you can only say Provides: if the ABIs are functionally identical - ah ok, didn't read this, nvm
[01:19] <slangasek> but the previous libhealpix-cxx0 is before the last LTS
[01:19] <tsimonq2> Yes, it is.
[01:20] <slangasek> so by that measure, I'll add it to the bucket of "we're not sure this was actually correct but we'll follow Debian on it and blame them if it breaks".
[01:20] <slangasek> and accept it from new
[01:20] <slangasek> tsimonq2: thanks for listening to me babble ;)
[01:20] <tsimonq2> slangasek: No, thanks for listening to ME babble. ;)
[01:20] <tsimonq2> slangasek: And thanks for the review. :)\
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [amd64] (artful-proposed) [3.30.0-6ubuntu1]
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [armhf] (artful-proposed) [3.30.0-6ubuntu1]
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [ppc64el] (artful-proposed) [3.30.0-6ubuntu1]
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [arm64] (artful-proposed) [3.30.0-6ubuntu1]
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [s390x] (artful-proposed) [3.30.0-6ubuntu1]
[01:21] -queuebot:#ubuntu-release- New: accepted healpix-cxx [i386] (artful-proposed) [3.30.0-6ubuntu1]
[01:22] <tsimonq2> \o/
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [amd64] (artful-proposed) [1.3.1-2ubuntu1]
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [armhf] (artful-proposed) [1.3.1-2ubuntu1]
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [ppc64el] (artful-proposed) [1.3.1-2ubuntu1]
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [arm64] (artful-proposed) [1.3.1-2ubuntu1]
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [s390x] (artful-proposed) [1.3.1-2ubuntu1]
[01:29] -queuebot:#ubuntu-release- New: accepted libepoxy [i386] (artful-proposed) [1.3.1-2ubuntu1]
[01:42] -queuebot:#ubuntu-release- New: accepted vine [amd64] (artful-proposed) [1.1.3+dfsg-2]
[02:30] <mwhudson> slangasek: can you mainify https://launchpad.net/ubuntu/+source/golang-1.8 ?
[02:30] <mwhudson> ah i guess it's getting a bit late there
[03:48] <slangasek> mwhudson: done anyway :)
[05:11] -queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.7.1 => 0.96.24.7.2] (desktop-core, ubuntu-server) (sync)
=== cpaelzer_ is now known as cpaelzer
[05:31] <kees> zesty is missing from the top page of wiki.ubuntu.com and I can't log in to the wiki for some reason :(
[05:34] <apw> kees, hmmm
[05:35] <kees> ah, it was just really really slow.
[05:35] <kees> fixed now
[05:36] <apw> kees, wiki and really slow are synonymous for sure
[05:36] <kees> hehe
[07:39] <mwhudson> slangasek: thanks
[08:05] <Laney> xnox: yeh feel free to test/upload
[08:05] <Laney> I only looked at that one you were complaining about
[08:27] <LocutusOfBorg> anybody can understand with me why llvm-toolchain-3.7 is not migrating? AA powers might be needed :)
[08:28] <apw> llvm-3.7-examples/amd64 unsatisfiable Depends: llvm-3.7-dev (>= 1:3.7.1-5)
[08:29] <LocutusOfBorg> yes, and I asked ( infinity did IIRC) to remove binaries on amd64
[08:30] <apw>  llvm-3.7-dev      | 1:3.7.1-5        | artful-proposed/universe | arm64, armhf
[08:30] <apw> so examples is uninstallable because it depends on it
[08:30] <LocutusOfBorg> yes, I/we intentionally are building it only for arm*
[08:30] <LocutusOfBorg> so, arch:all can't exist because somewhere they are not installable? seems strange
[08:30] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.11 => 1:2.5+dfsg-5ubuntu10.13] (ubuntu-server, virt) (sync)
[08:30]  * apw thinks about that
[08:31] <LocutusOfBorg> an arch:all can't depend on an arch:any package, otherwise it becomes uninstallable where such "any" is not built
[08:31] <apw> that seems to be a true statement
[08:31] <LocutusOfBorg> but examples depends on development packages
[08:32] <LocutusOfBorg> there is no need to have examples on amd64 because the library is not available
[08:32] <LocutusOfBorg> but meh, they are arch:all, so built for everybody
[08:32] <apw> we might have to arch limit that example dep
[08:33] <cpaelzer> ah while I see you here LocutusOfBorg, yes I think the merge on me is fine, I saw on mom that you added me as comment
[08:33] <cpaelzer> LocutusOfBorg: we will roadmapify all our merges soon if you need any sort of further confirmation
[08:33] <LocutusOfBorg> cpaelzer, I don't know how to add people on MoM, but thanks, even if I don't remember the package (strongswan?)
[08:34] <cpaelzer> LocutusOfBorg: yes the swan
[08:34] <LocutusOfBorg> thanks!, I hate doing no-change rebuilds and being accounted on MoM
[08:47] <LocutusOfBorg> apw, seems that Debian force-hinted it to let it migrate
[08:47] <LocutusOfBorg> since we disabled llvm-3.7 on archs because we *don't* want people using it anymore
[08:48] <LocutusOfBorg> it seems something useful
[08:50] <mapreri> all depends on britney's conf, mind yo
[08:50] <mapreri> you*
[08:50] <mapreri> https://anonscm.debian.org/git/mirror/britney2.git/tree/britney.conf#n36
[08:50] <mapreri> # if you're not in this list, arch: all packages are allowed to break on you
[08:50] <mapreri> NOBREAKALL_ARCHES = i386 amd64
[08:51] <mapreri> might be different on ubuntu
[09:04] <LocutusOfBorg> apw, force-hint pretty please?
[09:05] <xnox> Laney, tah
[09:07] <infinity> LocutusOfBorg: No.
[09:09] <infinity> LocutusOfBorg: arch-restrict llvm-3.7-examples or, here's a novel thought, stop producing the package entirely, since you "don't want people using that version".
[09:10] <LocutusOfBorg> infinity, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/7737290/+listing-archive-extra I'm already testing the first
[09:28] <apw> LocutusOfBorg, force-hint> that doesn't seem like the right approach ...
[09:28] <LocutusOfBorg> it did seem the right approach for Debian Release
[09:28] <LocutusOfBorg> anyhow, will probably ask to move to a recommends or similar
[10:43] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.102-0ubuntu0.16.04.2]
=== santa is now known as Guest77025
[12:07] <LocutusOfBorg> infinity, "missing build on amd64: clang-3.7-doc, liblldb-3.7, liblldb-3.7-dbg, liblldb-3.7-dev, lldb-3.7, lldb-3.7-dev, llvm-3.7-examples (from 1:3.7.1-3ubuntu4) "
[12:07] <LocutusOfBorg> now with that removal we should be good, right?
=== klebers_ is now known as klebers
[12:16] <LocutusOfBorg> just for next time, where did mark blog the artful codename? :)
[12:17] <ogra_> i think he didnt this time
[12:17] <LocutusOfBorg> so... who choose it?
[12:17] <apw> mark
[12:17] <ogra_> i didnt say he didnt chose it :)
[12:17] <LocutusOfBorg> interesting :)
[12:18] <ogra_> he just didnt blog about it it seems
[12:18] <LocutusOfBorg> I used to go on that website to understand when the archive was opening
[12:18] <LocutusOfBorg> I missed two days of work :)
[12:18] <ogra_> not trusting infinity's mails ?
[12:20] <LocutusOfBorg> I'm subscribed to ubuntu-devel and ubuntu-devel-discuss, where did that mail go?
[12:20] <ogra_> ubuntu-release
[12:20] <LocutusOfBorg> ough
[12:20] <ogra_> iirc
[12:21] <ogra_> ah, no ... ubuntu-devel-announce actually
[12:21] <LocutusOfBorg> thanks, will check my subscription then
[12:29] <LocutusOfBorg> BTW I plan to pass the llvm-3.8 arm64 test hang to doko when he is back from VAC :/ I don't really have clues, but seems somewhat a gcc timeout
[12:38] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.4-1~ubuntu16.04.1]
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.4-1~ubuntu14.04.1]
[12:46] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (yakkety-proposed) [3.4-1~ubuntu16.10.1]
[12:47] -queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (zesty-proposed) [3.4-1~ubuntu17.04.1]
[12:55] -queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.21]
[12:57] -queuebot:#ubuntu-release- Unapproved: accepted apt [source] (yakkety-proposed) [1.3.6]
[13:00] -queuebot:#ubuntu-release- Unapproved: rejected iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.1]
[15:10] <dax> howdy! what's the difference between "current" and "pending" on http://cdimage.ubuntu.com/daily-live/ in general? I assume pending becomes current after $something, just not sure what that is.
[15:10] <slangasek> dax: after automated smoketests pass, if any exist
[15:12] <dax> thanks :)
[15:32] <slangasek> mwhudson: I promoted golang-1.8 but it wants demoting; golang-defaults hasn't migrated?
[15:33] <slangasek> mwhudson: because golang-defaults wants gccgo-go to be promoted, this harkens back to the conversation with infinity
[15:40] <slangasek> mwhudson: n/m, gccgo-go itself is a binary that should be demoted; fixing now
[15:42] <slangasek> why is the gcc-6 build horrible on arm64 :P
[15:45] <LocutusOfBorg> slangasek, wrt LP: #1667834
[15:45] <ubot5> Launchpad bug 1667834 in php7.1 (Ubuntu) "[FFe] Please remove php7.1 from zesty" [Undecided,Triaged] https://launchpad.net/bugs/1667834
[15:45] <LocutusOfBorg> can I remove the block?
[15:45] <slangasek> LocutusOfBorg: it's not my block, it's the server team's; nacc ^^ ?
[15:45] <LocutusOfBorg> I mean, now it won't land on zesty anymore :p
[15:45] <LocutusOfBorg> maybe lets land it on artful
[15:46] <LocutusOfBorg> also 7.0 needs some mergecare :)
[15:46] <LocutusOfBorg> "One of my tasks in 17.10 will be to migrate php7.1 into main and drop php7.0."
[15:47] <LocutusOfBorg> I guess this means "remove after zesty"
[15:49] <nacc> LocutusOfBorg: yes i own php, i'll handle it
[15:49] <slangasek> LocutusOfBorg: yes, my setting the block was mechanics, it's the server team to consult about whether it's time to remove it now
[15:49] <nacc> LocutusOfBorg: is there a reason you need to remove it?
[15:50] <nacc> own for the server team, that is
[15:51] <LocutusOfBorg> since the bug was "don't land for zesty", and now zesty is closed, I thought about setting it as "fix released", something everybody would/might do while randomly looking at bugs
[15:52] <LocutusOfBorg> maybe you can retitle it, so people won't remove it by mistake :)
[15:52] <nacc> presuming that doesn't change the tag's effect, i don't care
[15:52] <nacc> slangasek: ?
[15:54] <nacc> ah based upon slangasek's comment in the bug, it needs to stay open
[15:55] <slangasek> nacc: keeping it open because you don't want it to migrate yet?
[15:55] <nacc> slangasek: yeah
[15:55] <slangasek> ok
[15:56] <nacc> slangasek: i'm going to merge php7.0 now (in process) so i can sru it back logically, then i'll work on the migration
[15:56] <slangasek> fwiw getting that done would let us clean up http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed, I would not mind seeing that happen :)
[15:56] <nacc> i synced up with ondrej on it last week so we are in line with debian on timelines for 17.10 and 18.04
[15:56] <nacc> slangasek: ack
[15:59] <LocutusOfBorg> thanks you both for caring
[15:59] <LocutusOfBorg> slangasek, on that page there is listed a package I maintain ndg-httpsclient
[15:59] <LocutusOfBorg> should I do something?
[16:00] <nacc> LocutusOfBorg: i updated the bug and assigned to myself for now
[16:00] <LocutusOfBorg> yep, I saw
[16:03] <slangasek> LocutusOfBorg: movements to universe don't require any action from developers; it's currently on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed but not on http://people.canonical.com/~ubuntu-archive/component-mismatches because packages in artful-proposed no longer need it in main but packages in artful still do. Once those packages migrate (I don't remember what it
[16:03] <slangasek> was, maybe it was conntrack?), it'll drop out
[16:03] <LocutusOfBorg> thanks
[16:04] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/python-urllib3/1.19.1-1
[16:04] <LocutusOfBorg> this is the reason I wild guess
[16:51] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-77.98] (core, kernel)
[16:53] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-77.98]
[17:55] <slangasek> ah, lubuntu-next image build failures, artful must be fully open
[17:55] <slangasek> anyone planning to make a non-failing lubuntu-next image build? :)
[18:16] <bdmurray> slangasek: Could you have look at bug 1680090? I'd like to release it and just want a rubber stamp that comment #9 isn't worth removing v-done.
[18:16] <ubot5> bug 1680090 in apt-xapian-index (Ubuntu Zesty) "python3-xapian not installed when apt-xapian-index upgraded" [High,In progress] https://launchpad.net/bugs/1680090
[18:17] <bdmurray> s/rubber stamp/second set of eyes to say/
[18:22] <slangasek> bdmurray: agreed
[18:23] <slangasek> bdmurray: dino99 is low signal-to-noise, he does craaaaazy things with his systems
[18:24] <bdmurray> slangasek: yes, I know that name
[19:24] <slashd> For SRU, I had a talk with apw and rbasak about this bug a couples weeks ago LP: #1674399, could you please look at this bug and based on the Descriptions and comment #6 if this looks eligible for SRU in Stable release ? (note that this is a HW enablement, not a bug, this is why I'm requesting you to have a look at it) thanks in advance
[19:24] <ubot5> Launchpad bug 1674399 in openssl (Ubuntu Artful) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,In progress] https://launchpad.net/bugs/1674399
[19:40] <infinity> slashd: I disagree with your reasoning for not fixing both 64 and 32.
[19:40] <infinity> slashd: Lots of people run 64/32 multiarch and would benefit from fixing both.
[19:41] <slashd> infinity, I'm fine with fixing 32bit, I proposed that approach cause apw wanted to self-contained the fix as much as possible
[19:41] <infinity> That doesn't really contain it much. ;)
[19:41] <slashd> infinity, so what if I do the same proposition but including 32-bit in stable release, would that work for you ?
[19:41] <infinity> slashd: The claim that Ryzen is "64-bit only" is also a bit poorly worded.  What you mean to say is "there are no 32-only variants".
[19:42] <infinity> slashd: I think that would work for me, but what I really want to see is the diff.
[19:42] <slashd> infinity, debdiff or the upstream patch ? I have both
[19:42] <infinity> slashd: diff, so I can judge the impact from a code review, and then test plan (as you've mostly laid out, but modified to include both arches).
[19:42] <rbasak> I had a brief look. Looks like a fairly straightforward rearrangement, but it needs reviewing carefully as it's in assembly.
[19:42] <infinity> slashd: debdiff.  Am I missing where that's attached?
[19:43] <rbasak> "Do it carefully" is my only comment really.
[19:43] <slashd> infinity, I have it ready, but not attached yet. I'll attach to the bug now if you want
[19:43] <rbasak> Also, for regression potential, are there any CPUs out there that will false positive?
[19:43] <infinity> slashd: Conceptually, I have no issues with the plan (other than the "please do 32-bit too" comment).
[19:44] <slashd> infinity, sure, I'm actually glad you are keen to see the 32-bit portion included
[19:44] <rbasak> And I wonder if we need to test a wide variety of CPUs out there, and if so how that might be achieved.
[19:44] <slashd> I have a debdiff with both arches ready for artful if you want to have a look
[19:44] <infinity> rbasak: x86 vendors coordinate to not overlap on flags, if someone managed to break just this one, they'll have a very bad time in general.
[19:45] <infinity> (I mean, sure, it's a possibility, but it hasn't happened in decades)
[19:45] <rbasak> OTOH, if someone who knows tells us it's probably OK, that's fine too. infinity counts as such a person :-)
[19:45] <slashd> infinity, rbasak, attaching the debdiff now
[19:46] <infinity> rbasak: Kernels, C libraries, video drivers, crypto accelerators, etc, etc, on multiple OSes all rely on those flags not being broken.  I can be fairly confident from my history in that space that a newish flag (as this is) will not throw a false positive.
[19:47] <rbasak> infinity: I thought your previous statement was fine, but thanks :)
[19:47] <slashd> infinity, rbasak --> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1674399/+attachment/4868343/+files/artful_openssl_lp1674399.debdiff
[19:47] <ubot5> Ubuntu bug 1674399 in openssl (Ubuntu Artful) "OpenSSL CPU detection for AMD Ryzen CPUs" [Medium,In progress]
[19:47] <infinity> rbasak: The only place where this messes up is when a flag is present, but broken which, ironically, only Intel ever seems to manage.  Then we need to mask out the broken CPUs.  But I know not of any such errata for sha acceleration.
[19:48] <rbasak> Well, that's what I meant by a false positive.
[19:48] <slashd> rbasak, for the testing I proposed something in comment #6
[19:48] <slashd> let me know what you think
[19:48] <rbasak> "Claims support but it doesn't" is the only definition of that, surely?
[19:48] <infinity> On, x86 ASM, how I don't love reading you.
[19:49] <infinity> rbasak: Oh, well, I read it as "the flag is on, but for unrelated reasons", which doesn't happen in practice.
[19:49] <rbasak> I'll look at it another time thanks, as I'm EOD. Feel free to review and accept without me.
[19:49] <infinity> rbasak: "Flag is on, but the CPU is crap" can happen, but it's rare and, as I said, historically only Intel manages to do this more than once a decade, and they already had this flag on pre-patch. ;)
[19:50] <rbasak> already had this flag on> good point.
[19:56] <slashd> rbasak, infinity, take your time to review all this, please keep me posted if possible by commenting the LP bug, and I stay at your disposal if you have any question I can answer.
[19:56] <slashd> infinity, rbasak, tks for jumping on this
[19:57] <infinity> slashd: Like I said, I'm conceptually fine with it (and, indeed, quite excited about the massive speed boost).  I think maybe the other thing I'd like to see is some attempt at coverage across a bunch of weirdo cores.  Whatever we can get our hands on.  If upstream has such testing, I'd accept that in lieu.
[19:57] <slashd> infinity, ack
[19:58] <infinity> A few generations of Intel cores pre/post-feature shoudn't be hard to dig up, ditto for AMD, but finding some odd non-Intel/AMD stuff to just double-check would be nice.
[19:58] <infinity> (But I'm also not super concerned about the idea that someone's flipped that bit by accident)
[19:59] <slashd> infinity, ack I'll do my best to test on various CPU that I can get access and try to contact openssl upstream to look at their upstream testing results
[20:00] <slashd> infinity, so my question is, can we go ahead with the upload and do the testing during the -proposed phase ? or you want me to test all this prior the upload ?
[20:01] <rbasak> IMHO, that's what -proposed is for, so doing it in the -proposed phase would be fine. But I'm interested to see what infinity says.
[20:02] <rbasak> Though, I would want the plan to be in the bug description before accepting into proposed, because that can help prevent an accidental release if a verification-done gets marked without it done.
[20:15] <slashd> rbasak, my proposal is documented in the LP bug, and will update it again with what has been discuss here, once infinity confirm about the testing as of if it needs to be done prior -proposed or not. And then of course again once in -proposed
[20:26] <infinity> slashd: Upload away, IMO.
[20:26] <infinity> slashd: We have enough users who recklessly run proposed that we'll get some test coverage there too. :P
[20:34] <slashd> infinity, I'll then start the upload for Artful, note that starting next week I'll be gone for 2 weeks for sprints, and won't be able to do much testing, so do you think it's preferable we only start the SRU when I get back or we upload this week and worst case it will languish in -proposed for ~2weeks which will allow ppls to test with no stress (if any volunteer)
[20:37] <Ukikie> I usually run with proposed, but with http://paste.openstack.org/show/608137
[20:38] <slashd> mdeslaur, is your offer to upload my openssl debdiff on devlopment release (Artful) still valid ? I'll upload the debdiffs in Stable release myself ^^^^ look infinity comment
[20:49] <infinity> slashd: I think letting it fester in proposed for two weeks to see if we get random negative feedback is entirely fine.  Obviously, I'll delete/revert it if it breaks anything, but I don't need you around for that.
[20:50] <infinity> slashd: 2 weeks of random user installations plus you executing a more precision test plan should give us solid confidence.
[20:54] <slashd> infinity, ack then mdeslaur will upload in Artful as I don't have righ in dev release, and I'll take care of the other uploads myself.
[20:54] <slashd> infinity, tks again
[21:14] <stgraber> going to mark juju-core as badtest FYI
[21:14] <stgraber> + echo SKIP: Juju won't bootstrap unknown without published agent
[21:14] <stgraber> so that's the usual juju issue of not knowing what the new release is
[21:15] <stgraber> (trying to get LXD to migrate)
[21:24] <infinity> stgraber: Can you maybe poke the juju folks with a sharp stick and get them to fix it too? :P
[21:56] -queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3 => 3.22.7-0ubuntu3.17.04.1] (ubuntu-desktop)
[22:02] <stgraber> infinity: I'll be with them next week, will nag them then
[22:50] -queuebot:#ubuntu-release- Unapproved: rejected apt [source] (zesty-proposed) [1.4.1~17.04.1]
[23:39] <mdeslaur> slashd: sure, just let me know when it's ready and I'll do it