[00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [amd64] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [armhf] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [powerpc] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [s390x] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [arm64] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu1] [00:04] -queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [i386] (yakkety-proposed) [16.04.3-0ubuntu1] [00:06] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.0.0-0ubuntu1] [00:08] -queuebot:#ubuntu-release- Unapproved: ubiquity (yakkety-proposed/main) [16.10.12 => 16.10.13] (core) [00:10] -queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.2 => 1.21.3] (core) (sync) [00:10] -queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905.is.0.8-0ubuntu2 => 0.9+1465500757.14a5905.is.0.8-0ubuntu3] (core) (sync) [00:12] I retried the libreoffice autopkg test triggered by gcc-6, but this looks unrelated to gcc-6. Please could you override it? [00:12] pitti: ^^^ [00:13] -queuebot:#ubuntu-release- Unapproved: accepted foomatic-db [sync] (yakkety-proposed) [20161005-1] [00:19] cyphermox: the above shim been tested for the MokManager case? [00:20] err, no, woops [00:20] * doko_ curses all these new kde binaries just a few days before release ... [00:20] cyphermox: can you test that, so we know for sure before round-tripping all the way to the release? :) [00:21] yeah [00:21] it's trivial to test [00:23] doko_: it all comes down to lack of developers and Qt 5.6.1 being such a mess [00:23] * cyphermox goes offline for a bit to test this [00:23] doko_: now that we have another Kubuntu Developer (congrats clivejo!) things will get easier [00:24] doko_: but yes, we're cursing them too :P [00:24] * tsimonq2 has Kubuntu hat on [00:27] syq_: please see the update to #835851. can you do this backport? [00:27] oops, wrong channel [00:28] * doko_ is revealing the super secret Ubuntu mips port ... [00:29] *finally* [00:29] .. maybe we can get ubnt to run on ubuntu? :) [00:29] -queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (yakkety-proposed) [1:3.0.0-0ubuntu1] [00:36] -queuebot:#ubuntu-release- Unapproved: xubuntu-default-settings (yakkety-proposed/universe) [16.10.2 => 16.10.3] (xubuntu) [00:37] pitti, the above corrects the backlight slowness in xubuntu [00:44] doko_: I'll take the curses if we get a working packageset for release [00:45] the calendar is never our friend, unfortunately [00:45] * valorie puts on the flame-proof underwear [00:48] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (yakkety-proposed) [3.0.0-0ubuntu1] [00:48] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (yakkety-proposed) [2:13.0.0-0ubuntu1] [00:50] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (yakkety-proposed) [16.10.8] [00:50] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-default-settings [source] (yakkety-proposed) [16.10.3] [00:52] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (yakkety-proposed) [1:3.0.0-0ubuntu1] [00:55] hmmmm I wonder what machines actually run mips... [00:59] slangasek: now it is tested, mokmanager loads succesfully, and of course the booting works, etc. [00:59] -queuebot:#ubuntu-release- Unapproved: accepted python-tooz [source] (yakkety-proposed) [1.43.0-0ubuntu1] [01:14] -queuebot:#ubuntu-release- New binary: kdepim-addons [amd64] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset) [01:14] -queuebot:#ubuntu-release- New binary: kdepim-addons [ppc64el] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset) [01:15] oh my, we'll probably have the signed new shim tomorrow. [01:16] -queuebot:#ubuntu-release- New binary: kdepim-addons [i386] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset) [01:16] cyphermox: still better than the alternative :) [01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [amd64] (yakkety-proposed) [16.04.3-1ubuntu1] [01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [ppc64el] (yakkety-proposed) [16.04.3-1ubuntu1] [01:16] -queuebot:#ubuntu-release- New: accepted kdepim-addons [i386] (yakkety-proposed) [16.04.3-1ubuntu1] [01:16] -queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.0-0ubuntu1] [01:16] slangasek: having the new tomorrow signed on shim? [01:17] no, that's the converse [01:17] -queuebot:#ubuntu-release- New binary: kdepim-addons [s390x] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset) [01:17] -queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (yakkety-proposed) [4:16.04.3-0ubuntu2] [01:17] -queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (yakkety-proposed) [1:6.2.1-0ubuntu1] [01:17] -queuebot:#ubuntu-release- Unapproved: accepted manila [source] (yakkety-proposed) [1:3.0.0-0ubuntu1] [01:17] -queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1] [01:17] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (yakkety-proposed) [2:9.0.0-0ubuntu1] [01:18] -queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.0-0ubuntu1] [01:18] -queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (yakkety-proposed) [1:9.0.0-0ubuntu1] [01:18] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0~rc2-0ubuntu3] [01:18] the alternative is shim.efi -> /etc/alternatives/shim.efi -> /usr/share/.rootkitz/nsa.efi [01:18] -queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.0-0ubuntu1] [01:18] -queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (yakkety-proposed) [2:9.0.0-0ubuntu1] [01:18] -queuebot:#ubuntu-release- New binary: kdepim-addons [powerpc] (yakkety-proposed/universe) [16.04.3-1ubuntu1] (no packageset) [01:18] ah, someone batch-accepting? [01:18] shh, can't tell people. [01:18] (about the nsa.efi file, i mean) [01:24] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.16+16.10ubuntu1] [01:25] infinity: were those your accepts above? any reason raspi2 not also accepted? [01:26] seems snapdragon went in and raspi2 not, though they have the same rationale from apw [01:30] slangasek: snapdragon was a simple review, raspi2 needs a bit more time, but it's happening tonight too. [01:31] slangasek: (the former was a copy forward of an SRU, the latter is a last-minute rebase from 4.4 to 4.8...) [01:35] ok [01:36] -queuebot:#ubuntu-release- Unapproved: accepted policykit-1 [source] (yakkety-proposed) [0.105-16git1] [01:39] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1465500757.14a5905.is.0.8-0ubuntu3] [01:40] cyphermox: shred -n 1000000000 -z nsa.efi && debuild -S -sa && dput ../*source.changes [01:40] lol [01:42] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (yakkety-proposed) [1.21.3] [01:43] infinity: ^^ that should /not/ need a new d-i upload to pick up for the images, since AFAIK the bits we put on the CD do not include MokManager and the actual shim binary used for CD boot is unchanged [01:44] slangasek: Kay. We may need a new d-i for other reasons later anyway, but won't do one for that. [01:47] -queuebot:#ubuntu-release- New: accepted kdepim-addons [powerpc] (yakkety-proposed) [16.04.3-1ubuntu1] [01:47] -queuebot:#ubuntu-release- New: accepted kdepim-addons [s390x] (yakkety-proposed) [16.04.3-1ubuntu1] [01:57] oh, indeed it wouldn't [01:57] that's good I guess [02:02] -queuebot:#ubuntu-release- Unapproved: xubuntu-docs (yakkety-proposed/universe) [16.04.4 => 16.10] (xubuntu) [02:05] ^ Finally got our yakkety docs uploaded [02:20] g'night [02:20] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (yakkety-proposed) [16.10.13] [02:20] -queuebot:#ubuntu-release- Unapproved: accepted xubuntu-docs [source] (yakkety-proposed) [16.10] [02:36] slangasek: are you still up? [04:23] -queuebot:#ubuntu-release- Unapproved: gnome-photos (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra, ubuntugnome) [04:49] santa_: certainly ;) [04:50] slangasek, the man who never sleeps [04:51] well not at 10pm anyway [04:52] ah, that's my tz too [04:59] infinity: why does binutils autopkgtest run now take 2-3x as long on amd64, beginning with the latest glibc upload? [05:03] slangasek: I wanted to ask you about our next steps with kde packages, we are now in the final freeze, aren't we? [05:03] doko_: will have a look [05:03] bluesabre: hm, the polkit change already should fix the backlight? [05:03] pitti: I just sorted gcc-6 hinting [05:03] santa_: next steps are, do whatever it takes to get these packages into a releasable state [05:04] santa_: I just retried the akonadi arm64 build, hopefully that was a random failure rather than a bug [05:04] slangasek: allright, so we will continue to work on autopkgtest failures to get the things accepted by britney, right? [05:04] santa_: yes [05:05] slangasek: excellent, I have a fix for kwin, if you are willing to sponsor I will prepare a dsc [05:05] santa_: please post the link, and if I don't get to it before I drop off, someone in a more European timezone can [05:06] allright [05:06] slangasek: regarding akonadi I think it's a race condition when building with -j4, I dind't have time to do a proper research of that, but I think a rebuild will fix it [05:08] santa_: ah, so a missing dependency declaration somewhere for a generated header [05:09] santa_: kpimtextedit's autopkgtest also appears racy [05:09] at least on i386 [05:09] slangasek: the akonadi thing - I think it's a problem in the cmake stuff [05:09] slangasek: your snapd/ppc64el hint doesn't work; I'll have a look, maybe britney stumbles over the + [05:09] probable the cmake file for the tests needs adjusting [05:10] pitti: the previous hint worked, I *just* updated the version for the new snapd [05:10] that header is generated automatically by something [05:10] slangasek: oh, missed the UTC-7, ok :) [05:10] but I think it's not completely guaranteed that that something happens before the buid of the test [05:11] slangasek: regarding th current state given by the status page, there are some things stuck on plasma-framework, for instance http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kdeclarative [05:11] so pressing the update button would help I think [05:11] hi! I didn't get e-mail about this rejection, could someone fetch the reason? https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=qtbase - just interested if deemed unsuitable for SRU or something wrong in the preparation [05:12] Mirv: the reason isn't stored anywhere [05:13] ok, I did search all my mailbox and trash though. and not also the rejecter is stored? [05:13] Mirv: AFAIK it is not [05:13] ok, let's see if someone notices and remebers then [05:15] I can see that maybe the code change feels a bit too big with regression potential somewhere despite the unit tests [05:16] santa_: I've retried the plasma-framework tests, but they failed pretty consistently across amd64/i386/ppc64el while passing on armhf; this may require harder hinting, pitti should be able to help with that later if it remains an issue [05:16] Mirv: in practice, I think only me, i_nfinity, s_langasek, L_aney, and a_pw review unapproved (and you just ruled out two); shouldn't be too hard to find out [05:16] hm, juju's tests have been failing for a while :( [05:17] pitti: for xenial, bdmurray and rbasak were certainly doing some SRU processing this week [05:17] oh, was that SRU, sorry [05:17] yeah [05:18] Mirv: oh, that actually could have been me [05:18] I remember that I rejected one sync where the origin PPA already got removed [05:19] so there was no way to review teh package, and I'm not even sure if that actually works (syncing from a removed PPA) [05:19] ah, we have a hint for juju-core too :( [05:20] pitti: no, the PPA is still there https://bileto.ubuntu.com/#/ticket/1964 [05:21] pitti: oh, robru! why does he say he finalized it by mistake, even though the silo is actually there. [05:21] Mirv: check the queue item -- clicking on sync leads to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/1964-deletedppa [05:21] but that robru's comment was actually days later regardless [05:21] Mirv: hm, odd -- that's not what the +queue page leads to [05:21] pitti: oh.. so robru deleted the PPA then restored it and rebuilt the binary. right, and the "When" in queue is actually when I uploaded, not when rejected [05:22] Mirv: ok, that makes sense [05:22] so you just need to re-sync I figure [05:22] Mirv: same binary. I bincopied it before the ppa was fully removed [05:23] robru: oh, ok. but it seems the PPA has different internal id despite the same name so the sync wasn't functional anymore. [05:23] Mirv: interesting to learn that upload queues follow the ppa entity rather than just going by name, which matched [05:23] Yeah [05:24] Mirv: sorry again, i was testing code that prevents finalizing queued uploads and it failed, doh [05:24] ok, now it's in the queue again, let's see about its true fate later :) [05:24] -queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.1 => 5.5.1+dfsg-16ubuntu7.2] (kubuntu, qt5, ubuntu-desktop) (sync) [05:24] robru: hah! :) no worries. [05:25] santa_: akonadi/arm64 looks better this time [05:27] slangasek: great, here's the proposed fix for kwin http://gpul.grupos.udc.es/sponsor/kwin_5.7.5-0ubuntu2.dsc [05:28] \o/ [05:28] I had to disable 1 test, just one. I tried so hard but I couldn't figure out a proper environment to get it built [05:29] I checked upstream code 5.8 but it seems the tests changed so much, so I guess we will drop the patch disabling that test for the next version [05:30] santa_: how has this change been tested ? I would not expect 'xvfb-run -a kwin' + 'xvfb-run -a dbus-launch' to put the processes on the same X server [05:32] slangasek: trial/error with adt-run [05:32] hmm [05:33] I tried various things and got less and less tests failing [05:33] I don't think the 'xvfb-run -a kwin &' bit does anything for you [05:33] that should spawn a completely separate X server than what's used for dh_auto_test [05:34] maybe it's unneed, I can recheck [05:34] and, I would be concerned about the possibility that on the autopkgtest testbed, this would lead to test timeouts because of dangling processes left behind [05:35] (so, it wouldn't be harmless) === cpaelzer_ is now known as cpaelzer [05:37] the testbeds don't care about dangling processes, just the buildds do [05:38] but starting two different xvfb-runs indeed doesn't make sense [05:39] pitti: if they don't care, then I can upload this as-is and let santa_ fix the extra process at leisure [05:39] -queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.4 => 2.10.95-0ubuntu2.5] (core) [05:39] I'm testing without the kwin exec btw [05:40] -queuebot:#ubuntu-release- Unapproved: kwin (yakkety-proposed/universe) [4:5.7.5-0ubuntu1 => 4:5.7.5-0ubuntu2] (kubuntu) [05:42] slangasek: another case, I mentioned earlier in this channel that libkscreen autopkgtest is working properly here locally http://gpul.grupos.udc.es/things/libkscreen_5.7.5-0ubuntu1_adt.log [05:42] any idea about this one? [05:43] santa_: do you actually test with a qemu testbed? [05:44] the "cannot connect to wayland" and "segfault" errors don't sound particularly specific to the scalingstack test env [05:44] pitti: I'm using lxc [05:44] but I can test with qemu too [05:45] * pitti runs it here for fun too [05:45] santa_: where should the wayland server come from within the tests? [05:46] maybe the tests work for you in lxc because you have a wayland server running already and the socket is exposed in the container? [05:46] but, for instance, xvfb-run won't provide you a wayland server - so my guess is the wayland tests need to be run separately or not at all (depending on whether there's a reliable wayland equivalent to xvfb-run) [05:47] -queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (yakkety-proposed) [4:5.7.5-0ubuntu2] [05:49] slangasek: I'm using an lxc container created with adt-build-lxc, so I doubt I already have a wayland server running there [05:49] but you may have one in the host which shows through? or, there may be one started within the container but it relies on getting access to real graphics hardware [05:51] I doubt it, but as I said I can re-test anything with qemu [05:51] I stoped using it because there was a concrete package I coudn't get working [05:51] no because of the package but because qemu timeouted or something like that [05:53] libkscreen also works here in qemu; so some kind of race condition [05:53] so, push the retry button? [05:55] it fails consistently on the infra, that won't work [05:55] ugh [05:55] so override it? [06:01] for now, I'd say yes, bump the override [06:02] done [06:02] * pitti bumps kwin too [06:05] pitti: why does the neutron/s390x failure get an ignore? openstack is expected to work on s390x, and it seems like the test works /most/ of the time [06:07] it stopped working reliably in August already [06:07] and now fails consistnetly [06:08] I mean, I can unbump the version and leave that one stuck, but I don't think that's going to suddenly raise an interest now :/ [06:08] (and it also regularly blocks a lot of rdeps) [06:09] pitti: "fails consistently" for the past 5 runs, but magically worked between 20-9 and 5-10 :) [06:10] pitti: I think we need some forcing factor here to make sure those tests are cared for; maybe a critical bug against the openstack packages when this happens [06:11] ok; IRC pings aren't forceful enough I guess :) [06:11] I'll file a bug [06:14] bug 1631260 [06:14] bug 1631260 in neutron (Ubuntu) "autopkgtest fails on s390x: neutron-server.service failed to start" [Undecided,New] https://launchpad.net/bugs/1631260 [06:16] slangasek: re: binutils autopkgtest, I have no idea, but having a very hard time seeing how glibc would have changed anything there. [06:16] slangasek: So, I call coincidence. [06:16] ok, what else does it coincide with? :) [06:16] what's wrong with binutils? [06:16] Changes in scalingstack. [06:17] were there changes in SS? [06:17] There were. But generally for the better. [06:17] pitti: its testsuite started taking 2-3x longer [06:17] infinity: ok [06:17] slangasek: not really - time stamp difference in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/b/binutils/20161006_220952@/log.gz is 3:30 hours [06:18] slangasek: I figure it was retried two or three times due to intermittent cloud failures [06:18] ah [06:18] a worker auto-retries up to three times on such "tmpfail" issues, then it commits suicide [06:18] and these three retries add up to the total test time; that's a bit confusing [06:18] Little bit. [06:18] Yeah. [06:18] it's useful for /running (to spot when tests running), but not for the final result [06:19] THe duration should be of the last test, not the total run. [06:19] "when tests loop") [06:20] I want an s390x laptop. [06:20] filed bug 1631262 [06:20] bug 1631262 in Auto Package Testing "do not include time for tmpfail retries in result runtimes" [Undecided,New] https://launchpad.net/bugs/1631262 [06:20] And a shawarma. [06:21] One of those two things will happen in the next half hour. [06:21] xnox wanted to have an s390x phone in yesterday's meeting -- so how hard can a laptop be then [06:23] Well, I figure I can cut off a leg and replace it with a lithium-ion prosthetic, and then carry a refrigerating unit on my back. [06:24] infinity: iprutils runs 3 daemons out of the box; is that a sensible thing to pull into standard? [06:25] slangasek: It does? It didn't used to. Maybe I live in the past. [06:25] urgh, priority-mismatches is a pool of sadness [06:25] slangasek: If the daemons are useful/sane to have on IPR controllers and gracefully don't start in the absence of same, that might be alright. [06:26] pitti: Yeah, that was my next stop. [06:26] infinity: iprupdate, iprdump, iprinit; all are started as part of multi-user.target; I see no sensible disabling [06:26] pitti: All those py3 modules are curious. [06:26] darn, and we were so close to kicking perl [06:26] perl has been in standard off and on forever. [06:27] I wonder why it fell out. [06:27] infinity: I actually investigated the lp3lib thing somewhere, hang on [06:27] that was for a new corner-case feature in software-properties or release-upgrader or so [06:27] Oh, ick. [06:27] infinity: confirmed that they're all running after install on diamond, but it looks like that might actually have ipr so isn't a good test case for auto-disabling [06:28] Yeah, a VM would be a better test. [06:28] slangasek: But I'm also curious about why we need them running at all. Unless the upstream changed drastically, I always used to use iprutils without a daemon to query/config/update controllers. [06:29] Maybe Colin just enabled them because upstream ships unit files, so why not? [06:31] slangasek: But, yeah, I don't think I'd be happy with them running on non-IPR systems. Less opinionated on what's correct for IPR bare metal. [06:31] * infinity -> shawarma. [06:32] infinity: found the culprit: http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz [06:32] infinity: have updated the MIR bug; includes a reference to Red Hat fixing their package to not auto-start unless ipr is present. Maybe that's been upstreamed and we can take that [06:33] I wish update-manager could just do that one or two REST calls with urllib, instead of pulling that whole stack .. [06:33] infinity: can I leave this to you to figure out from here? [06:33] pitti: Ugh. I don't think that's a valuable enough feature to pull lplib into standard, personally. [06:34] slangasek: I can look after I food. [06:36] infinity: ok. also, it looks perfectly feasible to me to make lsvpd drop its dep on iprconfig, as it should continue functioning in the absence of iprconfig [06:36] slangasek: Perhaps the better short-term solution. [06:39] infinity: cough https://bugs.launchpad.net/ubuntu/+source/lsvpd/+bug/1537116 [06:39] Ubuntu bug 1537116 in lsvpd (Ubuntu Trusty) "lsvpd: Missing package dependency" [Undecided,Incomplete] [06:42] slangasek: Well, that's a special bug log. [07:35] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-raspi2 [sync] (yakkety-proposed) [4.8.0.1012.14] [07:35] -queuebot:#ubuntu-release- Unapproved: accepted linux-raspi2 [sync] (yakkety-proposed) [4.8.0-1012.14] [07:46] -queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [source] (yakkety-proposed) [3.22.1-0ubuntu1] [07:50] -queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server) [07:53] -queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0~rc3-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server) [08:24] please could someone reject the nova upload above - I'd like to put in a autopkgtest fix as well to try sort out the current failures [08:25] jamespage, done [08:26] apw, ta [08:26] xnox had a nice suggestion so trying that [08:26] -queuebot:#ubuntu-release- Unapproved: rejected nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1] [08:27] he's a useful chap to have around [08:27] * jamespage twiddles thumbs whilst fresh yakkety downloads [08:27] gotta love adsl [08:29] he has the giggle factor :) [08:31] hearing it in my head right now [08:38] * infinity hands Laney some aspirin. [08:43] sorry that was my fault [08:43] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-2ubuntu2 => 1:3.7.1-3ubuntu2] (no packageset) [08:44] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu2] [08:48] let's all have a moment of calm to remember the joy that xnox brings to our lives [08:55] urgh [08:56] this looks look a pkg ordering resolution issue [08:56] nice circular between nova-compute -> nova-compute-kvm -> nova-compute-libvirt -> nova-compute [09:00] resulting in nova's membership of libvirt being configured after the daemon is started [09:00] yukity yuk [09:02] Laney, shall i upload gnupg2 for yakkety? enable-ssh-support seems to be broken =/ [09:03] sure, if you've got a fix [09:03] Reference a bug so it can be punted if necessary [09:05] -queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.0~rc2-0ubuntu3 => 2:14.0.0-0ubuntu1] (openstack, ubuntu-server) [09:05] * xnox dist-upgrades to latest upload to reverify [09:07] apw, OK ^^ is better I think - there is a niggle in the dep order for nova-compute-* things - the test changes make things configure in the right order, but it probably needs more thinking next cycle [09:08] can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26 [09:11] https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1631304 [09:11] Ubuntu bug 1631304 in nova (Ubuntu) "apt-get install nova-compute has odd configuration order" [Medium,Triaged] [09:11] for reference [09:13] same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there [09:13] jamespage, win! \o/ [09:13] xnox, one of those beggining of time type bugs methinks [09:28] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.7 (yakkety-proposed/universe) [1:3.7.1-3ubuntu2 => 1:3.7.1-3ubuntu3] (no packageset) [09:28] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.7 [source] (yakkety-proposed) [1:3.7.1-3ubuntu3] [09:32] -queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (yakkety-proposed/main) [1.1.93-1ubuntu1 => 1.2.6-2ubuntu1] (no packageset) [09:37] Hm... shouldn't http://changelogs.ubuntu.com/meta-release contain yakkety by now? [09:38] Just trying to test Xenial to Yakkety release upgrades and "do-release-upgrade -d" acts as there is nothing new [09:43] smb: Changing /etc/update-manager/release-upgrades to have Prompt=normal fixed that for me. [09:45] Odd_Bloke, hm it does. But its odd. I thought "-d" was supposed to override things [09:46] smb: ¯\_(ツ)_/¯ [09:47] indeed [09:50] smb, after every LTS release, upgrade-manager reverts to "show me LTS only" and thus -d would work to do xenial -> 18.04 LTS (when in devel) [09:51] there is gui option to toggle the tickbox too in software sources. [09:51] clearly, smb, does not read OMG!Ubuntu =) [09:51] xnox, ok... well if you got a gui (server) [09:52] horum [09:52] it is a conf file, no idea if there is non text-editor options =/ [09:57] xnox, I can perfectly change it as soon as I know its supposed to work like that. Apparently I do not read omg!ubuntu nor did I do that many dist-upgrade tests for a hey-its-a-lts+1-crack-release releases. :-P [09:57] Also upgrades to LTSes reset that var to 'lts' [10:24] bug 1631320 [10:24] bug 1631320 in gnupg2 (Ubuntu) "systemd-user cannot connect to gpg-agent ssh-agent" [Undecided,New] https://launchpad.net/bugs/1631320 [10:25] -queuebot:#ubuntu-release- Unapproved: gnupg2 (yakkety-proposed/main) [2.1.15-1ubuntu5 => 2.1.15-1ubuntu6] (core) [10:25] Laney, ^ [10:32] xnox: looks right [10:33] xnox: I think it was always like this [10:33] at least the internets seems to document using XDG_RUNTIME_DIR [10:34] Laney, xenial desktop with upstart user session uses /home/xnox/.gnupg/S.gpg-agent.ssh [10:34] for gpg2? [10:34] but i think what happened there is that xenial's gpg-agent honoured preset environmental variable (you want it there - you get it there) [10:35] that's 2.1.11 agent [10:35] and 2.2 agent is more opinionated - you shall use /this/ socket. [10:38] anyways :) [10:38] -queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (yakkety-proposed) [2.1.15-1ubuntu6] [11:20] -queuebot:#ubuntu-release- Unapproved: accepted cpustat [source] (xenial-proposed) [0.01.25-1ubuntu0] [11:38] xnox: I guess you should fix gpg-agent.conf too [11:38] (upstart) [11:46] xnox: does this still actually need the env var at all? [11:47] xnox: I thought with either XDG_RUNTIME_DIR or GNUPGHOME the path is alwasy the same anyway, so that we can stop having these silly "poke a constant well-known value in to the session env early" [11:47] and this also works on VT/ssh logins after all, where none of this runs [11:48] I realize we still need to export those for legacy software which expoects them, but they hsould at least point to the canonical location [11:57] pitti, nothing to do with GPG agent, has to do everything with SSH_AGENT variables. [11:57] this is a corner case i use gpg-agent as an SSH agent. [11:58] pitti, possibly need fixing. on xenial with gpg-agent 2.1 things work with $GNUPGHOME for the enable-ssh-support. [11:59] but i do not care about gpg-agent ssh integration in yakkety with upstart user session. As far as I understand, e.g. on touch, people can't really use gpg ssh-agent... =/ [11:59] or maybe they can. [11:59] but i'm not sure why they would. it's no different to using ssh-agent given no support for smartcards. [11:59] it's not just touch [11:59] other flavours use upstart [12:00] I think you should fix the path there too [12:04] pitti, hey - are you aware of any changes to the way udev manages perms on devices? I'm triaging a yakkety specific issue with ceph - basically the ceph/ceph user/group is not being applied via the udev rules afaict [12:04] bug 1631328 for context [12:04] bug 1631328 in ceph-osd (Juju Charms Collection) "ceph-osd stays blocked on Yakkety: "No block devices detected using current configuration"" [Undecided,New] https://launchpad.net/bugs/1631328 [12:12] Laney, huh? we do have systemd user session everywhere unconditionally as far as I understand. becuase pam logind starts that. [12:13] (in addition to upstart user session, at times) [12:14] xnox: gpg-agent.service is started by graphical-session-pre.target.wants/ [12:14] however i don't see gpg-agent started for TTY1 session, and I don't see gpg-agent tty updated upon seat switches. [12:15] * xnox guesses elmo / smb / smoser will kill me if systemd starts spawning gpg-agent left-right-and-center upon tty logins =) [12:19] * smb misses a bit of context but in my world systemd or anything else would just blow up because the keyring won't be there ... [12:23] hmm yeah - it appears that the ceph udev rules don't get automatically picked up by udev without a reload? [12:25] Release Team : LocutusOfBorg has uploaded a fix for llvm-toolchain-3.7 to fix a powerpc FTBS [12:25] the same fix apply to llvm-toolchain-3.6 which impacts clamav (its only dependency) [12:25] jamespage, one does need to re-trigger devices to apply newly created rules, that are added after udev spotted a device. [12:26] debian has just dropped use of llvm for clamav until it can be used with llvm-3.8 so either we do the same for clamav and remove LLVM-36 [12:26] xnox, yeah just baffled as to why udev is not applying the perms but just spotted something [12:26] udev is silly [12:28] xnox, see last comment in that bug [12:29] can failing tests of kdeclarative be retried? they seem to be failing against plasma-framework/5.24.0-0ubuntu1 while we now have 5.26 [12:29] same for kxmlgui. tests are failing against plasma-framework/5.24 when there is 5.26 there [12:30] acheronuk, is plasma-framework/5.26 in -proposed ? [12:30] apw: yes [12:31] -queuebot:#ubuntu-release- Unapproved: supertux (yakkety-proposed/universe) [0.4.0-1 => 0.5.0-1] (no packageset) (sync) [12:31] -queuebot:#ubuntu-release- Unapproved: accepted supertux [sync] (yakkety-proposed) [0.5.0-1] [12:31] -queuebot:#ubuntu-release- Unapproved: magnum (yakkety-proposed/universe) [3.0.0-1 => 3.1.1-0] (no packageset) (sync) [12:32] acheronuk, ok by default each package is tested only with -release pocket packages, it has to be requested manually, trying to find out how :) [12:32] -queuebot:#ubuntu-release- Unapproved: accepted magnum [sync] (yakkety-proposed) [3.1.1-0] [12:33] apw: retry-autopkgtest-regressions --all-proposed will give you the command [12:34] apw: sorry. I am fairly new to this side of the release/migration process. I can just see it they were got to move, a lot else might then get unstuck in response [12:40] -queuebot:#ubuntu-release- Unapproved: im-config (xenial-proposed/main) [0.29-1ubuntu12 => 0.29-1ubuntu12.2] (input-methods, kubuntu, ubuntu-desktop) [12:41] Laney, ahh nice [12:41] * apw tries to run the appropriate tests again [12:41] apw: (or add others as --trigger to just pick those ones) [12:41] all-proposed is probably easier for KDE stuff though :P [12:43] acheronuk, if we are lucky submitted [12:46] apw: thank you :) if that doesn't resolve it, I'll ask some other kubuntu team members to look again later [12:52] morning! [12:53] hey cyphermox, how are you? [13:02] -queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.3-0ubuntu1 => 10.2.3-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server) [13:09] bad [13:10] pitti: everytime I do small plumbing repairs I remember why I went in IT [13:12] -queuebot:#ubuntu-release- Unapproved: sahara (yakkety-proposed/universe) [1:5.0.0~rc1-1 => 1:5.0.0-1] (openstack) (sync) [13:12] -queuebot:#ubuntu-release- Unapproved: zaqar (yakkety-proposed/universe) [3.0.0~b2-1 => 3.0.0-1] (no packageset) (sync) [13:13] -queuebot:#ubuntu-release- Unapproved: accepted zaqar [sync] (yakkety-proposed) [3.0.0-1] [13:16] please be aware of https://bileto.ubuntu.com/#/ticket/2054 (qtbase, workaround from upstream to fix also the different crash on exits, iso-tracker bug) and https://bileto.ubuntu.com/#/ticket/2055 (arm64 QML problem, the fix that is alternative to going back to 4.2 kernel on builders, but the patch may affect other 64-bit platforms too). I'm trying to get QA look into those but the silos are ready [13:16] build wise. [13:17] could a release team member review my ceph upload - its blocking most of our OpenStack testing on yakkety today so would be nice to get clear [13:18] -queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu8 => 2.1.0-1ubuntu9] (ubuntu-server, virt) [13:19] -queuebot:#ubuntu-release- Unapproved: pandas (yakkety-proposed/universe) [0.17.1-3ubuntu2 => 0.18.1-1] (no packageset) (sync) [13:19] -queuebot:#ubuntu-release- Unapproved: accepted pandas [sync] (yakkety-proposed) [0.18.1-1] [13:19] -queuebot:#ubuntu-release- Unapproved: fwts (yakkety-proposed/universe) [16.09.00-0ubuntu3 => 16.09.00-0ubuntu4] (no packageset) [13:21] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.4 => 1.3.1-1ubuntu10.5] (ubuntu-server, virt) [13:21] -queuebot:#ubuntu-release- Unapproved: accepted fwts [source] (yakkety-proposed) [16.09.00-0ubuntu4] [13:22] -queuebot:#ubuntu-release- Unapproved: xen (yakkety-proposed/main) [4.7.0-0ubuntu1 => 4.7.0-0ubuntu2] (kubuntu, ubuntu-desktop, ubuntu-server, virt) [13:29] infinity: Could you test tip of https://anonscm.debian.org/cgit/collab-maint/iprutils.git to see if (a) daemons still come up on systems with ipr and (b) daemons don't come up on systems without ipr? [13:29] -queuebot:#ubuntu-release- Unapproved: mistral (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-1] (no packageset) (sync) [13:30] -queuebot:#ubuntu-release- Unapproved: accepted mistral [sync] (yakkety-proposed) [3.0.0-1] [13:35] -queuebot:#ubuntu-release- Unapproved: ironic-inspector (yakkety-proposed/universe) [3.2.0-2 => 4.2.0-1] (no packageset) (sync) [13:35] -queuebot:#ubuntu-release- Unapproved: accepted ironic-inspector [sync] (yakkety-proposed) [4.2.0-1] [13:36] -queuebot:#ubuntu-release- Unapproved: murano (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (openstack) (sync) [13:42] -queuebot:#ubuntu-release- Unapproved: murano-agent (yakkety-proposed/universe) [1:3.0.0~rc1-1 => 1:3.0.0-1] (no packageset) (sync) === s8321414_ is now known as s8321414 [13:44] -queuebot:#ubuntu-release- Unapproved: accepted murano-agent [sync] (yakkety-proposed) [1:3.0.0-1] [13:46] apw: retry seems to have done it ofr kdeclarative if I am not misreading :) can you try for kxmlgui if not done already? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui [13:47] seems to be a final blocker ^^ [13:53] acheronuk, looking [13:54] acheronuk, submitted [14:09] acheronuk: final package? [14:09] -queuebot:#ubuntu-release- New sync: neutron-dynamic-routing (yakkety-proposed/primary) [2:9.0.0~rc2-1] [14:11] someone has an opinion on the LLVM-3.6 .vs. clamav upload ? === jgrimm is now known as jgrimm-out [14:23] cyphermox: urgh, got disconnected, just got scrollback -- household repairs? [14:24] cyphermox: and now your kitchen is a swamp? [14:24] no, not that much [14:25] no wonder IRC had been so quiet in the last hour [14:25] it's barely leaking a drop here and there around the handles, but *any* leakage annoys me, because it's clearly a failure [14:25] and patching plumbing isn't as easy as in our profession :) [14:28] * pitti does a mass-retry with all-proposed for KDEish stuff, let's see what sticks [14:37] -queuebot:#ubuntu-release- Unapproved: chromium-browser (yakkety-proposed/universe) [51.0.2704.79-0ubuntu2~cm1 => 53.0.2785.143-0ubuntu1.1307] (ubuntu-desktop) [14:53] thanks pitti [15:03] infinity: fyi, oem-config-gtk isn't installed after doing an OEM install from today's desktop daily. i recall this happening now and then, but i can't remember what you said causes this [15:15] cyphermox: trade you a leaky faucet for groundwater seepage in our lower level ;) [15:15] sucks to be you! [15:16] slangasek: ouch, that sounds rough. where abouts do you live? [15:16] slangasek: is lower level meaning basement, or ground level? [15:17] cyphermox: the front is below grade, the back is above grade, so it's a basement when it gives us problems like this [15:17] because to me that sounds like "omg, need to fix the foundation, will cost upwards of 10k, I want to die now" [15:17] jderose: Portland [15:18] (the bit with high water table and lots of rain) [15:18] cyphermox: hey dude shim and mok working today \o/ Haven't tried on hardware will do that shortly [15:18] davmor2: ack, thanks! [15:18] slangasek: nice. i lived in portland for about 4 years. loved the summers, but eventually decided i personally need more sun, so moved back to colorado :) [15:18] jderose: :-) [15:20] -queuebot:#ubuntu-release- Unapproved: libsmbios (yakkety-proposed/universe) [2.3.0-0ubuntu1 => 2.3.1-0ubuntu1] (no packageset) [15:21] -queuebot:#ubuntu-release- Unapproved: accepted libsmbios [source] (yakkety-proposed) [2.3.1-0ubuntu1] [15:23] slangasek: seen my prior comment about LLVM-3.6 & clamav ? [15:23] -queuebot:#ubuntu-release- Unapproved: libsmbios (xenial-proposed/universe) [2.3.0-0ubuntu1 => 2.3.0-0ubuntu1.1] (no packageset) [15:23] tl;dr : will upload a fix for LLVM3.6 FTBS on powerpc, then we'll drop LLVM3.6 in Z [15:24] unless the release team has something against it [15:24] caribou: you're asking about whether to patch llvm-3.6 or drop the llvm usage from clamav? [15:24] slangasek: patch 3.6 as it's been done for 3.7 yesterday [15:25] caribou: fixing a build failure is non-controversial [15:25] slangasek: i know, but you were talking about dropping 3.6 altogether during the meeting, [15:26] Debian has dropped it in the latest clamav pkg (yesterday) until upstream get support for LLVM 3.8 [15:26] caribou: well, the question was "why does clamav have its own version". If the answer is "because it's not ported yet to 3.8 and this is non-trivial", that answers that question [15:27] I don't know what dropping llvm support costs us in functionality in clamav; I'm not asking to drop functionality from the package [15:27] -queuebot:#ubuntu-release- Unapproved: lsvpd (yakkety-proposed/main) [1.7.7-1 => 1.7.7-1ubuntu1] (no packageset) [15:27] slangasek: ok, good then; I'll push the 3.6 fix to unblock everything & will take care of the rest during Z [15:27] I probably will kick llvm-3.6 out of Debian in two days or so [15:27] please kick it out from Ubuntu if possible [15:27] we already have llvm-3.6 in main in xenial, it's not like dropping it before yakkety release gains us anything in terms of support length [15:27] dropping it for z will suffice [15:27] -queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (yakkety-proposed) [1.7.7-1ubuntu1] [15:27] slangasek: thanks! [15:28] makes sense, unfortunately 3.7 seems to be failing to build on amd6 [15:28] LocutusOfBorg: if you're ok, I'll upload the powerPC fix monday morning (hate friday's uploads) [15:28] caribou, I would prefer uploading right now :( [15:28] I can bother other core-devs in case something breaks [15:29] LocutusOfBorg: fine with me then src pkg is ready [15:29] LocutusOfBorg: just doing last minute check & I will upload [15:29] I hate having fixes for toolchain the week of release [15:29] :) [15:33] LocutusOfBorg: i'll be around (and am core-dev now) [15:39] thanks [15:40] BTW as soon as this one is over http://debomatic-amd64.debian.net/distribution#unstable/llvm-toolchain-3.6/3.6.2-4/buildlog [15:40] I'll upload it on Debian, and ask to sync it [15:41] I took the delta [15:44] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.6 (yakkety-proposed/main) [1:3.6.2-3ubuntu3 => 1:3.6.2-3ubuntu4] (kubuntu, ubuntu-desktop, ubuntu-server) [15:44] LocutusOfBorg: ^^ [15:53] thanks [16:03] apw: I made an interesting observation in bug 1626436 [16:03] bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Medium,Triaged] https://launchpad.net/bugs/1626436 [16:05] I wonder if there's some way to ignore uevents to test this theory [16:07] sorry, this is #u-devel matter, have this channel in the wrong window [16:10] yakkety 20161007 live cd on Lenovo x230 and external monitors does not boot to X. without external monitor I get X but attaching the monitor leads to a 'hall of mirrors' effect outside a certain region of the screen. Just a heads up, I'm taking more of a look. Right now have bug #1631349 open [16:10] Error: Launchpad bug 1631349 could not be found [16:17] pitti: can kxmlgui test on plasma-framework be re-run with 'retry-autopkgtest-regressions --all-proposed' or whatever the command is? it's failing on plasma-framework 5.24 when we have 5.26 available [16:18] apw kindly tried that with kdeclarative earlier and it seemed to help [16:20] ^^^ or @ slangasek or anyone available who has sec. thank you [16:22] acheronuk: pitti mentioned 2 hours ago in here that he was doing a "mass-retry with all-proposed for KDEish stuff", maybe this is already done? [16:25] slangasek: damn. I though I had refreshed the excuses page, but clearly not. now listing both 5.24 & 5.26 and still 'not considered' for some reason http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kxmlgui [16:26] * acheronuk clearly needs more caffination [16:29] slangasek: when I follow the not considered due to dependencies on other things, mostly they seem to lead back after a few levels to that kxmlgui [16:35] acheronuk: there appears to be a plasma-framework/ppc64el test still running [16:38] slangasek: my view shows that as regression for 5.24 and absent on that arch for 5.26. neither 'running' [16:38] don't know if you can see something I can't or somewhere I am not looking [16:46] -queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-14-g94fd35e-0ubuntu1 => 0.7.8-15-g6e45ffb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server) [16:57] acheronuk: http://autopkgtest.ubuntu.com/running [16:58] slangasek: cheers. I am still finding my way around this stuff [17:04] slangasek: that ppc64el test shows no output on that page? is that right? sorry to be a pain :/ [17:06] I now with I could learn what's what on this at a slightly calmer time! [17:06] *now wish [17:11] acheronuk: there are several stanzas, it's a bit hard to scan that page to spot the right one but the test I was looking at was Release: yakkety Architecture: ppc64el Requester: pitti Triggers: ['mesa/12.0.3-1ubuntu2', 'kxmlgui/5.26.0-0ubuntu1'] All-proposed: 1 [17:13] slangasek: yes, I think I found it ok. it's now vanished off that page [17:14] * smoser comes to grovel [17:14] ah. there it is. [17:14] Odd_Bloke, noticed an error in the previous upload for cloud-init... it did not actually fixt he issue it reported to [17:14] his fix he tested and i uploaded. [17:18] cyphermox: any recent ubiquity changes you can think of that might result in oem-config-gtk not being installed after doing an oem install? [17:18] smoser: accepted [17:18] please accept llvm [17:19] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-15-g6e45ffb-0ubuntu1] [17:20] LocutusOfBorg: done [17:21] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.6 [source] (yakkety-proposed) [1:3.6.2-3ubuntu4] [17:21] thanks [17:24] -queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.0-0ubuntu1] [17:25] -queuebot:#ubuntu-release- Unapproved: ubuntu-themes (yakkety-proposed/main) [16.10+16.10.20161005-0ubuntu1 => 16.10+16.10.20161007-0ubuntu1] (kubuntu, ubuntu-desktop) (sync) [17:48] -queuebot:#ubuntu-release- Unapproved: nautilus (yakkety-proposed/main) [1:3.20.3-1ubuntu2 => 1:3.20.3-1ubuntu3] (ubuntu-desktop) [17:52] -queuebot:#ubuntu-release- Unapproved: oxide-qt (yakkety-proposed/main) [1.17.7-0ubuntu1 => 1.17.9-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) [17:53] Hello - I've just sponsored a yakkety oxide-qt upload, on behalf of chrisccoulson, which fixes a number of security issues (see bug #1631448) [17:53] bug 1631448 in Canonical System Image "Update to 1.17.9" [Critical,In progress] https://launchpad.net/bugs/1631448 [17:53] we'd prefer that it be part of the yakkety release but we can always release it to yakkety-security after the release if it is going to cause too much trouble [18:37] jamespage: I'm curious about the change in nova autopkgtests; armhf and s390x both have always run their tests in containers, and don't appear to be /fundamentally/ broken on those archs as they've passed intermittently [18:51] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (yakkety-proposed/main) [1.371 => 1.372] (core) [18:55] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.0-0ubuntu1] [18:55] -queuebot:#ubuntu-release- New: accepted neutron-dynamic-routing [sync] (yakkety-proposed) [2:9.0.0~rc2-1] [19:03] -queuebot:#ubuntu-release- New binary: neutron-dynamic-routing [amd64] (yakkety-proposed/universe) [2:9.0.0~rc2-1] (no packageset) [19:13] jamespage: I think this ceph upload is wrong; udev rules db is auto-reloaded via inotify, and per the manpage a --reload doesn't change perms on existing devices - I believe you want udevadm trigger --subsystem-match=block --action=change which is the convention used elsewhere [19:14]