[02:13] -queuebot:#ubuntu-release- New binary: golang-github-dop251-goja [amd64] (artful-proposed/universe) [0.0~git20170430.0.d382686-1] (no packageset)
[05:08] -queuebot:#ubuntu-release- Unapproved: network-manager (zesty-proposed/main) [1.4.4-1ubuntu3 => 1.4.4-1ubuntu3.1] (kubuntu, ubuntu-desktop)
[05:28] <tjaalton> infinity: is there a release schedule for 16.04.3?
[06:30] -queuebot:#ubuntu-release- New: accepted kaddressbook [source] (artful-proposed) [4:16.12.3-0ubuntu1]
[06:30] -queuebot:#ubuntu-release- New: accepted kontact [source] (artful-proposed) [4:16.12.3-0ubuntu1]
[06:30] <slangasek> infinity: second opinion on text at top of http://releases.ubuntu.com/12.04/ ? (LP: #1690565)
[06:49] <apw> slangasek, i would also make the "Extended Security Support" link to the same place as "here".
[08:16] -queuebot:#ubuntu-release- New: accepted golang-github-dop251-goja [amd64] (artful-proposed) [0.0~git20170430.0.d382686-1]
[08:45] <tjaalton> looks like noone on the sru team wants to review/ack mesa uploads :P
[08:48] <sil2100> ;)
[08:48] <sil2100> On which queue?
[08:49] <tjaalton> zesty, though there's a new stable release now that I probably should prepare instead
[08:49] <tjaalton> 17.0.5 -> .6
[08:49] <sil2100> hmmm, I didn't see it yesterday, is it old?
[08:50] <sil2100> Oh god
[08:50] <tjaalton> the oldest of the bunch, there's two pages
[08:50] <sil2100> It's on the other page
[08:50] <tjaalton> yeah :)
[08:50] <tjaalton> let me prep it after this call
[08:50] <sil2100> tjaalton: you still want that reviewed? I could take a look in a moment if anything
[08:50] <sil2100> (or if you have a newer one then we can just skip to that)
[08:51] <tjaalton> sil2100: right, I'll prep the new one, won't take long
[08:51] <sil2100> Sorry about that, I guess I missed the 'next page' button yesterday
[08:51] <tjaalton> no problem
[08:53] <tjaalton> another thing is the xenial backport stack components
[09:03] <sil2100> Yeah, can't help with that yet, but I signed up for some backporter team training
[09:10] <tjaalton> no these are normal sru's
[09:10] <tjaalton> first wave is on the xenial queue
[09:16] <apw> sil2100, i will probabally volunteer to do those kde point release reviews on the zesty queue as a batch -- everything with a version 5.9.5
[09:17] <apw> sil2100, as it was me who rejected the whole lot en-mass last week :)
[09:17] <sil2100> apw: ok, thanks! I wanted some additional feedback from the uploader as per my bug comment anyway, I suppose you might have more context
[09:18] <sil2100> apw: oh, and just a question for future things like this - we need all of those components marked on the bug, right? For the SRU infra?
[09:18] <sil2100> e.g. all those gazillion packages marked as affecting the bug
[09:18] -queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (zesty-proposed) [17.0.5-0ubuntu1~17.04.1]
[09:18] <tjaalton> sil2100: rejected old mesa, new one uploaded
[09:19] <sil2100> tjaalton: thanks, looking o/
[09:19] -queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.3-1ubuntu1 => 17.0.6-0ubuntu0.17.04.1] (core, xorg)
[09:19] <apw> sil2100, right it needs all the packages adding, i'll get that sorted and i agree we need some testing feedback
[09:20] <sil2100> Oh my, ok, then good luck! That'll be an awful task I suppose :|
[09:20] <apw> sil2100, less awful than the new reviews for kde in artful, so :/
[09:21] <sil2100> heh
[09:21] <sil2100> tjaalton: will review as soon as the debdiff is generated
[09:22] <tjaalton> sil2100: cool ,thx
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.6-0ubuntu0.17.04.1]
[10:29] -queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:40] -queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:46] -queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[10:50] -queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:52] -queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:55] -queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[10:59] -queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:02] -queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:07] -queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:09] -queuebot:#ubuntu-release- Unapproved: accepted kwallet-pam [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:13] -queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:15] -queuebot:#ubuntu-release- Unapproved: accepted kwrited [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:28] -queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:30] -queuebot:#ubuntu-release- Unapproved: accepted milou [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:31] <cpaelzer> hi, I was verifying an libvirt SRU but I need some help on x-proposed
[11:31] <cpaelzer> Y and Z verified well, but for X I need a fixup
[11:31] <cpaelzer> I already have that fixup built in a ppa and tested
[11:31] <cpaelzer> Now I need some help to replace the current in proposed with the newer fixed one
[11:32] <apw> cpaelzer, just upload it, and we can accpet it over the current proposed
[11:32] <cpaelzer> ok, if that is working that is good
[11:32] <apw> needs an incremented version of course
[11:32] <cpaelzer> wasn't sure if we'd need to reject the former one
[11:32] <cpaelzer> it already has the incremented version and is created with -v<oldver-in-updates>
[11:32] <cpaelzer> so that the update picks up all that is needed
[11:33] <apw> sounds right to me
[11:33] <cpaelzer> pushing to x-unapproved then and will ping here
[11:34] -queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[11:34] <cpaelzer> apw: libvirt 1.3.1-1ubuntu10.10 is no in x-unapproved
[11:34] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.9 => 1.3.1-1ubuntu10.10] (ubuntu-server, virt)
[11:35] <cpaelzer> here it is, thanks queuebot :-)
[11:37] <cpaelzer> could one take a look and accept it over the current libvirt in x-p so I can verify that as well - thanks in advance
[11:38] <apw> cpaelzer, that drops two patches adding lines and only adds one line ... is that what you are expecting ?
[11:39] <cpaelzer> yes it drops the two patches form 10.9 and adds into debian/apparmo/libvirt-qemu two lines (one commend and one rule about vfio)
[11:40] <apw> cpaelzer, to confirm we do not need "/proc/*/cmdline r," in the old world
[11:40] <cpaelzer> yes not in the libvirt version in xenial
[11:41] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.10]
[11:42] <cpaelzer> thank you, and to explain the noise I'm only kind of in a hurry as the kernel Team (hi apw :-) ) will soon steal my testbed (to have a working ppc64el box themselfe again) and verifying without that is possible but so much harder :-)
[11:42] <cpaelzer> hope that now verifies as it did from the ppa once it built in x-p later on
[11:42] <apw> cpaelzer, those pesky kernel-team people
[12:03] <tjaalton> sil2100: thanks for acking mesa :)
[12:11] -queuebot:#ubuntu-release- Unapproved: accepted breeze-grub [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:11] <slashd> rbasak, morning I see you talked with dragan about this LP: #1645324. From now on, I'm taking care of this bug, I see that some ppls suggest Dragan to submit in the upstream project first, but in this case it seems that ebtables "dead" last commits were made in 2015. Nowadays, all the development happen in nft.
[12:12] -queuebot:#ubuntu-release- Unapproved: accepted breeze-gtk [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:13] <slashd> Do you think it could be eligilble for SRu anyway ? considering that Dragan already submitted the same patch to Debian ebtables
[12:13] -queuebot:#ubuntu-release- Unapproved: accepted breeze-plymouth [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:16] -queuebot:#ubuntu-release- Unapproved: accepted kdecoration [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:17] -queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:18] -queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:19] -queuebot:#ubuntu-release- Unapproved: accepted ksshaskpass [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:20] -queuebot:#ubuntu-release- Unapproved: accepted kwayland-integration [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:23] -queuebot:#ubuntu-release- Unapproved: accepted libkscreen [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:26] -queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:28] -queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:29] -queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (zesty-proposed) [5.9.5-0ubuntu0.1]
[12:31] -queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:34] -queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:34] -queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:40] -queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (zesty-proposed) [4:5.9.5.1-0ubuntu0.1]
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace-wallpapers [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:45] -queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
[12:47] -queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:49] -queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:51] -queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:52] -queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:54] -queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (zesty-proposed) [4:5.9.5-0ubuntu0.1]
[12:58] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.26.1+17.04]
[13:01] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.26.1+16.10]
[13:05] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.26.1]
[13:09] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.26.1~14.04]
[13:31] <ahasenack> hi, could someone please remove these two packages from proposed: https://launchpad.net/ubuntu/+source/pam-mysql/0.7~RC1-4.1ubuntu1.1 and https://launchpad.net/ubuntu/+source/pam-mysql/0.7~RC1-4ubuntu2.1
[13:31] <ahasenack> they introduce a buffer overflow: https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1574911
[13:33] <apw> nacc, ^^ these are your SRUs
[13:36] <ahasenack> essentially my_make_scrambled_password() is not a replacement for the missing make_scrambled_password()
[13:38] <mdeslaur> rbasak: good morning! I would like to release the qemu security updates that supersede the qemu package in xenial-proposed. Looks like it's got the required verification-done tags and has waited more than a week. Could you release it?
[13:38] <apw> ahasenack, ok i've marked that up as failing so it cannot get released, and will wait on nacc's input
[13:39] <ahasenack> apw: thx
[13:40] <apw> mdeslaur, that qemu upload in xenial is a security update too by the looks of it, most confusing
[13:41] <apw> or did i miss
[13:41] <apw> mdeslaur, ignore me, i missed, stupid report
[13:42] <mdeslaur> apw: could you release it?
[13:43] <apw> mdeslaur, it looks releasable to me, so yes
[13:43] <rbasak> mdeslaur: o/
[13:43] <rbasak> I guess apw is taking care of it? Happy to look otherwise.
[13:43] <mdeslaur> looks like it
[13:43] <mdeslaur> thanks apw, rbasak
[13:43] <apw> mdeslaur, done
[13:43] <rbasak> Thanks apw!
[13:43] <mdeslaur> thanks!
[14:06] <ahasenack> artful still has an older mysql than xenial-updates, is an update stuck somewhere?
[14:06] <ahasenack> 5.7.17-0ubuntu1         | artful
[14:06] <ahasenack> 5.7.18-0ubuntu0.16.04.1 | xenial-security
[14:10] <mdeslaur> ahasenack: yeah, it's stuck in artful-proposed
[14:13] <rbasak> I've asked upstream to take a look
[14:14] <mdeslaur> ah, cool, thanks rbasak
[14:28] -queuebot:#ubuntu-release- Unapproved: accepted gnome-maps [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
[14:38] <nacc> apw: thanks
[15:14] -queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
[15:18] <slangasek> apw: done
[15:19] <apw> slangasek, esm ?  not changed if so
[15:20] <slangasek> apw: shift reload?  mirroring delay
[15:20] <apw> slangasek, better now indeed
[15:53] <nacc> jbicha: any thoughts on https://bugs.launchpad.net/bugs/1686257 possibly regressiong 16.04 users?
[15:53] <nacc> jbicha: we have one person in #ubuntu now
[15:59] <nacc> jbicha: thanks!
[16:22] <slangasek> infinity: feedback requested on https://code.launchpad.net/~vorlon/ubuntu-cdimage/public-info-out-of-private-production/+merge/324120 - if you're +1 I'll make a corresponding change to drop this file from our private production/ branch
[16:29] <jbicha> nacc: it's unlikely to be that bug, it's likely the 3.24.1 upgrade instead
[16:29] <nacc> jbicha: ah
[16:30] <nacc> jbicha: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1685500 then?
[16:30] <nacc> heh, the "Regression Potential" section does seem rather accurate
[16:30] <jbicha> nacc: yes; the other bug is more worrying since that was SRU'd to 16.04 too
[16:30] <nacc> why is that an acceptable regression potential
[16:31] <jbicha> because otherwise we could never upgrade any key packages?
[16:32] <jbicha> so far we have 1 report of that upgrade not working, which we can't duplicate yet
[16:32] <nacc> jbicha: sure, it just seems like basically saying the regression potential is infinite
[16:32] <nacc> which doesn't seem like a rational statement
[16:34] <jbicha> it's a bit unclear what exactly I'm supposed to put in the Regression Potential section, but users can have a lot more problems if a gdm update is bad than a gnome-maps update
[16:35] <jbicha> it's not clear if the affected user is going to bother filing a bug :(
[16:36] <nacc> jbicha: yeah, i don't know
[17:11] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.3.1-0ubuntu1]
[17:16] -queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.2.0-0ubuntu1]
[19:37] -queuebot:#ubuntu-release- Unapproved: designate (yakkety-proposed/main) [1:3.0.0-0ubuntu1 => 1:3.0.1-0ubuntu1] (openstack)
[19:44] <slangasek> apw: any reason for copy-proposed-kernel to take an --esm arg instead of this being implicit based on the release?
[19:51] <slangasek> apw: (this feeds into whether/how we would patch kernel-sru-review)
[19:56] <infinity>     if args.series == 'precise' and not args.esm:
[19:56] <infinity>         print("NOTE: directing copy from and to ESM for precise")
[19:56] <infinity>         args.esm = True
[19:57] <infinity> slangasek: It is implicit, I expect --esm is for people who like to be explicit and/or for testing.
[19:57] <slangasek> oho
[19:58] <infinity> slangasek: See also --no-auto
[20:37] <slangasek> apw, infinity: https://code.launchpad.net/~vorlon/ubuntu-archive-tools/sru-release-esm/+merge/324132 for the sru-release side of things
[20:57] <infinity> slangasek: Switching on precise repeatedly seems ugly.  Would be better to switch on it once to select an "ESM mode", then switch on ESM throughout.  More readable when precise becomes precise|trusty (or is replaced by trusty).
[20:57] <slangasek> fair
[20:57] <slangasek> infinity: btw did you see my rfr on https://code.launchpad.net/~vorlon/ubuntu-cdimage/match-series-for-current-triggers/+merge/324123 ?
[20:57] <infinity> slangasek: I'd also like to see the tooling treat ESM as a fourth pocket, even if that's a lie.  So:
[20:57] <infinity> --- Releasing openssl ---
[20:57] <infinity> Proposed: 1.0.2g-1ubuntu4.7
[20:58] <infinity> Security: 1.0.2g-1ubuntu4.6
[20:58] <infinity> Would also show me an "ESM:" version.
[20:58] <infinity> Updates:  1.0.2g-1ubuntu4.6
[20:58] <infinity> And tell me it's copying to Precise ESM.
[20:58] <slangasek> ah; that will require a bit of fiddling, but I'll have a look
[20:59] <infinity> slangasek: Yeah, it would be a very different patch, I grant you.  Just seems like, from a UI perspective, that might be more pleasant.  From an "only 3 people will run this command" perspective, I'm less fussed if it DTRT.
[20:59] <infinity> It's not like everything in u-a-t has a stellar UI to start with. :P
[21:00] <slangasek> yeah, not like we have two different ways to specify releases on the commandline, within a single tool repo
[21:00] <infinity> Within a single toolset, even.
[21:00] <slangasek> and at the moment we have no use case for sru-release on ESM outside of the kernels, so ideally everyone's invoking kernel-sru-release for the workflow management? :)
[21:01] <infinity> Well, you and sil2100 might be.
[21:02] <slangasek> infinity: if you prefer managing workflow bug tasks by hand, I won't stop you ;)
[21:02] <infinity> It's never really bugged me.  But, also, shankbot could be filling in assignee based on the owner of the copies, if I deeply cared.
[21:03] <infinity> (Honestly, I just didn't know that particular one existed until I just read it)
[21:03] <slangasek> by the time shankbot has confirmed seeing the copy, the assignee mostly doesn't matter
[21:04] <infinity> And kernel-sru-review is the one that desperately needs a polling loop with an upper bound to actually wait properly for the copies.
[21:04] <slangasek> yeah, so what's a sensible upper bound? :/
[21:04] <infinity>         # Arbitrary 10 second delay, maybe enough to let uefi binaries hit
[21:04] <infinity>         # the unapproved queue.
[21:05] <infinity>         time.sleep(10)
[21:05] <infinity> Not that. ;)
[21:05] <infinity> copy jobs are async, with two different potential queues.
[21:05] <infinity> There an almost-sync-but-not-quite queue, and when that one overflows, the losers end up in a queue that runs every 5m.
[21:06] <slangasek> ah ugh
[21:06] <infinity> Which is a behaviour you see a lot if doing mass copies (like releasing 20 kernels).  The first half will be near-instant, the next chunk will trickle in at a */5 mark.
[21:06] <slangasek> alright, new rev pushed to fix the precise hard-coding
[21:06] <slangasek> afk for a bit
[21:48] <infinity> slangasek: Was that ubuntustudio failure that just happened a bug in your code, or a race where the build started between you pulling the new revision and not having configs in place yet?
[21:51] <infinity> slangasek: Ahh, kylin just completed successfully, so I'll assume the race thing and just retry studio for them.
[21:58] <sil2100> While we're at kernel-sru-release - could anyone take another look at the tarball management bits?
[21:58] <sil2100> :)
[22:23] -queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.6-0ubuntu1~16.04.1 => 2.0.7-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
[22:23] -queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.6-0ubuntu1~16.10.1 => 2.0.7-0ubuntu1~16.10.1] (edubuntu, ubuntu-server)
[22:23] -queuebot:#ubuntu-release- Unapproved: lxcfs (zesty-proposed/main) [2.0.6-1 => 2.0.7-0ubuntu1~17.04.1] (edubuntu, ubuntu-server)
[23:27] <slangasek> infinity: ah yeah, I think the problem was I made the file on the production branch disappear out from underneath an already-running process
[23:37] <sbeattie> is there any additional kernel publishing going on, or are things blocked on the kernel team's end (trying to figure out why most of the derived kernels didn't get published)