[00:50] <k1l_> hi, is there a new target date for the 16.04.2 release? we keep getting questions about the release in #ubuntu since the ML did mention friday or monday.
[00:54] <tsimonq2> k1l_: Thursday.
[00:54] <tsimonq2> k1l_: Adam said something earlier. ;)
[00:55] <k1l_> alright
[01:10] <blomstertj> I had a question about this 16.04.2 HWE thing
[01:13] <blomstertj> From my understanding if you would install 16.04.2 from the ISO your kernel would be 4.8.  And if you were running 16.04.1 and upgrade to 16.04.2 (which my system is) the new kernel will NOT be upgraded.  So my question is when 16.04.3 comes out will my kernel be upgraded?
[01:14] <slangasek> blomstertj: https://wiki.ubuntu.com/Kernel/RollingLTSEnablementStack should explain the current setup.  Also, if I'm not mistaken the plan is that installing 16.04.2 still gives you the 4.4 kernel by default
[01:15] <blomstertj> slangasek: I have read that article but I'm just not comprehending that.  I'm not really familiar with how HWE stacks work because I have not run ubuntu long term
[01:17] <cyphermox> slangasek: are you currently trying to create the 16.04.2 changes summary?
[01:18] <blomstertj> So you have to manually enable the HWE stack?  The way it was worded seemed like after 16.04.2 that was changing that
[01:19] <k1l_> blomstertj: you have to enable the hwe stack once with installing that metapackage.
[01:20] <blomstertj> I was just wondering if 16.04.2 will by default use this Rolling model instead of never upgrading the kernel throughout the life of the LTS release
[01:30] <slangasek> cyphermox: I am not curretnly
[01:32] <k1l_> blomstertj: then 16.04 will still reveive kernel updates to the 4.4 kernel it was shipped with. but it will not upgrade the kernel automatically to the other kernel bases. it will stay on the GA kernel like told on the wiki page
[01:35] <cyphermox> ok, just trying to figure out who might have started but not committed changes, it refuses to copy
[01:37] <blomstertj> k1l_: The point releases will still stay on GA kernel as well then?
[01:38] <blomstertj> k1l_: I say that because of this line: Desktop installs will continue to offer the HWE Stack option only and default to it.
[01:38] <k1l_> blomstertj: when you install 16.04 and just run the updates it will become 16.04.2 by that and doesnt change something on the kernel at all
[01:38] <blomstertj> k1l_: That's what I thought.  If you install 16.04.2 from the ISO image is that still the case?
[01:38] <k1l_> blomstertj: that is when you run the 16.04.2 iso to make a complete new install. that is due to hardware support
[01:39] <blomstertj> k1l_: So if you upgrade to 16.04.2 from an earlier release you stay on GA kernel.  But if you install 16.04.2 and on from an ISO you will be on HWE?
[01:41] <k1l_> yes. the reason for that was the samsung notebooks that got brocken when run with an old kernel. from that on it always uses the hwe kernel on the iso. but not when you already are installed. since then the hardware works already.
[01:41] <blomstertj> k1l_: I get it.  Thanks for the explanation
[01:42] <k1l_> np
[02:56] <b-yeezi> infinity, I was told by tsimonq2 to ping you regarding an issue I ran into running 16.04 and HWE
[02:57] <b-yeezi> when It upgraded to kernel 4.8-36, I ran into this bug: ttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656618
[02:57] <b-yeezi> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1656618
[03:02]  * tsimonq2 nods
[03:17] <b-yeezi> I can't even boot into a previous kernel now.  error: symbol `grub_efi_secure_boot'  not found
[03:33] <cyphermox> that doesn't look like a kernel issue, that rather looks like you have the wrong modules installed for grub
[03:35] <b-yeezi> I got the same issue on a fresh install of 16.10 as well
[03:37] <cyphermox> you should file a bug and include in it the logs from the installer (/var/log/installer/*) before you reboot to the installed system.
[03:43] <b-yeezi> ok. I'll do that
[03:54] -queuebot:#ubuntu-release- New binary: pygresql [i386] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:54] -queuebot:#ubuntu-release- New binary: pygresql [ppc64el] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:55] -queuebot:#ubuntu-release- New binary: pygresql [amd64] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:56] -queuebot:#ubuntu-release- New binary: pygresql [arm64] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:56] -queuebot:#ubuntu-release- New binary: pygresql [s390x] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:56] -queuebot:#ubuntu-release- New binary: pygresql [armhf] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[03:58] -queuebot:#ubuntu-release- New binary: pygresql [powerpc] (zesty-proposed/universe) [1:5.0.3-1ubuntu1] (no packageset)
[04:11] -queuebot:#ubuntu-release- Unapproved: juju-core (trusty-proposed/universe) [1.25.6-0ubuntu1.14.04.1 => 1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1] (no packageset)
[04:19] -queuebot:#ubuntu-release- Unapproved: juju-core (trusty-proposed/universe) [1.25.6-0ubuntu1.14.04.1 => 1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1] (no packageset)
[04:26] <apw> it seems unlikely that that version number is intended for trusty?
[04:44] -queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (trusty-proposed) [1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1]
[04:44] -queuebot:#ubuntu-release- Unapproved: rejected juju-core [source] (trusty-proposed) [1:2.1~rc1-0ubuntu1~16.04.1~juju1dt1]
[04:45] <apw> ^ not intended for the archive
[06:43] -queuebot:#ubuntu-release- New: accepted mkchromecast [amd64] (zesty-proposed) [0.3.7+git20170130-1]
[06:43] -queuebot:#ubuntu-release- New: accepted radiant [amd64] (zesty-proposed) [2.7+dfsg-1]
[08:25] -queuebot:#ubuntu-release- Unapproved: libappindicator (xenial-proposed/main) [12.10.1+15.04.20141110-0ubuntu1 => 12.10.1+16.04.20170213.2-0ubuntu1] (ubuntu-desktop) (sync)
[08:28] -queuebot:#ubuntu-release- New binary: python-scrapy [amd64] (zesty-proposed/universe) [1.3.0-1~exp2] (no packageset)
[10:46] <Laney> sil2100: Hey - if you've got a minute, could you review gst-libav/xenial UNAPPROVED please?
[10:46] <Laney> It's a regression in -updates and I feel bad leaving it there
[10:47] <sil2100> Laney: hey! Let me try taking a quick look in a minute
[10:47] <Laney> thanks!
[10:47] -queuebot:#ubuntu-release- Unapproved: libodb (yakkety-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.10.1] (no packageset)
[10:48] <xnox> apw, if you can think of better version numbers in this case, I am happy to reupload something better. Above is constrained by 2.4.0-1 in both xenial & yakkety release; with 2.4.0-1build1 in zesty.
[10:48] -queuebot:#ubuntu-release- Unapproved: libodb (xenial-proposed/universe) [2.4.0-1 => 2.4.0-1build0~16.04.1] (no packageset)
[10:49] <xnox> and this one too
[10:50] -queuebot:#ubuntu-release- Unapproved: unity-control-center (xenial-proposed/main) [15.04.0+16.04.20160705-0ubuntu1 => 15.04.0+16.04.20170214-0ubuntu1] (ubuntu-desktop) (sync)
[10:50] -queuebot:#ubuntu-release- Unapproved: unity-control-center (yakkety-proposed/main) [15.04.0+16.10.20161003.1-0ubuntu2 => 15.04.0+16.10.20170214-0ubuntu1] (ubuntu-desktop) (sync)
[10:52] <jbicha> in case there's an archive admin who's not subscribed to the ubuntu-release list, I'll repeat that I'd appreciate it if mozjs38 were reviewed and accepted into zesty soon since it blocks gnome-shell 3.24
[10:55] <xnox> jbicha, just use webkit </iTroll> =)
[10:57] <jbicha> xnox: do I hear a volunteer? :)
[10:57] <xnox> jbicha, hahaha
[10:59] <apw> jbicha, are we going to see that in debian too ??
[10:59] <jbicha> yes, it's required for Debian to package GNOME 3.24
[11:00] <apw> jbicha, and we are using a common orig with them
[11:00] <jbicha> GNOME does plan to move to mozjs45 and then mozjs52 (when it's released), maybe GNOME 3.26 or so
[11:01] <jbicha> I have been in contact with the mozjs24 maintainer (a few weeks ago), but if he doesn't want to maintain it then it'll probably end up being the Debian GNOME team
[11:02] <jbicha> but yes I will forward my packaging to Debian
[11:10] <sil2100> Laney: ok, checked and approved o/
[11:10] -queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [source] (xenial-proposed) [1.8.3-1ubuntu0.2]
[11:10] <Laney> thanks!
[11:18] -queuebot:#ubuntu-release- New: accepted mozjs38 [source] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:18] <apw> jbicha, having reviewed it three times now, i think i am as happy as i can be ^^
[11:19] <jbicha> 3 times?
[11:20] <apw> jbicha, i reviewed it before not just today
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [amd64] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [armhf] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [powerpc] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [s390x] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [arm64] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [ppc64el] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] -queuebot:#ubuntu-release- New: accepted pygresql [i386] (zesty-proposed) [1:5.0.3-1ubuntu1]
[11:20] <apw> wasn't sure, thought about it some more, asked you questions ... now happy
[11:21] -queuebot:#ubuntu-release- New: accepted python-scrapy [amd64] (zesty-proposed) [1.3.0-1~exp2]
[11:21] <jbicha> mozjs is an annoying package (it's intentionally not in Ubuntu main) but if we're going to use it, it's better to use a more recent version
[11:22] <apw> jbicha, as it is a separate package space for each version, and us used an origin with a very specific version, most wrongness can be fixed if debian goes a different route
[11:23] -queuebot:#ubuntu-release- New binary: mozjs38 [i386] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:24] -queuebot:#ubuntu-release- New binary: mozjs38 [ppc64el] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:26] <LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/12005643
[11:26] <LocutusOfBorg> failing now
[11:26] -queuebot:#ubuntu-release- New: accepted autobahn-cpp [amd64] (zesty-proposed) [0.2.1-1ubuntu1]
[11:26] -queuebot:#ubuntu-release- New binary: mozjs38 [s390x] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:26] -queuebot:#ubuntu-release- New binary: mozjs38 [powerpc] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:27] <LocutusOfBorg> some update broke it
[11:27] <LocutusOfBorg> meld of the build logs shows just a few packages
[11:27] -queuebot:#ubuntu-release- New binary: mozjs38 [amd64] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: mozjs38 [arm64] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: mozjs38 [armhf] (zesty-proposed/none) [38.2.1~rc0-0ubuntu1] (no packageset)
[11:29] <jbicha> LocutusOfBorg: yes I think Laney is working on it now, thanks
[11:30] <jbicha> I don't think it's a change in build-dependencies, perhaps just depends on how overworked the LP builder is
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [amd64] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [i386] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [ppc64el] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [arm64] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [s390x] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [powerpc] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:32] -queuebot:#ubuntu-release- New: accepted mozjs38 [armhf] (zesty-proposed) [38.2.1~rc0-0ubuntu1]
[11:35] <LocutusOfBorg> jbicha, don't know I retried it a few times, and it is failing also in ppa
[11:35] <LocutusOfBorg> I remember having the same issues when I transitioned libpng1.6
[12:10] <ginggs> would someone please remove the armhf and powerpc binaries for theano?  it no longer builds on these architectures
[12:32] -queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (zesty-proposed/universe) [17.04] (no packageset)
[12:43] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu3~16.10.0 => 20160930-0ubuntu4~16.10.0] (ubuntu-cloud)
[12:44] <Odd_Bloke> An ACK of ^ in to -proposed so I can test it would be much appreciated.
[13:08] <acheronuk> hi. I suppose packages in Xenial archive, even if utterly useless as they only work with plasma4 found in trusty and before, are destined to just stay there?
[14:14] <LocutusOfBorg> acheronuk, probably yes
[14:14] <LocutusOfBorg> but remove them from zesty :p
[14:23] -queuebot:#ubuntu-release- New binary: python-scrapy-djangoitem [amd64] (zesty-proposed/universe) [1.1.1-1] (no packageset)
[14:27] <acheronuk> LocutusOfBorg: yep, it was removed in Yakkety actually. just had someone moaning slightly on a forum that it was in zesty archive, but of no use.
[14:27]  * acheronuk shrugs
[14:28] <acheronuk> *Xenial archive I meant
[15:25] <camako> Can I get a core dev to publish bileto #2435?
[15:25] <camako> Please?
[15:39] <xnox> camako, you should be pinging trainguards on #ubuntu-ci-eng
[15:41] <camako> xnox, I am confused ... I 've previously been told by the trainsguards that I need to ask a core dev. :-)
[15:41] <xnox> camako, this is not a place for core devs =)
[15:42] <xnox> camako, this is more about ~ubuntu-sru | ~ubuntu-archive teams =)
[15:42] <camako> xnox, ack, sorry about the noise :-)
[15:42] <xnox> camako, most coredevs are in #ubuntu-devel and bileto friendly coredevs are in #ubuntu-ci-eng
[15:42] <camako> gotcha
[15:42] <camako> I did get sil on the ci-eng to help me
[15:42] <xnox> camako, when things get stuck in proposed migration; or have NEW packages review; this channel is a good place to ask =)
[15:43] <sil2100> Yeah, for Bileto it's best to try on #ubuntu-ci-eng, many of the trainguards are core-devs anyway
[15:43] <camako> I see.. Thanks for patiently explaining :-)
[15:43] <sil2100> But #ubuntu-devel can be a good place as well ;)
[15:43] <sil2100> Still, some core-devs can not know how to use Bileto ;p
[15:44] <camako> O I see. I'll stick with ci-eng from now on
[16:06] <ginggs> would someone please 'force-badtest python-cobra/0.5.9-1/armhf' ? tests depend on python-pandas which is no longer installable on armhf
[16:31] <apw> ginggs, will those tests be removed in the next upload, or is there a plan to fix python-pandas ?
[16:34] <ginggs> apw: will which tests be removed?  i don't of anyone actually working on fixing pandas for architectures where it was removed
[16:35] <nacc> but pandas is current built for 'all', shoudl it be rebuilt to not exist on some architectures?
[16:36] <apw> welll i was asking if we were going to fix python-cobra to not run the test, or the python-pandas so it is installable
[16:36] <nacc> right, it seems like this is a 'permanent' issue -- so we should fix it in the src(s)?
[16:37] <ginggs> nacc: how do you propose to fix it in src?
[16:38] <nacc> ginggs: i have no idea, but it seems like you skip the test in python-cobra on a particular arch or you drop the dependency on pandas on a specific arcch, or some other choice
[16:38] <ginggs> isn't it britney that should be told not to run the test (or, at least ignore the failure)
[16:39] <apw>  we dont want to skip test over and over, a one off because they broke is fine, but if the test in a package is invalid we should stop running it
[16:39] <apw> bexause we can only ignore the whole suite on an arch, not individual tests
[16:39] <nacc> ginggs: my thinking was what apw said, you don't want to have to ask someone to manually skip on every upload or every dependency-run
[16:39] <apw> it is a blunt tool
[16:41] <ginggs> hmmm
[16:42] <nacc> it also seems bad if pandas is in the release pocket for armhf but uninstallable there?
[16:42] <nacc> did a dependency change?
[16:43] <ginggs> apw: look in p.itti's hints - please replace 'force-badtest python-cobra/all/s390x' with 'force-badtest python-cobra/all/armhf' - s390x is fixed now, armhf broken
[16:43] <ginggs> nacc: no, new upstream pandas broke on a few (most) architectures
[16:44] <nacc> ginggs: oh i see
[16:44] <nacc> ginggs: but it's already in the release (so it had to work at some point?)
[16:45]  * nacc will shut up, just confused :)
[16:45] <Laney> arch:all packages don't have to be installable everywhere (just amd64)
[16:45] <nacc> Laney: ah, that's it then :)
[16:45] <Laney> presumably the arch-specific ones got removed at some point
[16:47] <ginggs> Laney: yes, python-pandas-lib and python3-pandas-lib and their reverse-dependencies were removed (LP: #1643151)
[16:48] <apw> ginggs: this isn't about not knoeing how to disable those tests, it is about it being stupid to run them if they are broken alwaya
[16:50] <Laney> Not sure how proposed-migration can nkow that
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (yakkety-proposed) [140.0.0-0ubuntu1~16.10]
[16:55] -queuebot:#ubuntu-release- Unapproved: lxcfs (trusty-backports/universe) [2.0.5-0ubuntu1~ubuntu14.04.1 => 2.0.6-0ubuntu1~14.04.1] (no packageset)
[16:56] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [140.0.0-0ubuntu1~16.04.1]
[16:57] <apw> Laney: indeed it cannot, other than by a different hint, but that is why broken tests should be removed
[16:57] <Laney> apw: You're saying it should get an 'if not armhf' thing in the tests?
[16:58] <apw> or the individual test if that is possible,
[16:58] <apw> the only time it feels right to himt forever
[16:58] <nacc> could we get an AA to look at LP: #1662654 ?
[16:59] <apw> is if this is an unmodified debian package where thos would be the only delta
[16:59] <apw> Laney: though you were keen we didnt hint overly, whst is your criteria
[17:00] <ginggs> is it possible to 'if not armhf' in autopkgtests?
[17:01] <nacc> LP: #1516959 seems to imply it is
[17:02] <ginggs> apw: let's pretend pandas had never been installable on armhf, the python-cobra test would still always be run, the only difference is the result would be 'always failed' instead of 'ignored failure'
[17:03] <ginggs> nacc: thanks
[17:03] <nacc> ginggs: it's not clear to me if that is for specifying the test dependencies on a given arch, though (maybe that would be sufficcient?)
[17:03] <nacc> ginggs: as opposed to saying a particular test is arch-dependent
[17:03] <apw> true but it could go green, and then be useful, once it is ignored it is dead
[17:04] <Laney> I think it's strange to encode a build failure in the tests like that, if someone's performed archive operations to make the package migratable
[17:04] <Laney> What you want here I think is to be able to make something go back to always failed
[17:04] <Laney> But we don't have that ATM
[17:04] <apw> Laney: do we have that?
[17:04] <apw> as i agree fhat is really what we want
[17:04] <Laney> Well
[17:04] <Laney> You could go in and hack the swift stuff to delete the result(s) which passed
[17:04] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (trusty-backports) [2.0.6-0ubuntu1~14.04.1]
[17:05] <Laney> That wouldn't be that hard
[17:05] <Laney> But there's no operation to do it
[17:07] <Laney> (Also then it might be necessary to delete pending.json on snakefruit to make britney re-download the results, don't remember offhand)
[17:08] <apw> ...
[17:09] <Laney> :D
[17:09] <apw> i think then i can add that, but with some kind of header to trigger it to be deleted if we have a green ever
[17:09] <apw> (lost irc briefly)
[17:11] <apw> add that hint
[17:12] <Laney> Worth a bug about making this better
[17:12] <Laney> Maybe it would be a new reset the ratchet type of hint
[17:15] -queuebot:#ubuntu-release- Unapproved: lxc (trusty-backports/main) [2.0.6-0ubuntu1~ubuntu14.04.1 => 2.0.7-0ubuntu1~14.04.1] (ubuntu-server)
[17:23] <apw> yeah
[17:24] <apw> ginggs, ok done
[17:52] <ginggs> thanks apw !
[17:52] <ginggs> apw: except you made a type in your hints file
[17:52] <ginggs> a typo, even
[17:53] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu3~16.04.0 => 20160930-0ubuntu3~16.04.1] (ubuntu-cloud)
[17:53] <Odd_Bloke> There are gce-compute-image-packages packages waiting in the yakkety and xenial queues; ACKs would be much appreciated.
[17:54] <Odd_Bloke> (slangasek: ^)
[18:01] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.26 => 2.27] (no packageset)
[18:05] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.26+16.10 => 2.27+16.10] (no packageset)
[18:06] <sergiusens> RAOF: are you around to accept these? ^^
[18:07] <sergiusens> hmm, maybe slangasek, can you? Don't thing R A O F is on yet
[18:29] <slangasek> sergiusens, Odd_Bloke: looking
[18:32] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.27+16.10]
[18:33] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.27]
[18:34] -queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [140.0.0-0ubuntu1~14.04]
[18:37] <slangasek> Odd_Bloke: the debdiff also contains a change to the perms on /dev/console, which seems unlikely to be related to the performance issue described in the bug report; mind spelling this out in the bug description?
[18:40] <slangasek> can someone explain to me why there are autopkgtests being reported for "linux/blacklisted"?
[18:50] <sergiusens> thanks!
[18:52] <nacc> slangasek: would you be able to give an advice on LP: #1662654? the tomcat 8.5 in proposed is breaking dogtag-pki which is then gating many other packages in z-p.
[19:22] <slangasek> nacc: why is it in -proposed again?  I'm sure someone removed it already
[19:22] <slangasek> or maybe I looked at the wrong package name hmm
[19:23] <slangasek> nacc: ok, sorry, I thought this was done already
[19:24] <slangasek> nacc: I think I'll probably remove it regardless, under the circumstances; but for rationale it's good to understand if the problems are intrinsic to this tomcat8 package, or if it's an incompatibility with other packages which haven't yet been updated for compat with 8.5
[19:37] <nacc> slangasek: ack, I can update the bug
[19:37] <nacc> slangasek: it's a compatibility issue aiui, with 8.5 specifically
[19:37] <nacc> err, that's poorly phrased
[19:38] <nacc> it's a compatibility issue for other packages with tomcat 8.5
[19:38] <nacc> which we will pursue in 17.10, but for 17.04 we want to stay on 8.0
[19:45] <slangasek> nacc: package removed
[19:45] <slangasek> bug update timing out in lp ;P
[19:46] <nacc> slangasek: thank you -- will i need to manually rerun various tests in excuses? or will they trigger on that change?
[19:46] <slangasek> nacc: they'll need manually retriggered
[19:46] <nacc> slangasek: ack, thanks!
[19:46] <nacc> tjaalton: jgrimm: --^
[19:46] <jgrimm> \o/
[19:47] <jgrimm> nacc, could you retrigger dogtag-pki (under nspr) for me when its appropriate. I don't have rights. :)
[19:47] <nacc> jgrimm: ack, it's on my list
[19:47] <jgrimm> thanks sir
[19:55] <nacc> slangasek: i assume there is some time delay while the package is actually deleted? (e.g., rmadison reports it still present)
[19:56] <tjaalton> nacc: excellent
[19:56] <slangasek> nacc: yes. rmadison reads from a database, which is rebuilt from the archive, which publishes roughly once every half hour
[19:56] <nacc> slangasek: ack, thanks!
[19:56] <nacc> tjaalton: i'll start retrying tests -- and i'll redo those dogtag-pki builds, if that's ok with you?
[20:00] <tjaalton> nacc: sure, go ahead
[20:00] <tjaalton> did resteasy get synced already?
[20:00] <nacc> tjaalton: thanks
[20:00] <nacc> tjaalton: i think i saw it in excuses
[20:00] <nacc> tjaalton: yeah, 3.1.0-2 is in z-p, blocked by dogtag-pki
[20:01] <tjaalton> ah, right
[20:01] <tjaalton> that too :)
[20:01] <nacc> tjaalton: iiuc, the new dogtag-pki should fix this all up, along with retriggers as necessary
[20:01] <tjaalton> actually build tomcatjss first
[20:02] <tjaalton> oh sorry
[20:02] <nacc> tjaalton: it needs a rebuild?
[20:02] <tjaalton> it's not on excuses
[20:02] <tjaalton> nah
[20:03] <nacc> tjaalton: ack
[20:06] <nacc> tjaalton: hrm, dogtag-pki still failed to build (resteasy issue still?): https://launchpadlibrarian.net/306421401/buildlog_ubuntu-zesty-amd64.dogtag-pki_10.3.5-7_BUILDING.txt.gz
[20:07] <nacc> tjaalton: bah still picked up 8.5, i'll be more patient :)
[20:07] <tjaalton> hehe
[20:08] <nacc> tjaalton: sorry for the noise :)
[20:08] <tjaalton> np
[20:44] <nacc> tjaalton: does dogtag-pki need an update to use libresteasy-legacy.jar explicitly?
[21:02] <tjaalton> nacc: oh right, i'll deal with it tomorrow
[21:03] <nacc> tjaalton: i'm happy to try and do it -- if you can give a hint, I think I see how it's done. is it an update to the CMake stuff?
[21:12] <nacc> tjaalton: actually, hrm, it seems like the build of libresteasy-java does not contain a resteasy-legacy.jar at all
[21:13] <tjaalton> huh
[21:13] <tjaalton> -rw-r--r-- root/root    256434 2017-02-14 10:41 ./usr/share/java/resteasy-legacy.jar
[21:13] <tjaalton> that's what my localbuild has
[21:17] <tjaalton> and the deb should have that too
[21:17] <tjaalton> according to https://launchpadlibrarian.net/306405437/buildlog_ubuntu-zesty-amd64.resteasy_3.1.0-2_BUILDING.txt.gz
[21:19] <nacc> tjaalton: hrm, strange, you're right
[21:19] <nacc> tjaalton: i'll assume PEBKAC
[21:20] <tjaalton> it needs changes in several places, not just for the build but runtime too
[21:20] <nacc> tjaalton: ah i see that now
[21:28] <tjaalton> <- EOD
[21:57] -queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.13-0ubuntu0.16.04.1 => 7.0.15-0ubuntu0.16.04.2] (kubuntu, ubuntu-desktop, ubuntu-server)
[21:59] -queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.13-0ubuntu0.16.10.1 => 7.0.15-0ubuntu0.16.10.2] (kubuntu, ubuntu-desktop, ubuntu-server)
[22:34] -queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.1]
[22:35] -queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.1]
[22:44] -queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.2]
[22:45] -queuebot:#ubuntu-release- Unapproved: rejected php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.2]
[22:45] <jderose> infinity: so still no 16.04.1 RC ISOs? :)
[22:58] -queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.13-0ubuntu0.16.04.1 => 7.0.15-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:04] -queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.13-0ubuntu0.16.10.1 => 7.0.15-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
[23:13] <nacc> tjaalton: fyi, will also need to backport https://git.fedorahosted.org/cgit/pki.git/commit/?h=DOGTAG_10_3_BRANCH&id=423c986c57a0baacf1dc8d817dc8b356b9cf0d06 for the build to succeed. Not sure if it's worth uupdating instead to the latest
[23:24] <infinity> jderose: Tonight.
[23:24] <jderose> infinity: cool, thanks. good luck :D
[23:32] -queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (xenial-proposed) [7.0.15-0ubuntu0.16.04.1]
[23:34] <teward> aaaa i need someone to nuke an upload before it's accepted, I really hate myself for this
[23:34] <teward> i uploaded an incomplete merge, i think
[23:34] <teward> for nginx, can someone intercept and 'forget' it?
[23:35] <teward> I think i uploaded, if not then sorry, I panicked for nothing :/
[23:35] <teward> *yawns*
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (yakkety-proposed) [7.0.15-0ubuntu0.16.10.1]
[23:36] <rbasak> nacc, mdeslaur: ^
[23:36] <nacc> rbasak: thanks! i'll update the secondary bug with the SRU template
[23:37] <rbasak> teward: to Zesty, I don't believe there's any point you can intercept. You can cancel builds but you'll still burn the version number.
[23:37] <rbasak> nacc: good point, thanks.
[23:37] <teward> blurgh
[23:37] <teward> well I don't see an upload accepted thing so maybe I just imagined it?
[23:37] <rbasak> nacc: I wasn't too concerned so didn't notice - because the fix is trivial and comes with an automated test case.
[23:38] <rbasak> (and the microrelease carries far more regression risk than the bugfix)
[23:38] <mapreri> (teward: this is not debian where there can be so much of 15 minutes between upload and accept)
[23:38] <teward> well i made this fubar before and it was able to be caught and purged before it left proposed
[23:39] <mapreri> That's not "before it's accepted"
[23:39] <teward> well i just need it purged
[23:39] <teward> but eh
[23:39] <teward> i think i'm panicking over nothing 'cause I see no upload file heh
[23:40] <mapreri> locking it in proposed, and/or removing from proposed it's feasible, but 1) the version number is gone 2) it's not nuked from existence
[23:40] <mapreri> indeed :)
[23:40] <mapreri> probably time for sleep instead :P
[23:40] <teward> who has time for sleep lol
[23:40] <nacc> rbasak: ack
[23:41] <teward> okay, so I think this one won't blow up in my face heh
[23:43] <teward> just... one question, do I upload the merge, then give the Release team a notice about how some newer packages need to be main and others as universe?
[23:43] <teward> since we have some new packages thanks to the merge... :P
[23:43] <teward> (dynamic modules)
[23:43] <rbasak> teward: we'll get a component mismatch report.
[23:44] <teward> and then we can fix accordingly.  That makes sense.
[23:44] <rbasak> teward: you can file a bug (against nginx) and subscribe ~ubuntu-archive if you have further information I guess, or email ubuntu-release@. But normally they figure it out just from the report.
[23:44] <teward> indeed.  It's not like it's additional external dependencies, that I"m aware of, but if there are I'll have to follow-up
[23:44] <teward> IIRC that's not the case though
[23:45] <teward> just stuff that's new from the debian packaging and rules, but still all from the packaging itself and nothing external to it :P
[23:45] <teward> that's assuming these builds don't blow up in my face in the test repo
[23:45] <teward> oh COME ON
[23:47] <teward> ... stupid fatfingering...
[23:55] -queuebot:#ubuntu-release- Unapproved: nano (xenial-proposed/main) [2.5.3-2ubuntu1 => 2.5.3-2ubuntu2] (core)