=== Guest48238 is now known as RAOF [00:17] -queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.15-0ubuntu0.16.04.4 => 7.0.18-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) [00:21] -queuebot:#ubuntu-release- New sync: php7.1 (artful-proposed/primary) [7.1.4-2] [00:21] -queuebot:#ubuntu-release- Unapproved: php7.0 (yakkety-proposed/main) [7.0.15-0ubuntu0.16.10.4 => 7.0.18-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server) [00:23] -queuebot:#ubuntu-release- Unapproved: php7.0 (zesty-proposed/main) [7.0.15-1ubuntu4 => 7.0.18-0ubuntu0.17.04.1] (kubuntu, ubuntu-desktop, ubuntu-server) [00:28] -queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20170208.0.a34b091-0ubuntu1 => 3.20.1+git20170427.0.3d09239-0ubuntu1] (ubuntu-desktop) [00:36] -queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20170208.0.a34b091-0ubuntu1~xenial1 => 3.20.1+git20170427.0.3d09239-0ubuntu1~xenial1] (ubuntu-desktop) [02:44] Archive admins: please override the test regression in ostree, looks fine to me and builds fine locally (in sbuild *and* autopkgtest). === handsome_feng is now known as LinusBenedictTor === LinusBenedictTor is now known as handsome_feng [04:20] tsimonq2: we need autopkgtests to pass on the infrastructure, not just by hand; I will not as a rule hint in autopkgtest regressions. However in this case there is already a hint for the previous version that just needs updated, so done - but I see 'error: Server returned status 503: Service Unavailable' in the logs, is this test trying to access a service that's blocked by the firewall? [04:21] tsimonq2: and actually when I say 'done' I mean infinity did it [05:00] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-51.54~16.04.1] (kernel) [05:01] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-51.54] (core, kernel) [05:02] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-51.54~16.04.1] [05:02] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-51.54] [07:24] hello, question about magnum testsuite [07:25] it is failing on s390x because probably ran in a container? doing systemctl is-active of a service inside a container is impossible [07:25] what do you propose? disabling testsuite? ignoring it on s390x? [07:25] this is blocking a lot of stuff [07:26] (or do we have real s390x machines?) [07:31] LocutusOfBorg: armhf tests also run in containers [07:33] and the magnum tests on s390x did pass with python-oslo.i18n/3.15.0-0ubuntu1, so maybe that should be added to triggers [07:34] I did all-proposed=1 [07:36] lets try again [07:39] http://autopkgtest.ubuntu.com/packages/m/magnum/artful/s390x someone tried with a bunch of triggers on 2017-04-26 08:40:37 UTC, but not python-oslo.i18n [07:53] I did it [07:53] * LocutusOfBorg probably === marcusto_ is now known as marcustomlinson_ [09:42] infinity, ndg-httpsclient please demote :) [09:44] (I did make urllib3 migrate a few minutes ago) [09:44] so, now nothing is keeping it in main anymore [09:51] LocutusOfBorg, those will sow up in reports and get done as we go [09:55] http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed [09:59] you mean there? :) [10:00] no that one tells you what will happen when the packages migrate, it is not showing on the primary one yet [10:02] how do I check if the package "can be demoted"? [10:02] ./demote-to-proposed -n ndg-httpsclient -m "foo" [10:03] lets see [10:03] oh noes :( wrong tool [10:03] there's no relevant dry-run for moving to universe other than component-mismatches [10:04] ack thanks [10:05] well, if you want,the package now should be movable to universe [10:10] doko, hi, still on VAC? I suppose you are the one who knows when pie will be enabled by default :) (wrt steghide and similar failures) [10:12] LocutusOfBorg, systemctl is-active should totally work inside containers. armhf and s390x run in two different type of containers, one is lxc the other is lxd. both are similar but lxd is slightly more strict with permissions and apparmor protection. [10:14] interesting [10:14] but why clicking retry a few times works? [10:15] totally not reproducible [10:16] because tests are flaky =) [10:16] I bet it is [10:16] People mash retry over and over again instead of looking at the failures [10:16] Therefore the tests don't get more reliable [10:18] Laney, this is completely true, but I have zero clues in debugging it further [10:18] (this is why I asked here) [10:18] I don't want flaky tests being around [10:19] It also doesn't scale to make the release team responsible for fixing bugs just because they happen to show up in an autopkgtest result :/ [10:19] giving me help doesn't mean you have to fix it :) [10:19] I don't have access to the hardware, and I don't know deeply how containers are working [10:20] ok, well all I would know how to do is run the thing on lxc on my desktop [10:20] sudo autopkgtest-build-lxc ubuntu artful; autopkgtest --shell-fail --apt-upgrade magnum -- lxc --sudo artful [10:21] then hope it fails in the same way and attack it from there [10:22] * LocutusOfBorg upgrades his autopkgtest tool [10:22] but... how do I pass "s390x" arcitecture? [10:23] oh I see [10:23] nah just run it on your host arch [10:25] but on results I don't see issues on arches not s390x [10:25] you mean some generic lxc issue [10:26] : failure: ['sudo', 'lxc-ls'] failed (exit status 1, stderr 'sudo: lxc-ls: command not found\n') [10:26] autopkgtest [12:25:44]: ERROR: testbed failure: cannot send to testbed: ['BrokenPipeError: [Errno 32] Broken pipe\n'] [10:26] it should have a strong lxc1 dependency [10:26] no, it should not. [10:26] because autopkgtest ships runners for all sorts of technologies, and one needs just any of them, not all. plus not all are available everywhere. [10:27] recommends instead of suggests? [10:34] don't think so [10:34] but if the message isn't nice enough then you could file a bug at debian [10:34] nah, not needed of course [10:35] Error: container artful is not defined [10:35] uff [10:36] any idea? http://paste.ubuntu.com/24466017/ [10:38] the output you have there indicates that the container is called autopkgtest-artful [10:39] thanks! [10:39] and it just totally reproduced for me :) [10:40] I got trapped by the .new, I thought the /dev/lxc" error was the culprit [10:47] would it be possible to get debhelper 10 in xenial proper? packages are migrating to it and backporting hwe stack is getting more tedious [10:48] Laney, Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]: /usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py:200: FutureWarning: The access_policy argument is changing its default value to Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]: access_policy) [10:48] is this related? [10:48] I don't know [10:48] you tell me :P [10:49] restarting it works, so probably it is a race condition somewhere, starting it too fast [10:50] it gets restarted many times too quickly, and goes into an error state [10:50] tjaalton: +1 from me [11:51] could someone look into why the default Ubuntu flavor does not have artful daily iso's published? [11:52] I thought this means that the iso build was successful today and yesterday: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/artful/ubuntu [11:53] oh I see it's in pending now at least http://cdimage.ubuntu.com/daily-live/ [11:55] Right, the platform-qa-jenkins jobs need to be updated. [11:57] thanks [12:01] xnox: You want to fix that? ^- [12:01] * Laney isn't in the right team [12:02] Laney, i believe this was proposed to be fixed.... by someone else already. I saw the merge proposal. [12:02] https://code.launchpad.net/~powersj/qa-jenkins-jobs/enable-artful-iso-testing/+merge/323252 [12:03] nice [12:03] morning mdeslaur, is your offer to sponsor my openssl debdiff for openssl on development release (artful) still valid ? [12:03] xnox: so fix means approve [12:03] slashd: yes, where is it? [12:03] or merge or something [12:03] mdeslaur, https://launchpadlibrarian.net/317175176/artful_openssl_lp1674399.debdiff [12:03] Laney, i need olli ries to add me to the team or something. [12:03] you are in the team [12:04] canonical-platform-qa? no i am not. [12:04] https://launchpad.net/~canonical-platform-qa-jenkins/+members#active [12:04] that one [12:04] ah -jenkins [12:04] ok i shall merge it. [12:04] and i think jenkins polls to self-update the jobs [12:05] this https://code.launchpad.net/~canonical-platform-qa/qa-jenkins-jobs/snap-channel-support/+merge/320420 got some CI stuff run on it [12:05] hm. [12:06] Laney, i'm not sure if that still works. infinity did somebody tell you something about ci bot accounts that you semi-rejected, but I probably want to own? or e.g. foundations to own? [12:06] was it platform-qa-bot? [12:06] slashd: ack, building now and will upload in a few miuntes [12:07] mdeslaur, merci beaucoup, much appreciated [12:07] xnox: do you know why it would have stopped working? [12:08] -ENOCLUE [12:09] ah well [12:11] LocutusOfBorg: what happens if you install python-osprofiler inside the container where it's failing? [12:33] how can I Laney ? do I need to install it before the autopkgtest is executed? [14:08] LocutusOfBorg: erm... you get a shell when it fails, right? [14:15] yes [14:15] I do [14:15] so, apt :P [14:15] I did install it already [14:16] but I don't know what to do next [14:16] run the test again [14:17] debian/tests/the-test-name [14:18] (in general there's a chance it requires some of the AUTOPKGTEST_* variables set, but I checked and in this case it doesn't) [14:18] ok but the test fails obviously [14:18] the problem is: systemd tries to start it many times, and makes them "failed" units [14:18] not obvious to me [14:18] I thought I wrote this above [14:18] it fails because of that missing dependency [14:19] [12:48:13] Laney, Apr 27 10:40:35 autopkgtest-lxc-bfgnic magnum-conductor[31826]: /usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py:200: FutureWarning: The access_policy argument is changing its default value to you mean this one? [14:19] make it stop trying to respawn it [14:19] so you stop getting smacked by the timer [14:28] (or pass --setup-commands 'apt -y install python-osprofiler' and re-run the whole autopkgtest) [14:31] e.g. I ran systemctl restart magnum-conductor and magnum-api, and the test is succeeding [14:32] the problem is just some race condition during startup, probably a sleep 5 at the begin of the init script would "fix" this issue (wrong fix, of course, but to make clear what I'm saying) [14:32] LocutusOfBorg, Laney - there were ordering bugs in many openstack packages, which failed when installing out of order, and the postinst doesn't wait for services to start. [14:33] I'm telling you what the fix is [14:33] they start, then fail, then restart, then succeed a lot, resulting in race which is not apperant to the naked eye, as the status command shortly after already says everything is running just fine. [14:33] with python-osprofiler it works, interesting [14:33] soooo how to fix properly? [14:33] some of the similar bugs were fixed properly in the binary package depends and postinst; some with basically doing loop wait in dep8 =/ [14:33] Add that dependency [14:33] It's not what xnox is saying [14:33] ok [14:34] Reproduce the bug and look in /var/log/magnum/... [14:34] xnox, there is already the loop wait, for 5 seconds, but a failed unit isn't restarted automatically [14:34] it's like "omg I don't know about osprofile things" [14:34] "Depends: python-magnum, magnum-common, magnum-api, magnum-conductor, python-osprofile" [14:34] There might be a separate issue with the failure handling in the systemd unit, but that's not what is causing the startup to fail here [14:34] this works then [14:35] probably wants to be in the real depends of the package [14:36] then you can give autopkgtest the .dsc file instead of the package name and it'll build it and run the tests :-) [14:36] oh indeed nice [14:37] not sure if I have to add to python-magnum magnum-common or the two magnum-api/magnum-conductor [14:37] probably the common is the best place [14:37] the python binding has no init script [14:41] where's the code that loads the config? [14:41] probably python-magnum [14:43] sil2100: the bot API key works [14:43] winning [14:44] Laney: \o/ excellent! [14:45] Laney, debian/magnum-common.postinst.in and debian/magnum-common.config.in seems to be the two parsing the config, not sure if it is the same as what you are referring to [14:48] LocutusOfBorg: nah, code within the application itself - common has a dependency to python-magnum anyway [14:48] e.g. "magnum/cmd/api.py: profiler.setup('magnum-api', CONF.host)" [14:50] did anything change in the cdimage layout and/or the download tool in question is just broken since 8th of april? ERROR:root:Failed to fetch URL 'http://cdimage.ubuntu.com/trusty/daily-live/pending/SHA256SUMS': HTTP Error 404: Not Found . Aborting! [14:52] Presumably they stopped being built because there's no more point releases coming and someone cleaned up the old dailies? [14:56] yeah, but they are still here http://cdimage.ubuntu.com/releases/trusty/release/ it looks to me like something is failing in jenkins / proxy etc. and that it fallsback to some bad urls as well. [14:56] well artful download passed so we are good. [14:56] static validation has failed though [14:57] UTAHISOException: Cannot list ./wubi.exe in /data/iso/ubuntu/artful-desktop-amd64.iso: Command '['bsdtar', '-t', '-v', '-f', '/data/iso/ubuntu/artful-desktop-amd64.iso', './wubi.exe']' returned non-zero exit status 1 [14:57] hm, but i thought we stopped shipping wubi.... [14:57] or maybe it needs a new symlink on people. [14:58] * xnox smells alphabetic ordering [15:02] thanks Laney , uploaded! [15:02] damn I forgot to give you credits :/ [15:02] sorry [15:02] weall know Laney rocks [15:03] LocutusOfBorg: np, don't forget to push to git [15:04] Laney: \m/ [15:05] \m/ >_< \m/ [15:06] thanks done [15:07] Laney, this is to fix static validation job, which blocks smoketest jobs https://code.launchpad.net/~xnox/utah/skip-wubi-more/+merge/323328 [15:07] trusty's the only wubi thing left? [15:07] i think so. [15:08] out of the ones that we test in the jenkins. [15:08] looks like you need these people https://launchpad.net/~canonical-ci-engineering/+members#active [15:08] fginther, ^ please review utah fix [15:08] not sure if platform jenkins auto picks up things from lp:utah [15:08] Laney, can I expect the same fix to apply to openstack-trove and murano? [15:09] LocutusOfBorg: don't know [15:09] lets see the publisher, testsuite rerun and then I'll try to see [15:09] thanks for the help, now I have some more tools to debug [15:10] Run the test, check what systemd says when the job fails to start [15:10] run things by hand, see what they print, check log output, etc [15:10] btw with mapreri we were talking about some improvements, e.g. when somebody clicks "retry" to a test, the status on excuses isn't set back to "running" [15:10] so people click lots of times [15:10] same test run should be not allowed, so clicking twice a link should result in only one test run [15:11] the autopkg page e.g. http://autopkgtest.ubuntu.com/packages/g/gnocchi/artful/s390x should have probably some "all-proposed" column [15:11] and a line saying "something is already running there, right now, waiting for result" [15:11] *blink* [15:12] this would save some time to builders, due to useless retries [15:12] I know updating excuses is not easily feasible, so I was more thinking about having autopkgtest.u.c/packages/... pages having a note whether packages are being tested or in the queue. [15:12] The queue isn't inspectable as it stands [15:21] sad! [15:23] Well [15:23] /running/ could be split out into a script that makes some json or so [15:23] and then /running/ and /packages/ and /request.cgi could all look at that [15:36] Laney, i thought running is actually static json is it not ? [15:36] i am sure i inspect that, it is however delayed and periodic [15:37] apw: the logtail bit, but not the queue bit [15:48] Laney, isn't that in the json as well ... hrm [15:48] * apw suggests ignoring apw as he is likely less well informed than Laney [15:50] apw: see webcontrol/request.cgi running() [15:50] * Laney wants a release/tools sprint to have some clear time to work on all this stuff [15:51] Laney: I need to plan that. [15:54] infinity: That'd be peachy [15:55] .49 [15:55] oops [15:55] subscribe [15:55] Almost half way there [15:55] living on a prayer [16:01] did someone change the c-m report emails? I'm now getting email notifications about demotions, which I know I wasn't before [16:01] (so is that someone changing the code, or is it snakefruit fallout?) [16:03] tjaalton: For which release did you verify bug 1676845? [16:03] bug 1676845 in vlc (Ubuntu Yakkety) "libgles1-mesa is being removed, don't depend on it" [Undecided,New] https://launchpad.net/bugs/1676845 [16:08] slangasek: I didn't change it. I also have a hard time seeing how it would be fallout from the upgrade, though. [16:09] slangasek, i believe this has always been the case..... [16:09] slangasek: I confess that I don't read the mail often enough to know for sure if this is "usual". [16:09] slangasek, it would be nice to change FROM: address such that i don't get sad, each time i get notification of email with pitti's face [16:09] slangasek: But I *think* it used to tell me about demotions (though, annoyingly, it claims it's a promotion, because derpy code) [16:14] in 20 [16:29] bdmurray: xenial [17:37] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1~16.04.1 => 0.7.9-113-g513e99e0-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server) [17:43] -queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1~16.10.1 => 0.7.9-113-g513e99e0-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server) [18:15] anyone know why rednotebook is no longer in the official repo? [18:16] for zesty to be more specific [18:17] max100: it is. [18:17] oh, no it's not [18:17] sorry, packages.ubuntu.com tricked me [18:18] "Depends on obsolete python-webkit; removed from Debian testing (Debian bug #749259); LP: #1677048" [18:18] Debian bug 749259 in rednotebook "rednotebook: depends on python-webkit which is deprecated" [Serious,Open] http://bugs.debian.org/749259 [18:18] Launchpad bug 1677048 in pywebkitgtk (Debian) "Please remove pywebkitgtk from Ubuntu" [Unknown,New] https://launchpad.net/bugs/1677048 [18:23] -queuebot:#ubuntu-release- New: accepted php7.1 [sync] (artful-proposed) [7.1.4-2] [18:27] bdmurray: I would appreciate queue review of software-properties/yakkety-proposed; and apologies for the synciness, had to be binary copied from security-proposed ppa [18:27] -queuebot:#ubuntu-release- Unapproved: pcs (xenial-proposed/universe) [0.9.149-1ubuntu1 => 0.9.149-1ubuntu1.1] (no packageset) [18:28] silly silly syncs [18:30] -queuebot:#ubuntu-release- New sync: freebayes (artful-proposed/primary) [1.0.2-1] [18:33] slangasek: I don't see that package in the security PPA anymore. https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa [18:36] bdmurray: yes, tyhicks said he removed it from there [18:36] hmm [18:37] does that break things when it's deleted from source ppa before released from unapproved? [18:37] this is ringing a bell :P [18:37] well, in this case it's still retrievable from the queue so maybe we're ok [18:38] slangasek: where would I get the package to review the diff if its not in the PPA? === stgraber_ is now known as stgraber [18:41] bdmurray: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages?field.name_filter=software-properties&field.status_filter=&field.series_filter= [18:42] bdmurray: It's still not garbage-collected. [18:42] bdmurray: Which means queue can find it, and the copy will succeed. But for a limited time. :P [18:45] slangasek: looks fine to me although a test case is missing [18:47] lol checking [18:47] Should I try accepting it via sru-review? [18:48] bdmurray: should work as long as you --no-diff [18:50] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [sync] (yakkety-proposed) [0.96.24.7.2] [18:56] -queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.1] [19:02] bdmurray: test case added if you want to give that eyeballs [19:05] slangasek: sure, why did it go through the security ppa? because it'll end up in -security? [19:05] bdmurray: yes - since per our discussion I understand unattended-upgrades only pulls new packages in from -security, not from -updates [19:06] (new dependencies) [19:06] Err, no. [19:06] only pulls in new dependencies (from anywhere) when the update comes from -security [19:06] infinity: unattended-upgrades, not update-manager [19:06] By default, unattended-upgrades only upgrades from security. [19:07] New deps, however, can happen in any pocket you've configured it to look at. [19:07] Which is, by default, release and security, but if you ask it to update updates, that'll work fine too. [19:07] slangasek: Yes, I can read. :) [19:08] See Unattended-Upgrade::Allowed-Origins [19:08] The bug that was fixed there was that we used to not allow the release pocket, so new deps added would not work unless they were also in the allowed pocket. [19:09] ah [19:09] Now, we default to allowing release and security. But if you've configured unattended-updates to do updates, it'll obviously do that too. [19:09] bug 1624641 is the change I'm thinking of [19:09] bug 1624641 in unattended-upgrades (Ubuntu Yakkety) "security updates with a new dependency don't get installed" [High,Fix released] https://launchpad.net/bugs/1624641 [19:09] bdmurray: Yeahp, that's the one I'm describing above. [19:09] infinity: so, if this is not actually a security update, there should be no need to put it into security pocket to get the behavior we want [19:09] slangasek: Right. [19:10] we can just put it in -updates, and people will get it when they apply updates, whether that's unattended-upgrades or update-manager or feta [19:10] "Hello Vague" [19:10] slangasek: Unless you believe it's something users of the security pocket should just want, regardless, which can be argued for functional updates sometimes, when they have a positive impact on future security updates. [19:11] But if you feel that, I'll let you talk it out with the security czars. :) [19:11] infinity: ok. so when all is said and done, doing this in the security ppa was pointless but not harmful; and we can publish it to -updates only (along with binary copies of the perl deps which need promoting to main) [19:11] I don't see a reason this needs to be pushed out to security, no [19:11] * infinity nods. [19:11] * slangasek puts a pin in his brain to remember this for next time [19:12] https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1672424/comments/21 ftw [19:12] Ubuntu bug 1672424 in gnome-software (Ubuntu Zesty) "Cannot install Debian files outside of the repositories" [Critical,Fix committed] [19:14] Okay, I'm on the same page too now. [19:15] slangasek / infinity: however the fix for bug 1681231 we want to go into -security because people upgrading may not -updates enabled correct? [19:15] bug 1681231 in cracklib2 (Ubuntu Zesty) "package cracklib-runtime 2.9.2-3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Triaged] https://launchpad.net/bugs/1681231 [19:15] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-90-g61eb03fe-0ubuntu1 => 0.7.9-113-g513e99e0-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server) [19:17] bdmurray: Possibly, yes. [19:18] bdmurray: And following up from the above, https://launchpad.net/ubuntu/+source/unattended-upgrades/0.90ubuntu0.1 should have gone to security too, since its intent was to fix security updates. :P [19:19] (I mean, it fixed both security and updates, but security was the trigger for the bug) [19:20] infinity: oh that's great. is that u-u issue fixable now? [19:20] The part where people seemed to stop caring after the update hit -updates is another indication that there are probably very few users who actually run security-only. [19:23] bdmurray: u-u has no compiled binaries, and no versioned deps, so it might be worth a quick chat with security about if they just want the current SRUs copied wholesale to the security pocket. It should be safe to do so. [19:24] bdmurray: Or, more conservatively, we could copy the ones that just added the release pocket bit, which would be very safe. [19:24] mdeslaur: Come have an opinion. [19:27] yeah, we could copy it over [19:27] yakkety's 0.92ubuntu1.1 too [19:28] mdeslaur: I proposed https://launchpad.net/ubuntu/+source/unattended-upgrades/0.92ubuntu1.1 for yakkety and https://launchpad.net/ubuntu/+source/unattended-upgrades/0.90ubuntu0.1 for xenial as minimal impact. There are later SRUs, but they aren't about this thing. [19:28] mdeslaur: If that's cool with you, I'll do the copies right now. [19:28] infinity: sure, if there are no binaries, etc...you can just copy it over [19:28] infinity: yep, cool [19:30] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-security/main) [0.92ubuntu1.3 => 0.92ubuntu1.1] (desktop-core, ubuntu-server) (sync) [19:30] 0.92ubuntu1.3 => 0.92ubuntu1.1 ... Really? [19:30] Well job, queuebot. [19:30] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-security/main) [0.90ubuntu0.4 => 0.90ubuntu0.1] (desktop-core, ubuntu-server) (sync) [19:32] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (xenial-security) [0.90ubuntu0.1] [19:32] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [sync] (yakkety-security) [0.92ubuntu1.1] [19:34] mdeslaur, bdmurray: ^--- Both done. [19:35] thanks [19:35] mdeslaur: Though, again, as I said, the fact that no one complains when we miss things like this really makes me wonder if "security-only" users are a myth. [19:36] I think if I had a time machine, I'd just scrap the concept and have one post-release updates pocket. [19:36] Especially given that we also decided somewhere along the way to pull SRUs into security over time. [19:36] infinity: your queuebot has been replaced by Q*bert, HTH [19:38] infinity: ack, thanks [19:38] right, now I've got a fancy test case but no yakkety install to run it on. What's the fastest way nowadays to go from zero to installed yakkety desktop in a VM? [19:39] slangasek: Download an ISO? [19:39] tedious [19:39] slangasek: Assuming you want a real desktop, not just a chroot to piss around in. [19:39] I have to install it! [19:39] infinity: it would be nice to kill it....we've gotten perhaps 2 or 3 bugs about something not working for -security only users in the past [19:39] heh, i've often resorted to iso and virt-manager. Then make a copy of the image [19:39] infinity: maybe we can discuss killing it before the next lts [19:40] infinity: needs to be a desktop, I need to run Software & Updates [19:40] oh technically I don't need to install, do I, I could just do this from the livecd [19:40] infinity: you're a genius, thanks [19:40] slangasek: Yeah, then "dd if=/dev/zero of=disk.img bs=10M count=2000 conv=sparse && kvm -m 2G -hda disk.img -cdrom yakkety-desktop.iso" and wait around a bit? :P [19:41] slangasek: Oh, or from the livecd, if it's testable in the live env. [19:42] mdeslaur: It'd be an interesting discussion to have, but it might just be one of those things we're stuck with at this point. [19:43] mdeslaur: Also, the (now default) "only install security updates automatically, but let me install other updates manually" thing is divided across pockets, since that's easy, it would require a rethink if we killed the security pocket. Like somehow tagging packages with security fixes in Packages or some out-of-band source that apt and friends consume. [19:44] mdeslaur: Which is actually sort of a cool concept, but work. And we all love work. [19:45] hrm, and some of those may require other packages that weren't tagges as security [19:45] yeah, ok, it's a bit more complicated than I thoght [19:45] wow, I can't type today [19:46] Well, that's not really a problem. If you tell apt to install foo and bar because they're security updates, it'll happily pull baz as an extra dep even if it's not. [19:46] But yeah. It's not trivial to remove the security pocket and still have a concept of "this upload contains a security fix" in a way that automated tools can consume. [19:47] you're assuming that all the required dependencies actually got bumped manually or automatically [19:47] The most naive implementation would be a "Security-Updates: CVE-1234 LP1234 BTS1234" header, and if it exists, we act on it. [19:47] no? [19:47] mdeslaur: Hrm? I don't follow. [19:48] if the nss security update was built with a newer nspr from -updates, but nobody added a explicit version bump, or the symbols file didn't change... [19:48] mdeslaur: If you apt-get update and there are 34 updates, but 5 have a Security-Update header, apt-security (or whatever) marks those 5 for install, and then attempts an install, which will automatically resolve if two more packages are also needed, despite not having the header. [19:49] then installing the nss security update wouldn't automatically pull in the newer nspr [19:49] mdeslaur: Then that's a bug. Period. [19:49] yeah, but it happens _all the time_ [19:49] mdeslaur: That same bug could exist in any SRU, and shouldn't. [19:49] Also, if there's a symbols file, there shouldn't be a bug. [19:50] But I'll assume you meant that there wasn't one. [19:50] Or, I guess, that it has the wrong versions, because someone's using dpkg-gensymbols in slacker mode. [19:50] Now *that's* something I'd like to stamp out. [19:50] happens all the time, ie: debian bug 820565 [19:50] Debian bug 820565 in src:nspr "nspr: bump minimum PR_*printf version in .symbols to 4.10.9" [Wishlist,Fixed] http://bugs.debian.org/820565 [19:51] How is that wishlist? [19:52] mdeslaur: But yes, point made. It's an issue. I don't really see it as an issue that affects security any more than other SRUs except that we'd be trying to cherry-pick security updaes, which might magnify it. [19:53] mdeslaur: Anyhow, all totally a hypothetical, since I think if we float "hey, let's kill the security pocket and redesign this mess", all of us who aren't super keen on doing a ton of work for a potentially minimal gain will opt for beer instead. [19:53] right, automatically installing security update would probably trigger it a lot more...for SRUs, people are probably just installing all updates, so it doesn't happen frequently [19:53] oh, beer *drool* [19:53] See? [19:53] what were we talking about? oh right, beer. [19:54] * sbeattie works on an emrgency beer update [19:58] * apw wonders why he is being highlighted repeatedly, oh beer [19:59] Hah. [19:59] :) [20:01] apw: such a better choice then me being highlighted for security... [20:06] -queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.2 => 20160930-0ubuntu6~14.04.0] (ubuntu-cloud) [20:11] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu3 => 2.02~beta3-4ubuntu3] (core) [20:23] slangasek: line 8 of the test case in bug 1679784 talks about using update-manager but that'd install all of -proposed. I usually just recommend using apt and installing the specific packages. [20:23] bug 1679784 in software-properties (Ubuntu Xenial) "Changing from Xorg video driver to NVIDIA driver using Software & Updates does not display debconf prompt" [Critical,Confirmed] https://launchpad.net/bugs/1679784 [20:28] bdmurray: yes, I'm asking for update-manager specifically because I want to confirm correctness of behavior w/ u-m [20:29] slangasek: okay. could you replace yakkety with zesty in sru-review? [20:32] bdmurray: done [20:32] caribou: Do you have an upstream PR for the fix for bug 1654600? [20:32] bug 1654600 in unattended-upgrades (Ubuntu Zesty) "unattended-upgrade-shutdown hangs when /var is a separate filesystem" [High,In progress] https://launchpad.net/bugs/1654600 [20:41] bdmurray: fwiw I'm self-verifying this one in a VM, so if u-m + -proposed does eat the VM afterwards I don't care ;) [20:43] slangasek: I just like to pretend that people other than us developers do verifications. [20:44] dream a little dream, bdmurray [20:44] Me as a lowly user, just break things :) [20:44] slangasek: Ack, thanks. [20:45] nacc: lol [20:51] -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu3 => 2.02~beta3-4ubuntu3] (core) [20:53] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (zesty-proposed) [0.93.1ubuntu2.1] === jdstrand_ is now known as jdstrand [21:38] bdmurray: I replied on LP: #1685803 [21:38] Launchpad bug 1685803 in gnome-calendar (Ubuntu Zesty) "Update gnome-calendar to 3.24.1" [High,In progress] https://launchpad.net/bugs/1685803 [21:39] jbicha: okay, in a meeting [21:57] could someone please review my grub2 upload in the artful queue? [22:03] bdmurray: I notice binutils seems to not be making it to yakkety-updates, presumably because of the failing linux autopkgtests; but the linux autopkgtests are flaky. Would you mind looking at whether that's releasable? [22:04] slangasek: systemd too then? [22:04] it also is blocked by linux autopkgtests === wxl_ is now known as wxl === fossfreedom_ is now known as help === help is now known as Guest30781 === Guest30781 is now known as fossfreedom [22:23] -queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (zesty-proposed) [3.24.1-0ubuntu0.1] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-context [source] (zesty-proposed) [1.1-1ubuntu9] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-github-mattn-go-colorable [source] (zesty-proposed) [0.0.6-1ubuntu6] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-github-pborman-uuid [source] (zesty-proposed) [0.0+git20150824.0.cccd189-1ubuntu8] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-flosch-pongo2.v3 [source] (zesty-proposed) [3.0+git20141028.0.5e81b81-0ubuntu8] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-goprotobuf [source] (zesty-proposed) [0.0~git20161116.0.224aaba-3ubuntu2] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-x-text [source] (zesty-proposed) [0.0~git20161013.0.c745997-2ubuntu2] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-github-gosexy-gettext [source] (zesty-proposed) [0~git20130221-0ubuntu13] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-gocapability-dev [source] (zesty-proposed) [0.0~git20150716.0.2c00dae-1ubuntu8] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-petname [source] (zesty-proposed) [2.6-0ubuntu2] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-github-olekukonko-tablewriter [source] (zesty-proposed) [0.0~git20151029.0.a5eefc2-1ubuntu7] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-yaml.v2 [source] (zesty-proposed) [0.0+git20170125.0.4c78c97-0ubuntu2] [22:25] -queuebot:#ubuntu-release- Unapproved: rejected golang-gopkg-lxc-go-lxc.v2 [source] (zesty-proposed) [0.0~git20161126.1.82a07a6-0ubuntu4] [22:36] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.4] [22:38] bdmurray: likely :) [22:38] bdmurray: thanks [22:40] slangasek: I'm confused about "3. Install binutils and gcc-5 from -proposed." in bug 1623418 as the gcc-5 tasks are New [22:40] bug 1623418 in gcc-5 (Ubuntu Xenial) "gcc-as-needed.diff patch broke mpx support in GCC" [Medium,New] https://launchpad.net/bugs/1623418 [22:42] bdmurray: ah. I don't have more details; perhaps the v-done tag should be removed? [22:43] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.5] [22:44] bdmurray: fwiw I've confirmed that the packages /show up/ correctly in update-manager, though the actual install on top of 16.10 ISO wants to pull down 461.3MB... so I think I'll verify that I don't get any errors calculating the upgrade, then abort and install by hand [22:44] oops, I did get an error, 'not enough free space' on the livecd [22:45] bdmurray: do you think the above is close enough, or should I go through the trouble of installing off of the CD? [22:46] slangasek: that's the software-properties bug? [22:46] yes [22:47] I've a VM that I could do that with that won't run out of space. [22:47] ok, up to you [22:48] I also just realized I could unselect packages in u-m :P [22:48] That would be better [22:49] ok, rebooting and trying that [22:49] I think there's even a select all and select none [22:50] slangasek: Oh hey, how does bug 1389582 fit into this? [22:50] bug 1389582 in software-center (Ubuntu) "software-center misses a dependency on libgtk2-perl" [High,Triaged] https://launchpad.net/bugs/1389582 [22:50] uh... probably fits in somewhere :P [22:59] bdmurray: this is proving more difficult than expected; the VM is refusing to boot back to ubiquity >_< [23:00] bdmurray, infinity: lib{gtk,cairo,glib,pango}-perl copied to {trusty,xenial,yakkety}-updates and promoted to main, though [23:00] ah, there's a splash screen [23:14] bdmurray: v-done \o/ [23:16] suppose I should prep the SRU for trusty+xenial also [23:16] keep the momentum! [23:26] -queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.6 => 0.96.20.7] (desktop-core, ubuntu-server) [23:26] * nacc uploads php-defaults to switch default php to 7.1 [23:27] slangasek: i also uploaded some changes to remove explicit dependencies on src:php7.0 binaries rather than the ones from php-defaults [23:28] * slangasek nods [23:28] fixing two b-d on php7.0 and then i think we'll be able to demote and remove src:php7.0 [23:29] i synced with ondrej on this too, so we're not diverging from debian in any signficant way [23:30] -queuebot:#ubuntu-release- Unapproved: software-properties (trusty-proposed/main) [0.92.37.7 => 0.92.37.8] (kubuntu, ubuntu-desktop, ubuntu-server) [23:31] -queuebot:#ubuntu-release- Unapproved: accepted php7.0 [source] (zesty-proposed) [7.0.18-0ubuntu0.17.04.1] [23:38] cyphermox: reviewing grub2 in unapproved mostly for the uefi-signed aspect rather than the code aspect, but just checking on the way through, is the Signed-off-by in debian/patches/grub-install-extra-removable.patch still accurate? [23:41] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu3] [23:41] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu3] [23:51]