[08:49] <LocutusOfBorg> https://launchpad.net/ubuntu/zesty/+queue apw not sure if you or somebody else, but gce-compute-images have been only accepted for amd64
[08:51] <apw> LocutusOfBorg, was not me who accepted the zesty pile, but i can look at fixing that
[08:51] <LocutusOfBorg> thanks
[08:54] <apw> LocutusOfBorg, likely happened because this package was arch all before this update
[08:54] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
[08:54] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
[08:54] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [s390x] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
[08:54] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
[08:54] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
[09:06] <LocutusOfBorg> thanks! I was wondering why of such situations, this makes sense
[09:08] <LocutusOfBorg> doko, ping wrt ghc, should I upload the arm64 bfd switch? do you think this can be sane?
[09:42] <LocutusOfBorg> hello, wrt python-3to2, please remove it from the archive, I don't want it to slow the python transition, I requested removal in Debian some seconds ago
[09:42] <LocutusOfBorg> https://bugs.debian.org/867264
[09:42] <ubot5> Debian bug 867264 in ftp.debian.org "RM: python-3to2 -- ROM; FTBFS" [Normal,Open]
[11:13] -queuebot:#ubuntu-release- New binary: lrslib [ppc64el] (artful-proposed/universe) [0.62-2] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: lrslib [s390x] (artful-proposed/universe) [0.62-2] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: lrslib [amd64] (artful-proposed/universe) [0.62-2] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: lrslib [i386] (artful-proposed/universe) [0.62-2] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: lrslib [armhf] (artful-proposed/universe) [0.62-2] (no packageset)
[11:24] -queuebot:#ubuntu-release- New binary: lrslib [arm64] (artful-proposed/universe) [0.62-2] (no packageset)
[12:15] <didrocks> any ideas why qtquickcontrols-opensource-src wants to migrate back to main? All dependencies "rescued from" are in universe as listed on http://people.canonical.com/~ubuntu-archive/component-mismatches.html, and nothing is pulling directly to any seed: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all only universe components…
[12:15] <didrocks> I'm probably missing something obvious
[12:39] -queuebot:#ubuntu-release- Unapproved: ksh (trusty-proposed/universe) [93u+20120801-1 => 93u+20120801-1ubuntu0.14.04.1] (no packageset)
[12:39] -queuebot:#ubuntu-release- Unapproved: ksh (yakkety-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu0.16.10.1] (no packageset)
[12:39] -queuebot:#ubuntu-release- Unapproved: ksh (xenial-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu0.16.04.1] (no packageset)
[12:40] -queuebot:#ubuntu-release- Unapproved: ksh (zesty-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu1] (no packageset)
[12:41] <didrocks> it's pulled in main due to qtdeclarative5-examples, which I demoted, but from both links, we can see that this package is rescued by its source package?
[12:42] <didrocks> I don't really understand why and how, we do have quite some source packages in main with only some of its binary package in universe
[12:42] <didrocks> cjwatson: xnox: any idea on what I'm missing? ^
[12:46] <xnox> didrocks, probably Build-Using is pulling it in.
[12:46] <xnox> didrocks, i have a patch to germinate to show that in components-missmatches but it is pending review and merge from infinity / cjwatson
[12:46] <xnox> didrocks, that's one known thing. Let me check again if there is anything else there.
[12:48] <didrocks> xnox: shouldn't that be shown in apt-cache show *-exmamples?
[12:52] <xnox> is it not simply seeded?!
[12:54] <xnox> horum.
[12:54] <xnox> didrocks, your assesment appears to be right. i'm not sure why report is showing what it does. unless the report is stale or something.
[12:55] <didrocks> xnox: it's refreshed, beforehand it was showing up qtdeclarative5-examples (MAIN) before I demoted it
[12:55] <didrocks> and it added its own line
[12:55] <didrocks> so, yeah, quite puzzled
[12:55] <didrocks> (and no, not seeded as you can see in the /all page, it's rescued by the source package)
[13:06] <xnox> i give up, i do not know.
[13:07]  * didrocks doesn't feel alone anymore ;)
[13:07] <didrocks> let's see once cjwatson is around if he has a better idea
[13:08] <didrocks> thanks for looking at it xnox!
[13:11] <infinity> didrocks: It's because of qtdeclarative5-examples
[13:11] <infinity> didrocks: Demoting it didn't magically make it not want to be in main. :P
[13:12] <didrocks> infinity: but why does it want to be in main? It's rescued by its source package
[13:12] <infinity> didrocks: Yes.  Because the source is in main, and:
[13:12] <infinity> supported: * Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj gir1.2-* *-examples
[13:13] <didrocks> oh, didn't know about this regexp
[13:13] <didrocks> shouldn't it be written then as seeded in same way in the supported? (by its source package, ok)
[13:14] <infinity> didrocks: Note directly under that line are a bunch of exceptions for things we don't want to pull in for $reasons.
[13:14] <infinity> didrocks: So if you feel those examples packages aren't worth having in main because they pull in too many deps or whatever, you can add an Extra-Exclude in that block.
[13:15] <infinity> And I should porbably go clean that up and audit it some day.
[13:15] <didrocks> infinity: yeah, sounds like the best approach! I'll add it to that list to go on on our demotion
[13:15] <didrocks> infinity: yeah, the list is getting long :)
[13:15] <infinity> didrocks: If you do extra-exclude qtdeclarative5-examples, please add a comment or commit message (or both) that explain why (it was pulling in qtquickcontrols-opensource-src, which we don't want).
[13:16] <didrocks> thanks for the explanation! I never noticed this Extra-Include and thought -dbg/-dev/-doc rules were hardcoded somewhere
[13:16] <didrocks> infinity: as always ;)
=== mcasadevall is now known as NCommander
[13:26] <slashd> rbasak, good day, I want to push a patch in Artful for open-iscsi, but it seems like a previous upload is blocked "Not considered" for 56 days ... reason : a couples of unsatisfiable Depends. What can be done to unblock me ?
[13:26] <slashd> mdeslaur^
[13:27] <infinity> slashd: Follow LP: #1689963 closely, I imagine.
[13:27] <ubot5> Launchpad bug 1689963 in open-isns (Ubuntu) "[MIR] open-isns" [Undecided,New] https://launchpad.net/bugs/1689963
[13:30] <infinity> slashd: Ahh, and it looks like it's pretty much a done deal.
[13:31] <slashd> infinity, reading
[13:33] <infinity> slashd: cyphermox is on VAC unfil next week, but I'm sure he'll get to it when he's back.  Or if it's urgent, you could ask doko to put a bow on it.
[13:34] <slashd> infinity, it's not critical but I doubt we can wait until next week, I'll ping doko and see what can be done, thanks infinity much appreciated
[13:35] <infinity> slashd: Why can't it wait *to migrate* until next week?
[13:36] <infinity> slashd: If this is an "I want to upload to artful first so I can SRU the same fix" thing, the fix having migrated isn't a prereq for the SRU upload.
[13:36] <rbasak> I was about to say. It makes no sense to block an SRU because of an unrelated proposed migration issue. Unless I'm missing something, it'd be OK to put the fix into artful-proposed and proceed with an unrelated-to-the-migration-failure SRU I think.
[13:36] <infinity> (Though, taking responsibility to make sure it *does* migrate is)
[13:37] <slashd> rbasak, infinity, yes I want to push the change in devel release to start the SRU
[13:37] <infinity> slashd: Right.  So do that.
[13:37] <infinity> Upload early, upload often.
[13:37] <infinity> That's the devel series mantra.
[13:37] <slashd> infinity, ack thanks
[13:41] <Trevinho> arges, rbasak: could you please promote unity-control-center in xenial-proposed to updates? SRU is verified and i'd like to land a new one soon
[13:41] <slashd> rbasak, thanks as well
[13:43] <rbasak> Trevinho: looking
[13:47] <Trevinho> thanks
[13:50] <rbasak> Trevinho: seen comment 25?
[13:50] <ahasenack> hi, could someone please accept my nomiations in this bug? https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1560429
[13:50] <ubot5> Ubuntu bug 1560429 in squid3 (Ubuntu) " squid3: segfault when ftp passive mode is not available" [Medium,In progress]
[13:51] <rbasak> ahasenack: done
[13:51] <ahasenack> thx
[13:51] <seb128> rbasak, Trevinho, do we really need to block xenial fixes on yakkety, zesty is current stable and should be what matters
[13:52] <ahasenack> rbasak: when this bug was filed, the devel distro was affected, but that's not the case anymore. What should I do with the "(ubuntu)" task, which nowadays represents artful? zesty and artful have the fix already
[13:52] <rbasak> seb128: I was wondering that. I was just asking about the comment - not aware of any particular SRU policy on this.
[13:52] <ahasenack> delete it, or find out when it was fixed and mark it fix released with a comment?
[13:54] <rbasak> Best not to delete tasks to avoid hitting an Launchpad bug. Mark Invalid if necessary instead. If the bug was since fixed in the development release, then change that to Fix Released. Add a task for Zesty if necessary, though if that's immediately going to be Fix Released then there's little point unless there some other reason (clarity in communication, etc).
[13:55] <ahasenack> ok
[13:59] <apw> rbasak, you can get those tasks back iirc, using launchpadlib ...
[14:01] -queuebot:#ubuntu-release- Unapproved: xf86-input-mtrack-hwe-16.04 (xenial-proposed/universe) [0.3.1-1build1~16.04.1 => 0.3.1-1build2~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-evdev-hwe-16.04 (xenial-proposed/main) [1:2.10.2-1ubuntu1~16.04.1 => 1:2.10.5-1ubuntu1~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput-hwe-16.04 (xenial-proposed/universe) [0.19.0-1ubuntu0.1~16.04.1 => 0.25.0-0ubuntu1~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-void-hwe-16.04 (xenial-proposed/universe) [1:1.4.1-1build2~16.04.1 => 1:1.4.1-1build3~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xf86-input-wacom-hwe-16.04 (xenial-proposed/main) [1:0.33.0-0ubuntu1~16.04.1 => 1:0.34.0-0ubuntu2~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-synaptics-hwe-16.04 (xenial-proposed/main) [1.8.3-1ubuntu1~16.04.1 => 1.9.0-1ubuntu1~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-joystick-hwe-16.04 (xenial-proposed/universe) [1:1.6.2-1build4~16.04.1 => 1:1.6.3-1build1~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-16.04 (xenial-proposed/main) [1.1.2-1~16.04.1 => 1.3.0-0ubuntu1~16.04.1] (no packageset)
[14:01] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-16.04 (xenial-proposed/main) [1:7.7.1-1~16.04.1 => 1:7.9.0-0ubuntu1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-dummy-hwe-16.04 (xenial-proposed/main) [1:0.3.7-1build5~16.04.1 => 1:0.3.8-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode-hwe-16.04 (xenial-proposed/universe) [2.11.18-2~16.04.1 => 2.11.19-2~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-mach64-hwe-16.04 (xenial-proposed/universe) [6.9.5-1build2~16.04.1 => 6.9.5-1build3~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-16.04 (xenial-proposed/main) [1:1.0.12-2~16.04.1 => 1:1.0.14-0ubuntu1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl-hwe-16.04 (xenial-proposed/main) [0.1.4-3ubuntu3~16.04.1 => 0.1.5-2build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-savage-hwe-16.04 (xenial-proposed/universe) [1:2.3.8-1ubuntu3~16.04.1 => 1:2.3.9-1ubuntu1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-sisusb-hwe-16.04 (xenial-proposed/universe) [1:0.9.6-2build5~16.04.1 => 1:0.9.7-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-trident-hwe-16.04 (xenial-proposed/universe) [1:1.3.7-1build2~16.04.1 => 1:1.3.8-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vmware-hwe-16.04 (xenial-proposed/main) [1:13.1.0-2ubuntu3~16.04.1 => 1:13.2.1-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-fbdev-hwe-16.04 (xenial-proposed/main) [1:0.4.4-1build5~16.04.1 => 1:0.4.4-1build6~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-neomagic-hwe-16.04 (xenial-proposed/universe) [1:1.2.9-1build2~16.04.1 => 1:1.2.9-1build3~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-r128-hwe-16.04 (xenial-proposed/universe) [6.10.1-1~16.04.1 => 6.10.2-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-tdfx-hwe-16.04 (xenial-proposed/universe) [1:1.4.6-1build2~16.04.1 => 1:1.4.7-1build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel-hwe-16.04 (xenial-proposed/main) [2:2.99.917+git20160706-1ubuntu1~16.04.1 => 2:2.99.917+git20170309-0ubuntu1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-siliconmotion-hwe-16.04 (xenial-proposed/universe) [1:1.7.8-1ubuntu6~16.04.1 => 1:1.7.9-2ubuntu1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-openchrome-hwe-16.04 (xenial-proposed/universe) [1:0.3.3+git20160310-1~16.04.1 => 1:0.5.0-3build1~16.04.1] (no packageset)
[14:02] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vesa-hwe-16.04 (xenial-proposed/main) [1:2.3.4-1build2~16.04.1 => 1:2.3.4-1build3~16.04.1] (no packageset)
[14:03] -queuebot:#ubuntu-release- Unapproved: xorg-hwe-16.04 (xenial-proposed/main) [1:7.7+13ubuntu4~16.04.2 => 1:7.7+16ubuntu3~16.04.1] (no packageset)
[14:07] -queuebot:#ubuntu-release- Unapproved: rejected xorg-hwe-16.04 [source] (xenial-proposed) [1:7.7+16ubuntu3~16.04.1]
[14:07] -queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.3]
[14:08] -queuebot:#ubuntu-release- Unapproved: rejected xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.3-1ubuntu1~16.04.1]
[14:09] <rbasak> seb128, Trevinho: is there any reason Yakkety can't be verified? Seems a waste of everybody's time to do it twice, and we do still support Yakkety, no?
[14:09] <seb128> rbasak, I'm downloading a yakkety iso now, but that's what seems the waste of time to me
[14:09] -queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.18.4-1ubuntu6.1~16.04.1 => 2:1.19.3-1ubuntu1~16.04.1] (no packageset)
[14:09] <Trevinho> rbasak: mh, actually I think it's the same xenial thing, so I'll mark it properly
[14:09] <seb128> Trevinho, don't
[14:10] <Trevinho> seb128: ok
[14:10] <seb128> Trevinho, did you suggest just tagging it as verified on yakkety without actually testing i there or did I understand you not correctly?
[14:11] <seb128> rbasak, downloading iso, installing yakkety, reproducing, upgrading, testing the SRU, that's going to take me an hour, that's a waste for a serie which is neither LTS nor current and has probably not much desktop users left
[14:12] <rbasak> seb128: if it's a waste, then we need to make the decision either to EOL Yakkety now, or halt all Yakkety SRUs now, or decide why in this case we don't want to SRU this to Yakkety for some other reason, etc.
[14:13] <infinity> rbasak: My general rule of thumb is that cosmetic/"polish" changes only need to go to devel and the stable series' you care to fix, but real behavioural bug fixes can't skip supported releases.
[14:13] <Trevinho> seb128: bug #1639507 as per Laney's word isn't fixed, but it's fine to mark it verified. So I would follow the same policiy for yakkety. Not for the other one tho
[14:13] <ubot5> bug 1639507 in unity-control-center (Ubuntu Yakkety) "unity-control-center in installed software is listed with wrong icon and title" [Medium,Fix committed] https://launchpad.net/bugs/1639507
[14:13] <infinity> Because someone upgrading from xenial to yakkety shouldn't be subject to a functional regression.
[14:13] <seb128> rbasak, well it's the issues with SRUs delays, when that SRU was started in february it was making sense, we were far enough from zesty
[14:14] <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
[14:14] <Trevinho> infinity: sure... It's even true that the stack at that level is pretty much the same, so I expect no much difference
[14:14] <rbasak> Trevinho: AIUI, that discussion was about the definition of the bug being fixed, rather than about verification of the fix for the definition decided upon.
[14:16] -queuebot:#ubuntu-release- Unapproved: xorg-hwe-16.04 (xenial-proposed/main) [1:7.7+13ubuntu4~16.04.2 => 1:7.7+16ubuntu3~16.04.1] (no packageset)
[14:18] <seb128> Trevinho, right about that issue, it's not fixed but also not a regression so it's fine
[14:23] <slashd> rbasak, mdeslaur has uploaded the open-iscsi as discussed, and it is "Not Considered" in the update_excuse page "open-iscsi (2.0.873+git0.3b4b4500-14ubuntu17 to 2.0.874-2ubuntu2) " did I miss something ? or it's just a matter for SRU to unblock it ?
[14:24] <slashd> unsatisfiable Depends:  ^
[14:27] <infinity> slashd: Didn't we literally just discuss this?
[14:28] <slashd> infinity, maybe I miss something, but my understanding was that mdeslaur could upload the package anyway right ? and that it won't be caught by the MIR ?
[14:29] <infinity> slashd: He can (and did) upload it.  That doesn't change that it won't migrate until the MIR is complete.
[14:29] <infinity> slashd: What we said was that this shouldn't block you doing your SRUs.
[14:31] <slashd> infinity, gotcha ok, sorry I miss that bit, so we are all good, I was under the impression it would skip it or something. While it is still Not Considered in Artful, can I start the upload in Stable release ?
[14:32] <infinity> slashd: Why would it skip checking if it was installable?  That's the whole point of proposed-migration.
[14:32] <infinity> slashd: And yes, as we said, you can upload your SRUs now.
[14:33] <slashd> infinity, great thanks, sorry about that, but I prefer to make sure before doing a mistake.
[14:46] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.4 => 2.26.8] (desktop-core, ubuntu-server)
[14:47] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.26.4+16.10 => 2.26.8+16.10] (desktop-core, ubuntu-server)
[14:48] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.4+17.04 => 2.26.8+17.04] (desktop-core, ubuntu-server)
[14:49] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.4~14.04 => 2.26.8~14.04] (no packageset)
[15:03]  * apw looks at snapd(s) ^^
[15:03] <ahasenack> hi, could I get someone to sponsor this upload for me please? https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813
[15:03] <ubot5> Ubuntu bug 1602813 in openvpn-auth-ldap (Ubuntu Zesty) "openvpn-auth-ldap causing segfault on network timeout" [Medium,In progress]
[16:43] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.26.8+17.04]
[16:43] <nacc> ahasenack: it's on my queue for today
[16:43] -queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (xenial-proposed) [1.0.10-2~16.04.1]
[16:43] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.26.8+16.10]
[16:43] <ahasenack> thx
[16:43] <nacc> ahasenack: you need it sponsored for all 4, right?
[16:43] <ahasenack> nacc: yes
[16:45] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.26.8~14.04]
[16:45] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.26.8]
[16:49] <nacc> ahasenack: i wonder when/if we should start reconsidering sru for yakkety
[16:49] <nacc> ahasenack: as it goes eol in ~ 2 weeks
[16:50] <apw> nacc, well there is no point in accepting anything with less than 8 days to go
[16:50] <nacc> apw: ack, that's what i meant :)
[16:51] <ahasenack> 2w > 8d?
[16:51] <nacc> apw: i just want to make sure i consider the versioning correctly in the case of somone getting an update in xenial, but then upgrading to yakkety (and thus the version being earlier w/o the sru there) before it goes eol, then upgrading to z.
[16:52] <apw> nacc, right you need to consider the version in yakkety in that sense
[16:52] <ahasenack> the bug has been open for a year, would be a shame to not close it for y
[16:54] -queuebot:#ubuntu-release- Unapproved: gwakeonlan (xenial-proposed/universe) [0.5.1-1.1 => 0.5.1-1.1ubuntu0.1] (no packageset)
[16:55] -queuebot:#ubuntu-release- Unapproved: rejected gwakeonlan [source] (xenial-proposed) [0.5.1-1.1ubuntu0.1]
[16:56] <nacc> ahasenack: right, but y itself is about to be closed
[16:56] -queuebot:#ubuntu-release- Unapproved: accepted gwakeonlan [source] (xenial-proposed) [0.5.1-1.1ubuntu0.1]
[16:56] <nacc> ahasenack: so it's a cost/benefit tradeoff, as i have to review it and then the sru team has to review it :)
[16:56] <nacc> apw: yep, thanks
[16:56] <ahasenack> this would be easier if there was a clear cut date in the ubuntu release table for sus
[16:56] <ahasenack> srus*
[16:56] <ahasenack> EOL: X
[16:56] <ahasenack> last day for SRU: Y
[16:57] <rbasak> That's a good idea.
[16:57] <nacc> +1
[16:57] <ahasenack> otherwise, of course we will be tempted to not do SRUs for a release if we are "getting close" to its EOL
[16:57] <rbasak> At least unless there's some exceptional reason.
[16:57] <ahasenack> "close" is subjective in this case
[16:57] <nacc> ahasenack: yeah, i'm just considering 7 days is how long something bakes in y-p
[16:57] <nacc> ahasenack: and so you're only going to have the fix for about a week before the release goes eol :)
[16:58] <nacc> ahasenack: which doesn't seem particularly relevant ... user is better off just upgrading to z with the fix there
[16:58] <ahasenack> well, it's a segfault
[16:58] <nacc> ahasenack: that is to say, i'm comfortable (hand-waving versioning for a moment) if the y solution is: upgrade to z because you have to in two weeks anyways
[16:58] <nacc> rbasak: thoughts?
[16:59] <rbasak> Depending on the bug, I think it's reasonable to set Won't Fix for Yakkety on that basis. In principle anyway.
[17:00] <nacc> rbasak: right
[17:00] <rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
[17:00] <rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
[17:00] <nacc> ahasenack: i'm also going off the eol announcement e-mail having just come out, which makes it feel like we're in the 'getting close' window more explicilty
[17:00] <rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
[17:00] <rbasak> From earlier: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
[17:00] <jbicha> honestly, given the number of unapproved SRUs in the queue, new yakkety ones will likely just not be able to make it in time unless they fix Really Serious issues
[17:01] <rbasak> Argh
[17:01] <rbasak> Sorry
[17:01] <ahasenack> well, it's your call guys
[17:01] <nacc> jbicha: right, that was also my thinking
[17:01] <ahasenack> that's what sponsoring is for
[17:01] <nacc> ahasenack: understood, you just prompted me to think about this
[17:01] <ahasenack> I did my job weeks ago :)
[17:02] <jbicha> xenial has 60 unapproved SRU candidates and zesty has 17 so it's difficult for the SRU team to keep up :|
[17:02] <nacc> jbicha: yep
[17:19] -queuebot:#ubuntu-release- Unapproved: ntp (trusty-proposed/main) [1:4.2.6.p5+dfsg-3ubuntu2.14.04.10 => 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11] (core)
[17:19] <apw> xenial to be fair is prep for the point release i believe
[17:30] -queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (zesty-proposed) [2:0.28.0+fixes.20170206.03f4403-0ubuntu3.1]
[17:49] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-85.108~14.04.1] (kernel)
[17:52] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-85.108~14.04.1]
=== Guest39045 is now known as med_
[18:09] <ahasenack> slangasek: hi, if I could have our opinion on something
[18:09] <ahasenack> slangasek: I have this patch (https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813/comments/0) provided by the user in the bug description
[18:09] <ubot5> Ubuntu bug 1602813 in openvpn-auth-ldap (Ubuntu Zesty) "openvpn-auth-ldap causing segfault on network timeout" [Medium,In progress]
[18:09] <ahasenack> he signs it with his name, but no email. His launchpad id hides his email and is a generic name (foxpass-dev)
[18:10] <ahasenack> how should I give credit for this in the patch dep3 header?
[18:10] <ahasenack> I used:
[18:10] <ahasenack> Original-Author: Aaron Peschel https://launchpad.net/~foxpass-dev
[18:10] <ahasenack> (n/m the Original bit)
[18:11] <slangasek> ahasenack: that seems reasonable to me; I don't have the dep3 schema memorized, but I'd say anything that's permitted is ok
[18:12] <ahasenack> slangasek: it expects an email
[18:12] <ahasenack> "This field can be used to record the name and email of the patch author (...)"
[18:12] <slangasek> that seems vague to me :-)
[18:12] <ahasenack> and so not future-proof :)
[18:13] <ahasenack> it gives an example, though, the classical First Last <foo@example.com>
[18:13] <slangasek> if you use a non-email value, and nothing crashes, LGTM
[18:13] <ahasenack> I can't be sure that nothing will crash
[18:13] <ahasenack> definitely nothing should crash on bad input
[18:13] <ahasenack> but we know better
[18:14] <slangasek> not much parses these
[18:14] <slangasek> you could feed it through dep3changelog and see what happens :)
[18:14] <ahasenack> worst case, another bug to fix? :)
[18:22] -queuebot:#ubuntu-release- Unapproved: iscsitarget (xenial-proposed/universe) [1.4.20.3+svn502-2ubuntu4.1 => 1.4.20.3+svn502-2ubuntu4.2] (no packageset)
[19:03] -queuebot:#ubuntu-release- New binary: octave-communications [ppc64el] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:05] -queuebot:#ubuntu-release- New binary: octave-communications [i386] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:05] -queuebot:#ubuntu-release- New binary: octave-communications [s390x] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:06] -queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (xenial-proposed) [1.4.20.3+svn502-2ubuntu4.2]
[19:06] -queuebot:#ubuntu-release- New binary: octave-communications [amd64] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:06] -queuebot:#ubuntu-release- New binary: octave-communications [arm64] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:07] -queuebot:#ubuntu-release- New binary: octave-communications [armhf] (artful-proposed/none) [1.2.1-3] (no packageset)
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [amd64] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [armhf] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [ppc64el] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [amd64] (artful-proposed) [1.2.1-3]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [armhf] (artful-proposed) [1.2.1-3]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [ppc64el] (artful-proposed) [1.2.1-3]
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [arm64] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [s390x] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [i386] (artful-proposed) [1.2.1-3]
[19:10] -queuebot:#ubuntu-release- New: accepted lrslib [i386] (artful-proposed) [0.62-2]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [s390x] (artful-proposed) [1.2.1-3]
[19:10] -queuebot:#ubuntu-release- New: accepted octave-communications [arm64] (artful-proposed) [1.2.1-3]
[20:08] -queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (xenial-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.04.1]
[20:27] -queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (trusty-proposed/universe) [2.0.3-5.1 => 2.0.3-5.1ubuntu0.1] (no packageset)
[20:27] -queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (yakkety-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.16.10.1] (no packageset)
[20:27] -queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (xenial-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.16.04.1] (no packageset)
[20:28] -queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (zesty-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.17.04.1] (no packageset)
[21:08] <infinity> ahasenack: To add to the bikeshed, I'd put the URL ref in ().  Since RFC person records / addresses are in the form "Name Name Name (Comment Comment Comment) <email@drre.ss>"
[21:09] <infinity> ahasenack: So, you'd have Name and Comment, but no address, which seems reasonable.
[21:09] <ahasenack> good to know
[21:16] <nacc> infinity: oh good point
[21:17] <nacc> ahasenack: sorry for all the noise on it, but i think it's a good discussion to have and get agreement on :)
[22:18] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu17 => 229-4ubuntu18] (core)
[22:22] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-proposed) [2.0.7-0ubuntu1~16.04.2]
[22:23] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (yakkety-proposed) [2.0.7-0ubuntu1~16.10.2]
[22:23] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (zesty-proposed) [2.0.7-0ubuntu1~17.04.2]
[23:56] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu5 => 2.02~beta3-4ubuntu6] (core)