| -queuebot:#ubuntu-release- New binary: node-js-tokens [amd64] (zesty-proposed/universe) [2.0.0-1] (no packageset) | 00:56 | |
| -queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.19~16.04.1 => 1.21.4~16.04.1] (core) | 03:55 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.4 => 1.66.5] (core) | 03:56 | |
| -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.4 => 2.02~beta2-36ubuntu3.5] (core) | 03:56 | |
| -queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [0.8-0ubuntu2 => 0.9+1474479173.6c180c6-0ubuntu1] (core) (sync) | 03:56 | |
| -queuebot:#ubuntu-release- Unapproved: shim (trusty-proposed/main) [0.8-0ubuntu2 => 0.9+1474479173.6c180c6-0ubuntu1] (core) (sync) | 03:57 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.14 => 1.34.15] (core) | 03:58 | |
| -queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.12 => 2.02~beta2-9ubuntu1.13] (core) | 03:58 | |
| -queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.19~14.04.1 => 1.21.4~14.04.1] (core) | 03:59 | |
| -queuebot:#ubuntu-release- Unapproved: grub2 (precise-proposed/main) [1.99-21ubuntu3.20 => 1.99-21ubuntu3.21] (core) | 04:00 | |
| -queuebot:#ubuntu-release- Unapproved: shim-signed (precise-proposed/main) [1.18~12.04.1 => 1.19~12.04.1] (no packageset) | 04:01 | |
| -queuebot:#ubuntu-release- Unapproved: shim (precise-proposed/main) [0.8-0ubuntu2 => 0.9+1474479173.6c180c6-0ubuntu1] (no packageset) (sync) | 04:01 | |
| -queuebot:#ubuntu-release- Unapproved: grub2-signed (precise-proposed/main) [1.9~ubuntu12.04.10 => 1.9~ubuntu12.04.11] (no packageset) | 04:06 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [ppc64el] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:20 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [ppc64el] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:22 | |
| -queuebot:#ubuntu-release- New binary: node-fs-extra [amd64] (zesty-proposed/none) [1.0.0-1] (no packageset) | 05:22 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [amd64] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [s390x] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [i386] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [amd64] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [s390x] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [i386] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [arm64] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:23 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [arm64] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:25 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [armhf] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:25 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [armhf] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:26 | |
| -queuebot:#ubuntu-release- New binary: espeak-ng [powerpc] (zesty-proposed/none) [1.49.0+dfsg-2] (no packageset) | 05:27 | |
| -queuebot:#ubuntu-release- New binary: libgkarrays [powerpc] (zesty-proposed/none) [2.1.0+dfsg-1] (no packageset) | 05:28 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [powerpc] (zesty-proposed) [2.1.0+dfsg-1] | 08:00 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [arm64] (zesty-proposed) [1.49.0+dfsg-2] | 08:00 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [powerpc] (zesty-proposed) [1.49.0+dfsg-2] | 08:00 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [armhf] (zesty-proposed) [1.49.0+dfsg-2] | 08:00 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [armhf] (zesty-proposed) [2.1.0+dfsg-1] | 08:00 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [i386] (zesty-proposed) [1.49.0+dfsg-2] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [arm64] (zesty-proposed) [2.1.0+dfsg-1] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [s390x] (zesty-proposed) [1.49.0+dfsg-2] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [amd64] (zesty-proposed) [1.49.0+dfsg-2] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [amd64] (zesty-proposed) [2.1.0+dfsg-1] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [s390x] (zesty-proposed) [2.1.0+dfsg-1] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted espeak-ng [ppc64el] (zesty-proposed) [1.49.0+dfsg-2] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted node-fs-extra [amd64] (zesty-proposed) [1.0.0-1] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [i386] (zesty-proposed) [2.1.0+dfsg-1] | 08:01 | |
| -queuebot:#ubuntu-release- New: accepted libgkarrays [ppc64el] (zesty-proposed) [2.1.0+dfsg-1] | 08:02 | |
| -queuebot:#ubuntu-release- New: accepted pysynphot [powerpc] (zesty-proposed) [0.9.8.5+dfsg-1] | 08:02 | |
| -queuebot:#ubuntu-release- New: accepted node-js-tokens [amd64] (zesty-proposed) [2.0.0-1] | 08:02 | |
| josvaz | Is arges or someone else from the SRU team available here? I would like to get http://launchpadlibrarian.net/292538218/walinuxagent_2.1.5-0ubuntu4~16.04.0_source.changes | 08:39 |
|---|---|---|
| josvaz | reviewed and if possible approved into -proposed | 08:40 |
| apw | josvaz, that seems to include a whole heap of new features (which may be reasonable) but also implies it needs to have some kind of update exception | 10:11 |
| rbasak | I know walinuxagent is a little special. Who usually handles it? | 10:27 |
| josvaz | This package is the same that has gone into yakkety. No additional changes were required | 10:28 |
| josvaz | Odd_Bloke produced the yakkety release, that has been approved and is running | 10:28 |
| Odd_Bloke | rbasak: We often bug slangasek for it. | 10:28 |
| josvaz | Azure would like xenial & trusty to also move up to walinuxagent 2.1.5 | 10:29 |
| josvaz | this is the xenial backport | 10:29 |
| Odd_Bloke | apw: AIUI, walinuxagent falls under the "cloudware" exception; it's equivalent to hardware-enablement for Azure. Not exactly sure where this is codified, though. | 10:30 |
| josvaz | rbasak, let me know how can I progress this forward (this is my first SRU attempt) | 10:34 |
| rbasak | josvaz: I'm unwilling to go into this without quite a bit of guidance from people who have handled it in the past. Given that it's my first day on the SRU rota. Might be best to wait for slangasek. | 10:37 |
| josvaz | ok, will ping him later, thanks | 10:38 |
| LocutusOfBorg | any archive admin that wants to remove pandas on some architectures? it has been done some time ago in debian bug #840567 #825103 | 10:39 |
| ubot5` | Debian bug 840567 in ftp.debian.org "RM: statsmodels [arm64 armel armhf mips mipsel powerpc s390x hppa mips64el ppc64] -- ROM; dependency (pandas) is missing on those archs now" [Normal,Open] http://bugs.debian.org/840567 | 10:39 |
| LocutusOfBorg | debian bug #825103 | 10:39 |
| ubot5` | Debian bug 825103 in ftp.debian.org "RM: pandas [arm64 armel armhf mips mipsel powerpc s390x hppa mips64el ppc64] -- ROM; FTBFS on those archs, not supported by upstream, hoggs dependent packages" [Normal,Open] http://bugs.debian.org/825103 | 10:39 |
| slangasek | rbasak: fwiw my standing approach on walinuxagent is "it's hardware enablement for a cloud, so it gets an exception" | 10:49 |
| rbasak | slangasek: I get that part, but how/what do I review? | 10:50 |
| slangasek | rbasak: just the packaging, really | 10:50 |
| rbasak | slangasek: and we ignore all upstream changes? What about QA requirements? | 10:51 |
| rbasak | I know walinuxagent has a poor history of releasing broken SRUs, for example. | 10:51 |
| slangasek | does it? I was not aware of much of that, actually | 10:52 |
| slangasek | so I've more or less punted the QA to the CPC team and upstream; if you're concerned that this doesn't have a high success rate, you should certainly use your own judgement and ask the CPC team for more | 10:53 |
| rbasak | I can't find a reference immediately, but I believe there have been at least a couple "SRU to fix previous broken SRU" things go past. | 10:53 |
| rbasak | (things that had been marked v-d) | 10:53 |
| rbasak | (and been released to -updates) | 10:53 |
| Odd_Bloke | From our POV, I think we're working better with upstream to test new releases. | 10:56 |
| Odd_Bloke | I think a lot of those failures stemmed from a lack of time to actually do things properly. | 10:57 |
| Odd_Bloke | But we do now spend time ensuring that they work; we also build images from -proposed and ask Azure to perform testing. | 10:57 |
| rbasak | FTR, I found bug 1479610, which is one of the bugs I had in mind. | 10:59 |
| ubot5` | bug 1479610 in walinuxagent (Ubuntu Precise) "[SRU] walinuxagent regression on dhcp configuration" [Critical,Fix released] https://launchpad.net/bugs/1479610 | 10:59 |
| rbasak | And https://launchpad.net/ubuntu/+source/walinuxagent/2.0.14-0ubuntu1~12.04.1 is another. | 11:01 |
| rbasak | Oh, that might have been v-f correctly. | 11:01 |
| apw | slangasek, i agree it sounds reasonable this has an exception, perhaps it needs codifying in our list so that the SRU bugs can point to it | 11:03 |
| slangasek | yes, that would be sensible :) | 11:03 |
| rbasak | Odd_Bloke, josvaz: I appreciate the test cases detailed in the bug. Would these catch the previous regression in bug 1603581 if it were to occur again? IOW, does the test check for what walinuxagent does, as well as that it has started and the instance works? | 11:06 |
| ubot5` | bug 1603581 in walinuxagent (Ubuntu Xenial) "Azure Linux Agent (WALA) 2.1.5 Released" [Wishlist,In progress] https://launchpad.net/bugs/1603581 | 11:06 |
| josvaz | checking that bug 1603581 | 11:09 |
| ubot5` | bug 1603581 in walinuxagent (Ubuntu Xenial) "Azure Linux Agent (WALA) 2.1.5 Released" [Wishlist,In progress] https://launchpad.net/bugs/1603581 | 11:09 |
| Odd_Bloke | rbasak: The previous regression referred to by Daniel Sol? That was actually in functionality that is disabled by default in Ubuntu. | 11:09 |
| Odd_Bloke | rbasak: But it could have been enabled (after boot), so they wanted us to include that patch. | 11:10 |
| rbasak | Sorry that might have been the wrong bug reference. | 11:11 |
| * rbasak looks again | 11:11 | |
| rbasak | https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1479610 is what I meant. My apologies. | 11:12 |
| ubot5` | Ubuntu bug 1479610 in walinuxagent (Ubuntu Precise) "[SRU] walinuxagent regression on dhcp configuration" [Critical,Fix released] | 11:12 |
| rbasak | AFAICT, that's a failure case where the instance boots correctly but fails in other behaviour. So is that covered by your current test cases? | 11:13 |
| Odd_Bloke | rbasak: Hmm, good question; I'm not sure if that specific failure is in our test suite. | 11:16 |
| josvaz | rbasak, I did not check that specifically in my tests | 11:16 |
| Odd_Bloke | josvaz: So we should (a) add that to our test suite, and (b) ensure that we're running our test suite against the one-off images we produce for -proposed testing. | 11:17 |
| josvaz | odd_Bloke, rbasak I can spin up the test image and check it | 11:17 |
| josvaz | ok | 11:17 |
| rbasak | Odd_Bloke, josvaz: thanks. Also, is this type of regression unique, or is it in a class of bugs that we need to be testing more widely? For example, does walinuxagent do anything else that could impact runtime instance behaviour that could regress in an update? | 11:18 |
| josvaz | AFAIK walinuxagent is just for setting up networking and initial config, but Odd_Bloke will know best | 11:19 |
| rbasak | Odd_Bloke, josvaz: I appreciate you having listed your test plans in the SRU bug. But I wonder: given it's getting more complicated now, would it be worth moving that to a wiki page and providing a link to the test plan instead? Would save a bunch of bug editing. | 11:19 |
| rbasak | Just a suggestion. I don't mean to require this - as long as your test plan is clearly available, which it currently is (though we're amending it) | 11:19 |
| Odd_Bloke | So walinuxagent is actually becoming less and less important to get something that boots; we've discussed removing it from the image entirely in the future. | 11:20 |
| Odd_Bloke | But it does currently still affect things fairly fundamentally. | 11:20 |
| Odd_Bloke | We do have a set of "does Ubuntu work properly here?" tests that we run against all images, which should capture anything it might break. | 11:20 |
| rbasak | I feel that testing should include areas that it is known to impact. For example, it used to mess with ssh config (don't know if it still does), so tests should include the ssh functionality it messes with. | 11:21 |
| rbasak | (this doesn't apply if it doesn't do that any more) | 11:21 |
| * apw recommends pulling that out as a separate wiki page so when it gets a formal exception that can be pointed to | 11:21 | |
| Odd_Bloke | Agreed. | 11:21 |
| Odd_Bloke | rbasak: apw: Any recommendations as to how that wiki page should be named? (Are there any models we can follow?) | 11:25 |
| rbasak | No strong opinion. "walinuxagent SRU test plan" are what I'd entitle it if it were me. No idea about existing patterns, or how to encode that into a URL! | 11:26 |
| josvaz | what about http://wiki.ubuntu.com/SRU_walinuxagent_Test_Plan? | 11:37 |
| apw | Odd_Bloke, have a look at the SRU exceptions page, i think that has links to things like that, which may have names you can clone | 11:37 |
| josvaz | will be starting that as soon as I get to login into the ubuntu wiki | 11:37 |
| josvaz | checking that, thanks apw | 11:37 |
| apw | josvaz, it looks like we document the whole process for an update in like <thing>Updates | 11:38 |
| balloons | rbasak, are you on SRU's today? | 11:38 |
| josvaz | apw: ok, so http://wiki.ubuntu.com/walinuxagentUpdates instead? | 11:39 |
| rbasak | balloons: yes | 11:39 |
| -queuebot:#ubuntu-release- New binary: otb [ppc64el] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 11:43 | |
| -queuebot:#ubuntu-release- New binary: otb [s390x] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 11:45 | |
| -queuebot:#ubuntu-release- New binary: otb [i386] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 11:50 | |
| josvaz | working on https://wiki.ubuntu.com/walinuxagentUpdates | 11:52 |
| rbasak | Thanks. I'm reviewing the diffs. | 11:54 |
| apw | josvaz, i would guess some of that content is "yours" and the bottom bits would need to be approved by an SRU team member, like shortening release times | 11:54 |
| josvaz | ok, once it is ready for review I will pink rbasak again. Thanks apw | 11:56 |
| apw | np | 11:56 |
| -queuebot:#ubuntu-release- New binary: otb [amd64] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 11:58 | |
| balloons | pitti, I'm not remembering where we ended up on the 32-bit autopkgtests running on yakkety for juju-core. I was thinking the thought was a britney bug. Is this true? | 12:11 |
| pitti | balloons: they are running because: juju-core | 1.25.6-0ubuntu2.16.10.1 | yakkety/universe | all | 12:12 |
| balloons | ahh.. it does seem the failures are ignored. So that's fine | 12:12 |
| pitti | balloons: i. e. the metapackage actually does exist on 32 bit arches, and you said you fixed that in git (Architecture: all → 64 bit arch list) | 12:12 |
| pitti | balloons: well, not "fine", it will be blocked again next time | 12:12 |
| * balloons looks again | 12:13 | |
| pitti | oh, that is from 1.25 -- so the new transitional actually does use "any" (or hardcoded list) | 12:14 |
| balloons | indeed, my version uses the hardcoded list | 12:14 |
| * balloons checks cyphermox's upload | 12:14 | |
| pitti | so on yakkety i386 and armhf juju-core 1.25.6 exists again | 12:14 |
| pitti | which we can't do anything about in stables (we'll need to keep hinting), but it shoudl be removed on zesty | 12:15 |
| pitti | juju-core | 1.25.6-0ubuntu2.16.10.1 | zesty/universe | all | 12:15 |
| pitti | balloons: do you actually plan to remove 1.25 wholesale from z? I suppose you don't want to support that forever? | 12:16 |
| balloons | pitti, yes we do. We have an open bug about removing it from yakkety as well | 12:16 |
| pitti | balloons: you can't remove a package from a stable release | 12:16 |
| pitti | balloons: happy to remove it from zesty right now, what's the bug #? | 12:17 |
| balloons | pitti, right absolutely. I pushed back because 2.0 wasn't stable until yakkety release | 12:17 |
| balloons | I think that may be a nice bug resolution, just swap to z | 12:17 |
| -queuebot:#ubuntu-release- New binary: otb [arm64] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 12:18 | |
| -queuebot:#ubuntu-release- New binary: otb [armhf] (zesty-proposed/universe) [5.8.0+dfsg-1] (no packageset) | 12:20 | |
| balloons | pitti, can you target this? https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1612116 | 12:21 |
| ubot5` | Ubuntu bug 1612116 in juju-mongodb (Ubuntu) "please remove juju-core-1 and juju-mongodb packages from yakkety" [Wishlist,Incomplete] | 12:21 |
| balloons | pitti, also the juju-mongodb can go | 12:22 |
| * pitti retitles that to zesty | 12:22 | |
| balloons | rbasak, so xenial and yakkety have juju-core in proposed that have gone through the SRU process. Can you have a look? | 12:24 |
| balloons | pitti, thank you for reminding me and taking care of that :-) | 12:24 |
| pitti | balloons: *flush*, done :) | 12:25 |
| rbasak | apw, slangasek: what should happen to debian/changelog when backporting from a future release in an SRU? Should it follow the history of the thing it's backporting from, or the history of the release it's being backported to? Or both, with dpkg-mergechangelogs? | 12:44 |
| * rbasak thinks he asked infinity about this years ago doing some backports for docker.io or similar, but doesn't remember the answer :-( | 12:45 | |
| rbasak | josvaz: I don't see anything in the Trusty queue to review. Is that uploaded yet? | 12:47 |
| === didrocks1 is now known as didrocks | ||
| apw | rbasak, i have seen it done both ways, i have personally tended to be happy with either, but i would not like to say i am definitive in this | 12:53 |
| rbasak | Thanks. I guess I'm also happy either way (debian/changelog's linear format creaks a bit here, but Launchpad has the real history anyway). It's be nice to be consistent though. | 12:54 |
| rbasak | It'd be nice | 12:54 |
| rbasak | Makes it easier for uploaders, sponsors, etc. | 12:54 |
| apw | rbasak, right all of that | 13:01 |
| -queuebot:#ubuntu-release- New: accepted otb [amd64] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| -queuebot:#ubuntu-release- New: accepted otb [armhf] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| -queuebot:#ubuntu-release- New: accepted otb [ppc64el] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| -queuebot:#ubuntu-release- New: accepted otb [arm64] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| -queuebot:#ubuntu-release- New: accepted otb [s390x] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| -queuebot:#ubuntu-release- New: accepted otb [i386] (zesty-proposed) [5.8.0+dfsg-1] | 13:03 | |
| josvaz | rbasak: no the trusty package is prepared, but I have not given a test image to Azure yet | 13:12 |
| Odd_Bloke | rbasak: The Azure team want us to release this to xenial before trusty. | 13:15 |
| rbasak | josvaz, Odd_Bloke: OK. Let me know when you have the new test plan ready please? | 13:16 |
| rbasak | cyphermox, smoser, lamont: I'm looking at open-iscsi in yakkety unapproved. None of the zesty tasks are marked Fix Released, and I see smoser's objection. What's the current status of all of that please? | 13:17 |
| josvaz | rbasak: https://wiki.ubuntu.com/walinuxagentUpdates is going to be mostly it | 13:18 |
| josvaz | I was going just to add the list of regressions we'll be testing for | 13:18 |
| rbasak | Looks like the open-iscsi upload to Zesty has failed dep8 too. Possibly unrelated, but given the impact of this SRU and the previous regression, surely all our ducks should be in a row before going ahead with this? | 13:18 |
| smoser | rbasak, link for context ? | 13:18 |
| smoser | bug ? | 13:18 |
| * smoser has to leave here in a minute or two, but i'll come back | 13:18 | |
| rbasak | smoser: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1621507 | 13:18 |
| ubot5` | Ubuntu bug 1621507 in open-iscsi (Ubuntu Yakkety) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] | 13:18 |
| -queuebot:#ubuntu-release- Unapproved: dovecot (xenial-proposed/main) [1:2.2.22-1ubuntu2.1 => 1:2.2.22-1ubuntu2.2] (ubuntu-server) | 13:37 | |
| -queuebot:#ubuntu-release- Unapproved: dovecot (yakkety-proposed/main) [1:2.2.24-1ubuntu1 => 1:2.2.24-1ubuntu1.1] (ubuntu-server) | 13:37 | |
| -queuebot:#ubuntu-release- Unapproved: python-pip (xenial-proposed/universe) [8.1.1-2ubuntu0.3 => 8.1.1-2ubuntu0.4] (no packageset) | 13:53 | |
| -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-47.68~14.04.1] (kernel) | 13:54 | |
| -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-47.68] (core, kernel) | 13:54 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-47.68] | 13:58 | |
| josvaz | rbasak: https://wiki.ubuntu.com/walinuxagentUpdates is ready for you to review | 13:58 |
| -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-47.68~14.04.1] | 13:59 | |
| rbasak | josvaz: thanks, looking. | 14:06 |
| -queuebot:#ubuntu-release- Unapproved: python-pip (yakkety-proposed/universe) [8.1.2-2 => 8.1.2-2ubuntu0.1] (no packageset) | 14:06 | |
| cyphermox | rbasak, open-iscsi hasn't regressed in the autopkgtests, it's failing because there aren't zesty images for maas yet. | 14:10 |
| cyphermox | (I've been trying to get people to fix that) | 14:10 |
| rbasak | cyphermox: do you know that the inability to test isn't hiding a regression though? | 14:11 |
| cyphermox | yes, I do. The change in open-iscsi is highly unlikely to regress | 14:11 |
| cyphermox | I'm not saying to skip the tests, I want to see them run and see them green too | 14:12 |
| cyphermox | just saying that you currently can't say it has regressed. | 14:12 |
| rbasak | As a whole, the effort to fix this issue *has* regressed a stable release. Additionally, the open-iscsi dep8 test *is* failing, and may indicate a regression. | 14:13 |
| cyphermox | rbasak: as a whole, *initramfs-tools* regressed, not the rest of it. | 14:13 |
| rbasak | Is there any benefit to landing this without an initramfs-tools update? | 14:14 |
| rbasak | (in an SRU) | 14:15 |
| cyphermox | avoiding confusion in SRU tags, like you said. There is should be no effect on the current behavior in initramfs-tools (which is good to verify in itself) and should also work with the new initramfs-tools. | 14:16 |
| cyphermox | rbasak: having it in -proposed allows further testing of the SRU, to make sure my testing didn't miss something. | 14:16 |
| rbasak | I don't follow. Avoiding confusion in SRU tags would be testing all three together, and only marking v-d when all three are done. What does "further testing of the SRU" mean? What further testing do you expect to do for open-iscsi that you can't do from a PPA? I expect that all three together in -proposed to create a cloud image that can be tested is useful, but I don't see the case for one. And | 14:19 |
| rbasak | doing just one introduces the tag race if a second is accepted. | 14:19 |
| cyphermox | as much as I want and can test things, corner cases can be missed. the usual idea with rolling out changes is that you test with one person (locally), then multiple (PPA), then yet more (-proposed), until you can roll it out to everyone (-updates) | 14:21 |
| rbasak | You missed the test in the development release. | 14:22 |
| rbasak | The point of testing from -proposed is to test the real binary that would be released. | 14:23 |
| rbasak | In case the build is somehow different in a PPA, etc. | 14:23 |
| cyphermox | yes, that's why it's in the queue now. | 14:23 |
| rbasak | And that's why the SRU process expects you to test in the development release first, which you are conveniently ignoring. | 14:23 |
| cyphermox | as for the open-iscsi in zesty-proposed, as much as I would like it to have been promoted to -release weeks ago, it's not all up to me. | 14:24 |
| cyphermox | if you feel you must not accept open-iscsi, just reject it. | 14:24 |
| rbasak | Am I right in thinking that apart from your claimed additional testing, users won't actually benefit from an open-iscsi update for this issue until initramfs-tools is also updated? | 14:25 |
| -queuebot:#ubuntu-release- Unapproved: samba (trusty-proposed/main) [2:4.3.11+dfsg-0ubuntu0.14.04.1 => 2:4.3.11+dfsg-0ubuntu0.14.04.2] (core) | 14:25 | |
| cyphermox | of course you're right, that's also the point, it ensures there is no regression in open-iscsi itself. | 14:26 |
| cyphermox | ie. open-iscsi is released, nothing breaks, then we can easily test initramfs-tools, and see that any regression has to do with the iniramfs-tools change, not something broken in open-iscsi for another reason. | 14:27 |
| cyphermox | balloons: what's the story right now with juju-core? | 14:27 |
| smoser | rbasak, you and i discussed the open-iscsi tests once... i have a bunch of improvements to it, but its reliance on images is less than ideal.. let me dig up what i wrote. | 14:29 |
| rbasak | So I think we have to opposing opinions here. I wrote up what I thought in https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507/comments/37. cyphermox's proposed plan is above and the two are mutually exclusive I think. | 14:30 |
| ubot5` | Ubuntu bug 1621507 in open-iscsi (Ubuntu Yakkety) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] | 14:30 |
| rbasak | smoser, lamont: opinions? ^ | 14:30 |
| cyphermox | I don't see how our opinion of open-iscsi is opposed? | 14:31 |
| cyphermox | oh wait | 14:31 |
| rbasak | My opinion is to wait until they can all be accepted together every step of the way. | 14:31 |
| cyphermox | heh | 14:31 |
| rbasak | Your opinion I think is to do the opposite - open-iscsi first, with no interference from the others. I think. | 14:32 |
| cyphermox | yes, it is | 14:32 |
| rbasak | Does that mean you would expect no SRU uploads of the other packages until open-iscsi is all the way through the SRU process (either in -updates or deleted from -proposed?) | 14:32 |
| cyphermox | my way, you can also make sure each individual piece doesn't regress the rest of the world. | 14:32 |
| cyphermox | rbasak: no | 14:32 |
| cyphermox | any uploads can still happen, none of this has any effect until the iniramfs-tools SRU happens. | 14:33 |
| rbasak | Then we end up with tag confusion in the bug, no? | 14:33 |
| cyphermox | why? | 14:33 |
| cyphermox | open-iscsi can go all the way to updates before we do any other piece. | 14:33 |
| cyphermox | it's usually a good thing to not have multiple variables changing at the same time. | 14:34 |
| rbasak | I thought I asked exactly that, and you said no? | 14:34 |
| cyphermox | any SRUs can happen for any package in the meantime, including the other parts of initramfs-tools and isc-dhcp; but I would prefer neither include that SRU in the meantime. However, what you wrote could also be parsed as "there should not be another SRU of any of the affected packages in the meantime", to which the answer is "no" | 14:35 |
| rbasak | Oh, I see. | 14:36 |
| rbasak | I think. | 14:36 |
| rbasak | Let me try again. | 14:36 |
| rbasak | Does that mean you would expect no SRU uploads *for this particular issue* of the other packages until open-iscsi is all the way through the SRU process (either in -updates or deleted from -proposed?) | 14:36 |
| cyphermox | sure. | 14:36 |
| cyphermox | that's the way I'd do it tbh. | 14:36 |
| rbasak | OK, thanks. I think I understand your PoV now. | 14:36 |
| cyphermox | or maybe isc-dhcp and open-iscsi. since they're not linked. | 14:36 |
| cyphermox | but I would definitely wait for both of those to be in -updates before landing initramfs-tools | 14:37 |
| rbasak | They are linked in the bug though. | 14:37 |
| rbasak | That's where the tag confusion might happen. | 14:37 |
| cyphermox | sure | 14:37 |
| cyphermox | we're all adults, we can handle bug tags, presumably | 14:37 |
| cyphermox | that's why god invented comments. | 14:37 |
| rbasak | No, we can't. Bug 1511735 is my standard example of how this can go wrong. Not exactly the same thing, but IMHO the moment we try to do multiple things at once in the SRU process through one bug, we risk regression, and that does happen. | 14:38 |
| ubot5` | bug 1511735 in libnl3 (Ubuntu Trusty) "libnl: fail to bind() netlink sockets" [Medium,Fix released] https://launchpad.net/bugs/1511735 | 14:38 |
| cyphermox | looks to me like each tag change is commented and clear, but I haven't read all of it | 14:40 |
| rbasak | Yet it was released to -updates. | 14:40 |
| smoser | Overall, I'm mostly ok with the changes that are going in to add ipv6 support to initramfs. I'd these changes documented though, and I'm not aware of any doc on the new net6-*.conf files or their content. | 14:42 |
| cyphermox | so why? what was the confusion? | 14:42 |
| cyphermox | smoser: README.Debian. | 14:42 |
| smoser | README.Debian in what package ? | 14:43 |
| cyphermox | initramfs-tools | 14:43 |
| cyphermox | (which is what deals with these files) | 14:43 |
| cyphermox | wait, no | 14:44 |
| cyphermox | isc-dhcp, which creates the net6- file. | 14:44 |
| rbasak | Surely the documentation should be in the package that parses it? | 14:45 |
| smoser | does it create those in all cases now ? or just when run in initramfs? | 14:45 |
| rbasak | Since usually that's in one case, and in the general case multiple things might produce a thing. | 14:45 |
| cyphermox | rbasak: surely the documentation can be in the package that creates it? | 14:45 |
| cyphermox | rbasak: these files aren't even meant to be used by anything aside from initramfs-tools, and even then, it's debatable. | 14:46 |
| cyphermox | smoser: what do you mean? it's only of any use in the iniramfs. | 14:46 |
| smoser | but as you said "aren't even meant to be used by anything aside from initramfs-tools" | 14:46 |
| smoser | so i'd like to keep their creation to only occuring when used in initramfs | 14:47 |
| cyphermox | yes, meaning that cloud-init shouldn't be using them. | 14:47 |
| smoser | as they were with klibc | 14:47 |
| cyphermox | yes, that's how things are. | 14:47 |
| cyphermox | only created when in the initramfs. | 14:47 |
| rbasak | Who will be uploading the initramfs-tools and isc-dhcp fixes for this issue when that is ready? | 14:49 |
| cyphermox | I will. | 14:49 |
| rbasak | Let me write up a plan | 14:50 |
| rbasak | cyphermox, smoser: does http://pad.ubuntu.com/0Aj2S2OwIT seem reasonable to you both? | 14:55 |
| -queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.3-0ubuntu0.16.04.1 => 10.2.3-0ubuntu0.16.04.2] (kubuntu, ubuntu-desktop, ubuntu-server) | 15:00 | |
| -queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.3-0ubuntu2 => 10.2.3-0ubuntu2.1] (kubuntu, ubuntu-desktop, ubuntu-server) | 15:00 | |
| -queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu0.16.04.1 => 2:4.3.11+dfsg-0ubuntu0.16.04.2] (core) | 15:00 | |
| cyphermox | yeah, seems alright | 15:06 |
| cyphermox | I'm off today though, so anything other than the open-iscsi in the queue will wait until tomorrow. | 15:06 |
| cyphermox | smoser: ^ | 15:06 |
| cyphermox | smoser: I did see your diff though, looks good. | 15:06 |
| rbasak | cyphermox: smoser mentioned whitespace errors. I haven't actually reviewed yet, but are you happy for me to just fix those up? | 15:07 |
| cyphermox | sure | 15:07 |
| rbasak | OK, thanks! | 15:07 |
| cyphermox | if you change things though, you shouldn't review the SRU | 15:08 |
| rbasak | I was going to ask smoser | 15:09 |
| smoser | well, white space is fair for him to fix. | 15:09 |
| rbasak | I think it's fine for me to review the substance and ask smoser to make sure I haven't done something stupid with whitespace changes. | 15:09 |
| rbasak | It would meet the spirit of the 2-person review thing I think. | 15:10 |
| smoser | :) | 15:10 |
| * rbasak is just grabbing a snack, then he'll hit this. | 15:10 | |
| lamont | rbasak: overall, I'm a proponent of the ip= and ip6= approach mostly because we are not upstream, and it's easier to support whatever solution they come up with eventually (hopefully ours...) if we add an argument for it, rather than extending the old in what we hope is the direction they will go. It would be nice to be able to retire the fork sooner, rather than never. | 15:30 |
| lamont | or at least have the fork be easy to maintain | 15:30 |
| lamont | as a consumer of the bits, I just want them to work. It pains me that I've had to do as much on those parts as I have, since it means more late nights for me catching up on the work that was blocked on same. | 15:31 |
| balloons | cyphermox, not sure if juju-core guy looked at | 15:34 |
| * balloons sees them in proposed still | 15:35 | |
| rbasak | smoser: that whitespace error also exists in zesty-proposed. I'm tempted to just leave it for consistency with itself. | 15:39 |
| rbasak | Otherwise you end up with a diff against the backport. | 15:39 |
| smoser | :-( | 15:41 |
| smoser | i somewhat agree with you. | 15:41 |
| rbasak | Fixing it in zesty-proposed would be fine, but it's not worth it. The mistake's been made. | 15:42 |
| rbasak | Also, though, there's: | 15:42 |
| rbasak | - for i in /run/net-*.conf ; do | 15:42 |
| rbasak | + for i in /run/net-*.conf; do | 15:42 |
| rbasak | That really has no need to be in an SRU, though minor enough that I guess I'll let it slide. This is a cherry-pick type SRU, not a backport of many changes, where it might make sense to carry it through. | 15:43 |
| rbasak | cyphermox, lamont: ^ | 15:43 |
| -queuebot:#ubuntu-release- Unapproved: samba (yakkety-proposed/main) [2:4.4.5+dfsg-2ubuntu5 => 2:4.4.5+dfsg-2ubuntu5.1] (core) | 15:56 | |
| lamont | rbasak: fair point | 15:56 |
| -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (yakkety-proposed) [2.0.873+git0.3b4b4500-14ubuntu8.1] | 15:57 | |
| -queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.2] | 15:59 | |
| -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.13~16.04 => 0.14~16.04] (no packageset) | 16:03 | |
| -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.14~16.04] | 16:10 | |
| -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.13~16.04 => 0.14~16.04] (no packageset) | 16:12 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.18] | 16:43 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.17 => 1:16.04.18] (core) | 17:19 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [arm64] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:20 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [ppc64el] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:20 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [armhf] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:20 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [ppc64el] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:20 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [ppc64el] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:21 | |
| -queuebot:#ubuntu-release- New binary: python-openflow [amd64] (zesty-proposed/none) [1.1.0~alpha2-1] (no packageset) | 17:21 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [armhf] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:21 | |
| -queuebot:#ubuntu-release- New binary: forensics-extra [amd64] (zesty-proposed/none) [1.0] (no packageset) | 17:21 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [arm64] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:21 | |
| -queuebot:#ubuntu-release- New binary: constantly [amd64] (zesty-proposed/none) [15.1.0-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [amd64] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: fonts-adf [amd64] (zesty-proposed/none) [0.20110505-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [amd64] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: gpxpy [amd64] (zesty-proposed/none) [1.1.1-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: w1retap [arm64] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [arm64] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: w1retap [armhf] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [s390x] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:22 | |
| -queuebot:#ubuntu-release- New binary: crac [amd64] (zesty-proposed/none) [2.5.0+dfsg-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [i386] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [ppc64el] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [i386] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: w1retap [amd64] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: node-micromatch [amd64] (zesty-proposed/none) [2.3.11-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [amd64] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: pixiewps [powerpc] (zesty-proposed/none) [1.2.2-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: r-cran-viridis [amd64] (zesty-proposed/none) [0.3.4-1] (no packageset) | 17:23 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [s390x] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:24 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [s390x] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:24 | |
| -queuebot:#ubuntu-release- New binary: procyon [amd64] (zesty-proposed/none) [0.5.32-1] (no packageset) | 17:24 | |
| -queuebot:#ubuntu-release- New binary: w1retap [s390x] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:24 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [powerpc] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:24 | |
| -queuebot:#ubuntu-release- New binary: asyncpg [i386] (zesty-proposed/none) [0.6.3-1] (no packageset) | 17:25 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [i386] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:25 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [amd64] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:25 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [arm64] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:26 | |
| -queuebot:#ubuntu-release- New binary: w1retap [i386] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:26 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [armhf] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:27 | |
| -queuebot:#ubuntu-release- New binary: r-cran-randomfieldsutils [powerpc] (zesty-proposed/none) [0.3.3.1-1] (no packageset) | 17:27 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [s390x] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:28 | |
| -queuebot:#ubuntu-release- New binary: w1retap [powerpc] (zesty-proposed/none) [1.4.4-1] (no packageset) | 17:28 | |
| -queuebot:#ubuntu-release- New binary: qevercloud [powerpc] (zesty-proposed/none) [3.0.3+ds-1] (no packageset) | 17:32 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [powerpc] (zesty-proposed) [3.0.3+ds-1] | 17:51 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [powerpc] (zesty-proposed) [1.4.4-1] | 17:51 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [s390x] (zesty-proposed) [3.0.3+ds-1] | 17:51 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [amd64] (zesty-proposed) [3.0.3+ds-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [armhf] (zesty-proposed) [3.0.3+ds-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [i386] (zesty-proposed) [1.4.4-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [arm64] (zesty-proposed) [3.0.3+ds-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [powerpc] (zesty-proposed) [0.3.3.1-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [i386] (zesty-proposed) [0.6.3-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [s390x] (zesty-proposed) [0.6.3-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [powerpc] (zesty-proposed) [0.6.3-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [i386] (zesty-proposed) [3.0.3+ds-1] | 17:52 | |
| -queuebot:#ubuntu-release- New: accepted node-micromatch [amd64] (zesty-proposed) [2.3.11-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [powerpc] (zesty-proposed) [1.2.2-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted qevercloud [ppc64el] (zesty-proposed) [3.0.3+ds-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [amd64] (zesty-proposed) [1.4.4-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [i386] (zesty-proposed) [1.2.2-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [s390x] (zesty-proposed) [0.3.3.1-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted procyon [amd64] (zesty-proposed) [0.5.32-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [s390x] (zesty-proposed) [1.4.4-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted crac [amd64] (zesty-proposed) [2.5.0+dfsg-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [amd64] (zesty-proposed) [0.3.3.1-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-viridis [amd64] (zesty-proposed) [0.3.4-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted gpxpy [amd64] (zesty-proposed) [1.1.1-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [armhf] (zesty-proposed) [1.4.4-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [i386] (zesty-proposed) [0.3.3.1-1] | 17:53 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [arm64] (zesty-proposed) [0.6.3-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [s390x] (zesty-proposed) [1.2.2-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [amd64] (zesty-proposed) [0.6.3-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [amd64] (zesty-proposed) [1.2.2-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted constantly [amd64] (zesty-proposed) [15.1.0-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted w1retap [arm64] (zesty-proposed) [1.4.4-1] | 17:54 | |
| -queuebot:#ubuntu-release- New: accepted asyncpg [ppc64el] (zesty-proposed) [0.6.3-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted forensics-extra [amd64] (zesty-proposed) [1.0] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [arm64] (zesty-proposed) [0.3.3.1-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted fonts-adf [amd64] (zesty-proposed) [0.20110505-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [armhf] (zesty-proposed) [0.3.3.1-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted python-openflow [amd64] (zesty-proposed) [1.1.0~alpha2-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [arm64] (zesty-proposed) [1.2.2-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [ppc64el] (zesty-proposed) [1.2.2-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted pixiewps [armhf] (zesty-proposed) [1.2.2-1] | 17:55 | |
| -queuebot:#ubuntu-release- New: accepted r-cran-randomfieldsutils [ppc64el] (zesty-proposed) [0.3.3.1-1] | 17:55 | |
| -queuebot:#ubuntu-release- Unapproved: knopflerfish-osgi (yakkety-proposed/universe) [5.2.0-1 => 5.2.0-1ubuntu0.1] (no packageset) | 19:21 | |
| -queuebot:#ubuntu-release- Unapproved: metacity (yakkety-proposed/main) [1:3.20.3-1ubuntu2 => 1:3.20.3-1ubuntu2.1] (ubuntu-desktop) | 19:59 | |
| bdmurray | infinity: Are there any more point releases scheduled for X? https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule | 21:30 |
| -queuebot:#ubuntu-release- Unapproved: accepted iio-sensor-proxy [source] (yakkety-proposed) [1.3-1ubuntu1] | 22:15 | |
| -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (yakkety-proposed) [1:3.20.2-0ubuntu2] | 22:16 | |
| -queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (yakkety-proposed) [0.5.0+git1.656f8865-5ubuntu7.1] | 22:17 | |
| -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.1] | 22:19 | |
| -queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (yakkety-proposed) [1:2.2.24-1ubuntu1.1] | 22:20 | |
| -queuebot:#ubuntu-release- Unapproved: accepted python-pip [source] (yakkety-proposed) [8.1.2-2ubuntu0.1] | 22:21 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (yakkety-proposed) [10.2.3-0ubuntu2.1] | 22:24 | |
| -queuebot:#ubuntu-release- Unapproved: accepted samba [source] (yakkety-proposed) [2:4.4.5+dfsg-2ubuntu5.1] | 22:27 | |
| -queuebot:#ubuntu-release- Unapproved: accepted knopflerfish-osgi [source] (yakkety-proposed) [5.2.0-1ubuntu0.1] | 22:28 | |
| -queuebot:#ubuntu-release- Unapproved: accepted metacity [source] (yakkety-proposed) [1:3.20.3-1ubuntu2.1] | 22:28 | |
| -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.1+bzr5544-0ubuntu1~16.10.1] | 22:30 | |
| -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.7] | 22:31 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [ppc64el] (zesty-proposed/none) [2.1.0-2] (no packageset) | 23:23 | |
| -queuebot:#ubuntu-release- New binary: django-html-sanitizer [amd64] (zesty-proposed/none) [0.1.5-1] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: goopg [amd64] (zesty-proposed/none) [0.3.1-2] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [s390x] (zesty-proposed/none) [0.2.33-1] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [i386] (zesty-proposed/universe) [0.2.33-1] (no packageset) | 23:26 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [s390x] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [amd64] (zesty-proposed/universe) [0.2.33-1] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [amd64] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [arm64] (zesty-proposed/universe) [0.2.33-1] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [i386] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [arm64] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:28 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [armhf] (zesty-proposed/universe) [0.2.33-1] (no packageset) | 23:29 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [armhf] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:29 | |
| -queuebot:#ubuntu-release- New binary: tipp10 [powerpc] (zesty-proposed/universe) [2.1.0-2] (no packageset) | 23:31 | |
| -queuebot:#ubuntu-release- New binary: gnuastro [powerpc] (zesty-proposed/universe) [0.2.33-1] (no packageset) | 23:31 | |
| infinity | rbasak: My opinion on backport versioning depends on if it's a real backport or a an orig.tar.gz bump. | 23:51 |
| infinity | rbasak: For instance, if it's literally a reupload of a xenial package to trusty, bump the changelog, call it xenialver~16.04.1, and call it done. | 23:52 |
| infinity | rbasak: But some packages have historically taken upstream bumps *without* all the packaging changes (mysql, tzdata, etc), then the changelog should be similarly correc. | 23:52 |
| infinity | t | 23:52 |
| infinity | rbasak: Err, xenialver~14.04.1. You know what I meant. Hopefully. | 23:53 |
| rbasak | infinity: got it. Thanks! | 23:54 |
| infinity | rbasak: Another way to argue it is to argue if the changelog should be tracking the package's upload history in a series, or the source's evolutionary history. I obviously fall into the latter group. | 23:55 |
| infinity | If the source was incremented in T, U, V, W, X, then backported to P, then that's what I want to see, not some made-up history that doesn't actually reflect the contents of the package. | 23:55 |
| infinity | (Others likely fall on the other side of that argument, but meh) | 23:56 |
| rbasak | I think I can the merits of both sides of that | 23:56 |
| infinity | Indeed. | 23:56 |
| infinity | But upload history exists in LP, as you note. | 23:56 |
| infinity | While source history (more like a VCS history) is more relevant to me as a user. | 23:57 |
| infinity | When I want to know "what version did X support Y" or whatever. | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!