[00:56] slangasek: I've finished regression testing the fixes LaMont put together (via custom built MAAS images) -- from what I can tell, everything looks okay. I've done a dozen or so deployments with MAAS, using X and Y. [00:57] updated the bug to verification-done. [01:06] -queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.11.90.20161005-0ubuntu1] [01:06] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (yakkety-proposed) [16.10.10] [01:07] * cyphermox back [01:11] cyphermox: could you please keep me in the loop on the Kubuntu slideshow? [01:12] infinity: if this retry of the autopkgtests for open-iscsi fail, I think we'll have reached the point where we might as well override the tests -- I know open-iscsi works, even in those MAAS ephermeral tests, I ran them multiple times locally and we (lamont and I) did run MAAS deployments with these pacakges [01:13] -queuebot:#ubuntu-release- New binary: libkf5libkleo [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:13] -queuebot:#ubuntu-release- New binary: libkf5libkleo [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:14] -queuebot:#ubuntu-release- New binary: libkf5libkleo [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:14] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:14] tsimonq2: ok, starting to look into that now [01:16] -queuebot:#ubuntu-release- New binary: libkf5libkleo [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:16] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:16] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:16] can someone please hit https://autopkgtest.ubuntu.com/request.cgi?release=yakkety&arch=i386&package=unity8&trigger=unity-scope-click%2F0.1.1%2B16.10.20161005-0ubuntu1 to retry the test? only failed on i386 and in someething that unity-scope-click would have had no effect on [01:16] thanks a bunch cyphermox :) [01:16] -queuebot:#ubuntu-release- New binary: libkf5libkleo [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:16] tsimonq2: however, I have little idea what I'm doing there, so we'll see ;) [01:17] cyphermox: you familiar with Qt and/or Python? :) [01:17] python and ubiquity yes, Qt, much less, but I can manage [01:17] well then it won't be TOO hard for you :) [01:18] -queuebot:#ubuntu-release- New binary: libkf5libkleo [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:18] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:18] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:19] -queuebot:#ubuntu-release- New binary: libkf5libkleo [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:22] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:23] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:27] -queuebot:#ubuntu-release- New: accepted libkf5libkleo [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:28] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:28] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [01:28] ooh, more Kubuntu stuff accepted ;) [01:41] tsimonq2: what of blaze's port to pyqt5? [01:42] cyphermox: huh? [01:42] someone called 'blaze' on LP did some porting to pyqt5 [01:42] I'm looking through it right now, looks legit and pretty complete [01:42] I just didn't understand your question [01:42] well apparently it's not complete [01:42] ok [01:43] I couldn't get it set up on my machine [01:43] well then it's going to get me some ways to the end [01:43] segfault [01:44] cyphermox: so I think what you might need to do to figure it out is fix the goshdarn segfault :P [01:45] it looks like it's not that simple. if there's no webkit for pyqt4 as it seems to be the case now, there isn't much I'll be able to do [01:45] ah, zsync done [01:56] -queuebot:#ubuntu-release- Unapproved: spu-tools (yakkety-proposed/universe) [2.3.0.136-2 => 2.3.0.136-2ubuntu1] (no packageset) [01:57] -queuebot:#ubuntu-release- Unapproved: accepted spu-tools [source] (yakkety-proposed) [2.3.0.136-2ubuntu1] [01:58] -queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.0.0+bzr5189-0ubuntu1 => 2.1.0~beta2+bzr5454-0ubuntu1] (ubuntu-server) [02:50] slangasek: it occured to me over dinner... initramfs-tools is already in yakkety, it's the xenial SRU that's sitting in -proposed. [02:56] bug 1621615 also marked verification-done [02:56] bug 1621615 in MAAS "network not configured when ipv6 netbooted into cloud-init" [Undecided,New] https://launchpad.net/bugs/1621615 [02:57] slangasek: given that all of the packages in question are Fix-Released in yakkety, I expect that the SRUs of same could wait until people are awake after final freeze and the RC is out. [03:10] -queuebot:#ubuntu-release- New binary: libkf5gravatar [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:10] -queuebot:#ubuntu-release- New binary: libkf5gravatar [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:11] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:11] -queuebot:#ubuntu-release- New binary: libkf5gravatar [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:12] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:13] could a Release Team member take a look at bug 1630557 ? thanks [03:13] bug 1630557 in ubuntu-gnome-meta (Ubuntu) "FFE: Include Spice integration by default in Ubuntu GNOME" [Wishlist,New] https://launchpad.net/bugs/1630557 [03:14] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:14] -queuebot:#ubuntu-release- New binary: libkf5gravatar [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:14] -queuebot:#ubuntu-release- New binary: libkf5gravatar [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:15] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:15] -queuebot:#ubuntu-release- New binary: libkf5gravatar [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:15] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:15] -queuebot:#ubuntu-release- New binary: libkf5gravatar [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:17] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:18] -queuebot:#ubuntu-release- New binary: kf5-kdepim-apps-libs [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [03:28] cyphermox: webkit has support in PyQt5 [03:28] blaze changed the names of the functions from PyQt4 to 5 [03:28] ahoneybun: yeah, I noticed [03:28] I'm working on that, got it a bit of way to working [03:32] so far I can almost reach the timezone panel [04:03] dobey: unity8 i386 retried; I feel like I've seen that failure before, maybe you could log a bug about them fixing the test? [04:03] there! working slideshow for kubuntu. [04:04] -queuebot:#ubuntu-release- Unapproved: nfstrace (yakkety-proposed/universe) [0.4.2-2ubuntu2 => 0.4.2-2ubuntu3] (no packageset) [04:06] -queuebot:#ubuntu-release- Unapproved: accepted nfstrace [source] (yakkety-proposed) [0.4.2-2ubuntu3] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:08] -queuebot:#ubuntu-release- New: accepted libkf5gravatar [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:12] santa_: this sticks out among the other KDE lib packages: I: libkf5kaddressbookgrantlee5: no-symbols-control-file usr/lib/x86_64-linux-gnu/libKF5KaddressbookGrantlee.so.5.2.3 [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:13] -queuebot:#ubuntu-release- New: accepted kf5-kdepim-apps-libs [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [04:19] slangasek: wondering if we could override the open-iscsi test results. the MAAS ephemeral image test still fails in autopkgtest, but they do work locally and I and lamont have run MAAS deployments that show the package is working [04:20] cyphermox: slangasek I fully support this plan [04:21] cyphermox: I'd actually be inclined to leave that particular test there, but not run by default, with the README saying how to run it, and a hope that people run it manually to make sure it still passes [04:31] cyphermox, lamont: last successful autopkgtest for open-iscsi on amd64 and i386 was before xenial was released; yes to overriding, and +1 from me for disabling a test that isn't passing [04:31] lamont: well, true that I could have it skip myself. [04:31] (that's an SRU-worthy change for both xenial and yakkety) [04:32] -queuebot:#ubuntu-release- Unapproved: arc-theme (yakkety-proposed/universe) [20160923-1 => 20161005-1] (no packageset) (sync) [04:32] -queuebot:#ubuntu-release- Unapproved: clearlooks-phenix-theme (yakkety-proposed/universe) [6.0.3-1 => 6.0.3+git20161006-1] (no packageset) (sync) [04:33] -queuebot:#ubuntu-release- Unapproved: accepted arc-theme [sync] (yakkety-proposed) [20161005-1] [04:33] -queuebot:#ubuntu-release- Unapproved: accepted clearlooks-phenix-theme [sync] (yakkety-proposed) [6.0.3+git20161006-1] [04:33] I'll do an upload tomorrow that skips the test, it's easy to unskip it for one-off local autopkgtest runs. [04:34] lamont: ^ [04:34] and now, I'm off [04:34] cyphermox: g'night [04:35] good morning [04:35] g'night [04:35] * lamont stil has a few more tests to run before his hardware gets repossessed by IS in the morning [04:35] cyphermox: open-iscsi? I'll hint if it still fails [04:35] pitti: I've just hinted open-iscsi :) [04:35] ack [04:35] it's indeed what we were discussing [04:36] pitti: good morning, sir [04:37] hey lamont, how are you? [04:38] lets not go there. :D [04:38] actually doing well [04:38] questions from earlier in /query [04:39] mostly of the "halp how make work" variety, that become useful tomorrow when I cause my local hardware to qemu boot ipv6 guests [04:49] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (xenial-proposed) [1.376.1] [04:51] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.1-0ubuntu1.1] [05:28] pitti: I'm puzzled by the autopkgtest failure here; there's an error about an undefined symbol that is only available in the proposed version of kiconthemes, which has correct .symbols files, so how did the test environment ever end up with anything referencing that symbol? http://autopkgtest.ubuntu.com/packages/p/plasma-framework/yakkety/amd64 [05:30] -queuebot:#ubuntu-release- Unapproved: rejected maas [source] (yakkety-proposed) [2.1.0~beta1+bzr5433-0ubuntu1] [05:30] (I'm also retrying it with kio+kiconthemes fwiw) [05:33] slangasek: I did a mass-retry for KDE against all of -proposed on Monday, as the 5.26 packages commonly need to be tested together [05:33] I suppose that exposed it? [05:36] pitti: if it had been tested with the version of kiconthemes in -proposed, it shouldn't have been a missing symbol [05:38] Get:184 http://ftpmaster.internal/ubuntu yakkety-proposed/universe amd64 libkf5iconthemes5 amd64 5.26.0-0ubuntu1 [83.3 kB] [05:38] slangasek: ^ it was [05:38] -queuebot:#ubuntu-release- Unapproved: rejected linux-signed [sync] (yakkety-proposed) [4.8.0-21.23] [05:39] slangasek: actually, that log was not a run with --all-proposed [05:39] pitti: ah. so I see packages being downloaded multiple times as part of that test. Is it building against -proposed, and then testing the binaries against release? [05:39] --apt-pocket=proposed=src:kio [05:39] -queuebot:#ubuntu-release- Unapproved: linux-signed (yakkety-proposed/main) [4.8.0-19.21 => 4.8.0-21.23] (core, kernel) (sync) [05:39] i. e. that was just a standard "minimize proposed" run [05:41] slangasek: no, the apt pinning is the same for build and binaries, but it did run into the fallback: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed [05:41] pitti: ah [05:41] slangasek: so, it did build against everything in -proposed, as just instlaling kio from -proposed was uninstallable [05:42] and if deps aren't versioned correctly and pinning just the trigger from -proposed causes uninstallability, running everything from -proposed is the fallback [05:42] that happened during build, but not during the test [05:43] so indeed this is a case where --all-proposed (or more selectively using kiconthemes from -proposed) should help [05:43] pitti: got it. a bit confusing, especially when grepping the log instead of reading it linearly [05:45] santa_, acheronuk: libkdegames looks like it still has a broken autopkgtest (acc, broken since mid-august) [05:46] slangasek: want me to do a mass-retry against all-proposed to mop up these cases? [05:48] santa_, acheronuk: (overriding the bad test for libkdegames, to avoid blocking) [05:48] pitti: I'm never thrilled with --all-proposed because I don't feel that it gives us proper bisection, but it's up to you [05:51] good morning, today openvswitch shows up in update-excuses for a failed dependent neutron test [05:51] coreycb yesterday analyzed just such an issue and debugged it to a timing issue on s390 [05:52] therefore I was re-triggering the test for now [05:52] is there anything I should check/notify if I do so (I beg a pardon, but this is the first time I restart such a test) [05:53] cpaelzer: nope, just don't stand on the button [05:53] one click, one SSO login and thats it [05:53] ok, will take a look later then if that unblocked it [05:53] thanks slangasek [05:54] at least I found it on the running queue, so the triggering worked [05:57] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta [sync] (yakkety-proposed) [4.8.0.21.30] [05:57] -queuebot:#ubuntu-release- Unapproved: accepted linux [sync] (yakkety-proposed) [4.8.0-21.23] [05:57] -queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (yakkety-proposed) [4.8.0-21.23] [06:02] -queuebot:#ubuntu-release- Unapproved: golang-github-appc-spec (yakkety-proposed/universe) [0.8.5+dfsg-1 => 0.8.6+dfsg-1] (no packageset) (sync) [06:02] -queuebot:#ubuntu-release- Unapproved: accepted golang-github-appc-spec [sync] (yakkety-proposed) [0.8.6+dfsg-1] [06:03] -queuebot:#ubuntu-release- Unapproved: golang-google-grpc (yakkety-proposed/universe) [0.0~git20160517.0.a22b6611-2 => 1.0.0-1] (no packageset) (sync) [06:04] -queuebot:#ubuntu-release- Unapproved: accepted golang-google-grpc [sync] (yakkety-proposed) [1.0.0-1] [06:06] -queuebot:#ubuntu-release- Unapproved: gcc-snapshot (yakkety-proposed/universe) [20161001-1ubuntu1 => 20161006-1ubuntu1] (no packageset) [06:07] good morning [06:07] -queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (yakkety-proposed) [20161006-1ubuntu1] [06:08] slangasek: regarding libkdegames I think you were right when you said it was obsolete, apparently nothing is using it anymore but libkeduvocdocument [06:08] -queuebot:#ubuntu-release- Unapproved: kdesdk-thumbnailers (yakkety-proposed/universe) [4:15.12.3-0ubuntu1 => 4:15.12.3-0ubuntu2] (kubuntu) [06:09] I don't know why it's still released upstream maybe they didn't removed it yet from the tarball release scripts [06:09] ah [06:09] regarding the libkf5kaddressbookgrantlee5 I take note [06:10] slangasek: right now I have finished kidentitymanagement, that should unblock the remaining kde builds, would you like to sponsor it? I can prepare a dsc [06:10] santa_: I've also retried akonadi's autopkgtest with a hint to make things installable, and it fails with a different error now: http://autopkgtest.ubuntu.com/packages/a/akonadi/yakkety/amd64 [06:11] santa_: maybe pitti can sponsor it, I'm past EOD [06:11] santa_: sure, please send me a debdiff or pointer to .dsc [06:11] ok [06:12] -queuebot:#ubuntu-release- Unapproved: accepted kdesdk-thumbnailers [source] (yakkety-proposed) [4:15.12.3-0ubuntu2] [06:17] pitti: http://gpul.grupos.udc.es/sponsor/kidentitymanagement_16.04.3-0ubuntu2.dsc [06:18] -queuebot:#ubuntu-release- Unapproved: gcc-6-cross-ports (yakkety-proposed/universe) [9ubuntu1 => 9ubuntu2] (no packageset) [06:23] -queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross-ports [source] (yakkety-proposed) [9ubuntu2] [06:30] -queuebot:#ubuntu-release- Unapproved: gcc-5-cross (yakkety-proposed/universe) [24ubuntu1 => 24ubuntu2] (ubuntu-desktop) [06:31] -queuebot:#ubuntu-release- Unapproved: gcc-5-cross-ports (yakkety-proposed/universe) [10ubuntu1 => 10ubuntu2] (no packageset) [06:34] -queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross-ports [source] (yakkety-proposed) [10ubuntu2] [06:39] -queuebot:#ubuntu-release- Unapproved: accepted gcc-5-cross [source] (yakkety-proposed) [24ubuntu2] [07:02] -queuebot:#ubuntu-release- Unapproved: kidentitymanagement (yakkety-proposed/universe) [15.12.3-0ubuntu1 => 16.04.3-0ubuntu2] (kubuntu) [07:10] -queuebot:#ubuntu-release- Unapproved: accepted kidentitymanagement [source] (yakkety-proposed) [16.04.3-0ubuntu2] [07:10] santa_: ^ (will have a look at binNEW again after it built) [07:12] pitti: thank you very much [07:14] -queuebot:#ubuntu-release- New binary: kidentitymanagement [ppc64el] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:14] santa_: that'll require a dozen no-change rebuilds; want/need me to upload those? [07:14] -queuebot:#ubuntu-release- New binary: kidentitymanagement [amd64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:14] -queuebot:#ubuntu-release- New binary: kidentitymanagement [i386] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:15] -queuebot:#ubuntu-release- New binary: kidentitymanagement [arm64] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:16] -queuebot:#ubuntu-release- New binary: kidentitymanagement [s390x] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:16] -queuebot:#ubuntu-release- New binary: kidentitymanagement [armhf] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:17] -queuebot:#ubuntu-release- New binary: kidentitymanagement [powerpc] (yakkety-proposed/universe) [16.04.3-0ubuntu2] (kubuntu) [07:18] slangasek: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1982 → just the newer version is enough, britney now does a ≤ check on the version for matching [07:20] -queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160831-0ubuntu1 => 0.13+16.10.20160929.1-0ubuntu1] (ubuntu-desktop) (sync) [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [amd64] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [armhf] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [powerpc] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [s390x] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [arm64] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [ppc64el] (yakkety-proposed) [16.04.3-0ubuntu2] [07:27] -queuebot:#ubuntu-release- New: accepted kidentitymanagement [i386] (yakkety-proposed) [16.04.3-0ubuntu2] [07:50] -queuebot:#ubuntu-release- Unapproved: upstart (xenial-proposed/main) [1.13.2-0ubuntu21.1 => 1.13.2-0ubuntu21.2] (core) (sync) [07:50] -queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu32 => 1.13.2-0ubuntu33] (core) (sync) [08:06] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-21.23] (core, kernel) [08:16] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-21.23] [08:26] -queuebot:#ubuntu-release- Unapproved: glibc (yakkety-proposed/main) [2.24-0ubuntu1 => 2.24-3ubuntu1] (core) (sync) === ant_ is now known as Guest48995 [08:36] -queuebot:#ubuntu-release- Unapproved: ubuntu-wallpapers (yakkety-proposed/main) [16.10.1-0ubuntu1 => 16.10.2-0ubuntu1] (ubuntu-desktop) [08:38] pitti: I have a fix for plasma-framework autotests, are you willing to sponsor the upload? that would unblock some britney migrations I think [08:38] cyphermox, jibel: Yay working uefi on secureboot again \o/ [08:38] -queuebot:#ubuntu-release- Unapproved: accepted upstart [sync] (yakkety-proposed) [1.13.2-0ubuntu33] [08:39] santa_: sure [08:39] ok. let me prepare the dsc [08:39] -queuebot:#ubuntu-release- Unapproved: accepted glibc [sync] (yakkety-proposed) [2.24-3ubuntu1] [08:39] I plan to try to fix more tests today, so we can get more things migrated [08:39] pitti: apw's all over that glibc, BTW. [08:39] infinity: oh, oops [08:39] And I have a d-i prepped to pick up new glibc and kernel once it publishes. [08:40] pitti, s'ok, i was litterally about to do the exact same [08:40] apw: sorry for mid-air collision then [08:40] let the autopkgtest queue fun begin :) [08:40] pitti, it is good we both reviewed it, and both were happy to hit the button on it [08:41] infinity, d-i> nice [08:42] pitti: http://gpul.grupos.udc.es/sponsor/plasma-framework_5.26.0-0ubuntu2.dsc [08:46] santa_: did you see my questions about the rebuilds for kidentitymanagement? [08:47] pitti: about the no-change rebuilds? [08:47] santa_: yes [08:47] -queuebot:#ubuntu-release- Unapproved: plasma-framework (yakkety-proposed/universe) [5.26.0-0ubuntu1 => 5.26.0-0ubuntu2] (kubuntu) [08:48] santa_: i. e. don't bother with sponsoring; I have a script for mass-rebuilds, I was just wondering if/which of those you need done [08:49] pitti: so let me see if I get you: we bumped the abi so the reverse depends must be rebuilt to depend on the abi1 package, right? [08:51] santa_: correct [08:52] santa_: some might need actual source chagnes if the API changed too (but I was assuming it's just some C++ ABI change) [08:53] pitti: if we get everything we have in -proposed migrated that wouldn't be needed [08:53] santa_: how do you mean? [08:53] santa_: you either finish the transiton or that kidentitymanagemnt upload will not land in yakkety (britney enforces this) [08:54] santa_: libkf5identitymanagement5 is NBS now, we can't release with that [08:54] pitti: because we have an script which bumps the version of the build depends, so everything build depending on kidentitymanagement is going to be built against >= 16.04.3 getting the right dependency on build time [08:55] so everything in -proposed would be fine [08:55] santa_: right; but I meant the packages which are already in yakkety (reverse-depends libkf5identitymanagement5) [08:55] even in -proposed [08:55] everything which has built before that kidentitymanagement upload [08:55] needs to be rebuilt [08:56] hmm [08:56] probably many would fail to build because iirc the API changed [08:57] 5 → 5abi1 just sounded like one of the usual C++ madness ABI changes, not a real API change? [08:58] if the API changed, why isn't this just 6? [08:59] because that could clash with a real upstream soname bump [08:59] the changelog also said "bug fix releaes", and the few removed functions like setUrl() just looked internal [08:59] well, if that actually changed API and upstream 5.26 isn't ready for that and the transition isn't being handled, then perhaps we shuold remove that version from y-proposed again [09:01] -queuebot:#ubuntu-release- Unapproved: accepted plasma-framework [source] (yakkety-proposed) [5.26.0-0ubuntu2] [09:01] -queuebot:#ubuntu-release- Unapproved: mesa (yakkety-proposed/main) [12.0.3-1ubuntu1 => 12.0.3-1ubuntu2] (core, xorg) [09:01] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-wallpapers [source] (yakkety-proposed) [16.10.2-0ubuntu1] [09:01] it's 16.04.3, it's a package from KDE Applications, not from KDE Frameworks [09:01] -queuebot:#ubuntu-release- Unapproved: accepted account-plugins [sync] (yakkety-proposed) [0.13+16.10.20160929.1-0ubuntu1] [09:02] pitti: can't be kidentitymanagement blocked from migrating to yakkety until all reverse depends are ready to migrate? [09:03] santa_: it's the other way around -- it won't migrate until all of them are [09:04] santa_: look at "trying: kidentitymanagement" in http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt [09:04] santa_: anyway, if you did not really intend to land this in yakkety, let's remove it now [09:04] santa_: otherwise the next KDE uplaod will build against it and get stuck [09:07] pitti: the idea was getting the complete set of kde apps 16.04.3 landing in yakkety, I don't see why it's a bad thing in the next uploads are built against kidentititymanagement 5abi1, because it's the way it's suposed to be [09:08] santa_: ok; then please upload them ASAP [09:08] pitti: they are already there, the only thing blocking us right now are the autotests [09:09] santa_: how do you mean "already there"? [09:09] in some PPA? [09:09] * pitti is really confused [09:09] pitti: nope, in -proposed [09:09] santa_: so the ones in -proposed need no-change rebuilds? [09:10] as everything which was not uploaded in the last hour or so was obviously not built against 5abi1 [09:11] pitti: what was not uploaded in the last hour wasn't built yet, it was in dep-wait because we have versioned build depends [09:12] santa_: aah! ok, that makes more sense [09:13] pitti: so now, this last upload of kidentitymanagement would unblock that dep-wait packages which will be built against the correct version [09:13] can I upload the update requrested in bug 1630557 ? [09:13] bug 1630557 in ubuntu-gnome-meta (Ubuntu) "FFE: Include Spice integration by default in Ubuntu GNOME" [Wishlist,New] https://launchpad.net/bugs/1630557 [09:19] -queuebot:#ubuntu-release- New binary: libkf5ksieve [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:21] -queuebot:#ubuntu-release- New binary: libkf5ksieve [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:21] -queuebot:#ubuntu-release- New binary: libkf5ksieve [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:22] -queuebot:#ubuntu-release- New binary: kf5-messagelib [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:25] -queuebot:#ubuntu-release- New binary: libkf5ksieve [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:25] -queuebot:#ubuntu-release- New binary: libkf5ksieve [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:25] -queuebot:#ubuntu-release- New binary: kf5-messagelib [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:25] -queuebot:#ubuntu-release- New binary: libkf5ksieve [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:26] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:26] -queuebot:#ubuntu-release- New binary: libkf5ksieve [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:27] -queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:27] -queuebot:#ubuntu-release- New binary: kf5-messagelib [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:27] -queuebot:#ubuntu-release- New binary: kf5-messagelib [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:31] -queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:31] -queuebot:#ubuntu-release- New binary: kf5-messagelib [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [09:33] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:33] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:33] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:33] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:33] -queuebot:#ubuntu-release- New: accepted libkf5ksieve [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:33] -queuebot:#ubuntu-release- New: accepted kf5-messagelib [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [09:49] -queuebot:#ubuntu-release- Unapproved: makedumpfile (yakkety-proposed/main) [1:1.6.0-2 => 1:1.6.0-2ubuntu1] (core) [09:50] cyphermox: meh hit a snag on hardware, Mokutil just says verfication failed(15) Access denied [09:51] -queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (yakkety-proposed) [1:1.6.0-2ubuntu1] [09:51] -queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (yakkety-proposed) [12.0.3-1ubuntu2] [09:53] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu480 => 20101020ubuntu481] (core) [09:54] pitti, have debian-installer ^ [09:58] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu481] [10:02] aah, glibc test madness incoming [10:02] moar workers! [10:03] apw: can't see it, but now I just see someone accepted it [10:04] pitti, that was me :) [10:09] pitti: Consider a late glibc upload a way to get a good baseline on tests before we flip over to SRUs. :P [10:09] :) [10:09] infinity: and it's getting too cold outside, so some heating can't hurt! [10:20] -queuebot:#ubuntu-release- Unapproved: upstart (yakkety-proposed/main) [1.13.2-0ubuntu33 => 1.13.2-0ubuntu34] (core) [10:21] Laney: ^ more obnoxious script changes to fix that race [10:21] Laney: (no changes since you tested it from people.u.c.) [10:23] infinity: I suppose we don't actually want to wait until *all* glibc tests finished? (if we do, we won't land anything in the next two days at least) [10:23] i. e. I'd let a few hundred of them run, and once we see enough green and only justifiable red I'll kill the remaining tests and we wave it through? [10:31] pitti: ack [10:32] pitti: Yeah, seems reasonable. The number of code changes is actually quite small. [10:46] apw, are autopkgtests which failed automatically restarted or does that need some manual steps. Just was looking at xenial libvirt for otehr reasons and the sru page says armhf failed. Though the log looks suspiciously like container problem. Did not see a button for retry myself. [10:50] smb, will have a llok [10:52] smb, concur, and i have clickd the button on it [10:52] -queuebot:#ubuntu-release- Unapproved: accepted upstart [source] (yakkety-proposed) [1.13.2-0ubuntu34] [10:53] apw, ah thanks. Is that button appearing for you from something the sru page points to or am I just blind? Well ok I am mostly blind anyhow... :-P [10:55] smb, they are on the britney progress pages for the release, i've dropped you a link in PM [10:55] apw, got it. thanks [10:56] * smb was trying to click his way through from the pending-sru page [10:56] smb, yeah not so much [11:16] apw, smb: excuses.html are not dynamic/per user/login, retry buttons appear for everyone (they just don't work for everyone) [11:17] pitti, yeah there is no connection from pending-sru.html to those buttons, i think that was the confusion [11:18] aah [11:25] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:28] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:28] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:30] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:32] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:33] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:34] -queuebot:#ubuntu-release- New binary: libkf5mailcommon [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [11:37] -queuebot:#ubuntu-release- Unapproved: foomatic-db (yakkety-proposed/main) [20160817-0ubuntu1 => 20161005-1] (desktop-core, ubuntu-server) (sync) === marcusto_ is now known as marcustomlinson [12:02] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.69 => 0.70] (ubuntugnome) [12:44] cjwatson, your opinion on a ghc sync -f? https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/?id=6c85e8fa057c35e85231ab95d955b954160e6520 and https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/p/ghc/debian?id=3354959ffaddb30572e3609841f20a26859323ff [12:45] the powerpc fixes might be useful [12:45] as well as the fPIE additions, that should be better than the existing hacks === marcusto_ is now known as marcustomlinson [12:46] I also propose myself in doing the rebuilds if you want to do a sync and a little transition [12:46] LocutusOfBorg: I'd recommend not at this point in the cycle; too difficult to get everything rebuilt in time if it turns out to break ABI [12:47] save it for z [12:47] unless it's actively getting in something's way (more than "might be useful") [12:47] I can do all the rebuilds in two days, but I agree [12:48] cjwatson, AFAIR we had some powerpc broken builds, and we kicked them out to let it transition [12:48] this patch should fix the failures [12:48] right, and leaving them kicked out is fine [12:48] but I agree [12:48] IME two days is very ambitious, and relies on builders being otherwise fairly idle, which they won't be [12:48] the point was to make you aware of the fixes, so expect a transition for yakkety+1 archive opening :) [12:48] it also means basically swamping the build farm to the exclusion of other things [12:49] sure, I have some scripts that do rmadison and uploads as soon as it is fine [12:49] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.6 (yakkety-proposed/main) [1:3.6.2-3ubuntu2 => 1:3.6.2-3ubuntu3] (kubuntu, ubuntu-desktop, ubuntu-server) [12:49] but I agree, there is no need right now, I was just wondering about making you aware of that fixes. [12:50] please accept that llvm fix ^^ :) I gave the patch to nacc, it is the usual regex fix to new gcc version [12:51] -queuebot:#ubuntu-release- Unapproved: clamav (yakkety-proposed/main) [0.99.2+dfsg-2ubuntu1 => 0.99.2+dfsg-2ubuntu2] (ubuntu-server) [12:53] FYI, the clamav will rely on llvm-toolchain-3.6 to be available [12:54] caribou, how? http://launchpadlibrarian.net/288556750/clamav_0.99.2+dfsg-2ubuntu1_0.99.2+dfsg-2ubuntu2.diff.gz [12:54] - llvm-3.6-dev, [12:54] + llvm-dev [i386 amd64 kfreebsd-amd64 kfreebsd-i386], [12:54] I see this change [12:55] this brings 3.8 as default llvm [12:55] LocutusOfBorg: my fault, [12:55] ok :) because I tested a no-change rebuild for clamav [12:55] After preparing the upload, I ran another test & forgot to roll it back [12:57] (mostly sleepless nights are no good for uploads) [12:58] :( even my prompt tells me I'm not on the right branch : |default_llvm*|caribou@avogadro:clamav [13:01] I always forget : can this clamav upload be kicked out so I can re-upload with the same version or do I need to increment it again ? [13:05] pitti: ↑ would be great if we could the libkf5mailcommon binaries in, so that would unblock more builds [13:05] "Dear Release Team, could you please disregard the latest upload of clamav which will definitively fail to build" [13:06] caribou: as long as it's in unapproved it can be rejected and you can reupload with same version number [13:06] caribou: once it's accepted, the version number is burned [13:06] pitti: yeah, thought so but wanted to be sue [13:06] sure [13:06] caribou: rejected [13:06] (Man! time to turn on the coffee machine again) [13:07] pitti: thanks! [13:07] -queuebot:#ubuntu-release- Unapproved: rejected clamav [source] (yakkety-proposed) [0.99.2+dfsg-2ubuntu2] [13:07] santa_: done [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:08] -queuebot:#ubuntu-release- New: accepted libkf5mailcommon [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [13:10] -queuebot:#ubuntu-release- Unapproved: clamav (yakkety-proposed/main) [0.99.2+dfsg-2ubuntu1 => 0.99.2+dfsg-2ubuntu2] (ubuntu-server) [13:22] I like this one more :) [13:25] cyphermox: give me a ping when you're online dude we need to have a chat about mokutil [13:26] -queuebot:#ubuntu-release- Unapproved: zfcpdump-kernel (yakkety-proposed/universe) [4.8-0ubuntu1 => 4.8-0ubuntu2] (no packageset) [13:27] -queuebot:#ubuntu-release- Unapproved: accepted zfcpdump-kernel [source] (yakkety-proposed) [4.8-0ubuntu2] [13:30] I am online [13:31] pitti: thanks, I have checked libkscreen autpkgtest and works fine here: http://gpul.grupos.udc.es/things/libkscreen_5.7.5-0ubuntu1_adt.log not sure why it fails on the official server [13:32] davmor2: what's going on? [13:35] cyphermox: hey dude, so if I select 3rd party drivers you add a password for mokutils. On reboot after install you then get a message that says verfication failed(15) Access denied on both hardware and vm [13:36] cyphermox: and that is in the blue mokutil screen rather than the black uefi screens [13:40] ok [13:41] oh [13:41] yuck [13:41] slangasek: ^ yay us [13:42] cyphermox: you're welcome [13:42] cyphermox: want a bug for that? [13:42] yes please [13:42] cyphermox, not the signed binary then ? [13:42] not really sure how we'll fix it though :/ [13:42] apw: what do you mean? [13:43] cyphermox, best to ignore me :) [13:43] shim is fine, but we're installing a different shim than the one built, yet installing the MokManager from the shim built from source -- what that means is that shim expects a particular one-time signature for MokManager, and doesn't get it, because we don't have the right stuffs [13:44] I suppose there will be more fudging to do :( [13:44] oh that is harsh [13:54] cyphermox: https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1631013 [13:54] Ubuntu bug 1631013 in mokutil (Ubuntu) "When triggering 3rd party driver during an install on reboot you get an error from mokutil" [Undecided,New] [13:58] apw: could you review grub2/grub2-signed from xenial queue? [13:59] cyphermox: on a plus side the image boots now :) [14:00] -queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.0.0~rc2-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server) [14:01] heh [14:01] I really would like for MS to just damn well sign our binary now so we could be done with this [14:02] cyphermox: yeah but that would be easy and everything [14:05] -queuebot:#ubuntu-release- Unapproved: barbican (yakkety-proposed/main) [1:3.0.0~rc1-0ubuntu2 => 1:3.0.0-0ubuntu1] (openstack) [14:07] pitti: are you working on lp:1626651 already? i'm gonna take a stab at it today, starting with the u-s-d side, but i want to coordinate with you if you're already in progress on it [14:07] https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651 [14:07] Ubuntu bug 1626651 in unity-settings-daemon (Ubuntu) "brightness keys are handled slower in Yakkety than Xenial" [High,Triaged] [14:08] jderose: not yet, too much other things, sorry [14:08] pitti: nah, don't be sorry :) [14:08] jderose: the actual fix is trivial (just flipping the pam.d config), the hard part is to ensure it doesn't break anything [14:09] pitti: yeah, that approach sounded scary to me and i don't have the needed experience there. but i figure i'll dig into the u-s-d side to first better understand what's going on, and hopefully come up with a low-risk solution that at least offers moderate improvement [14:10] jderose: halving it is easy, by not wrapping the "get" part into pkexec (that doesn't need any privs) [14:10] -queuebot:#ubuntu-release- Unapproved: telephony-service (yakkety-proposed/main) [0.1+16.10.20160909.1-0ubuntu1 => 0.1+16.10.20160927-0ubuntu1] (no packageset) (sync) [14:10] jderose: I actually wonder why this is still being used in the first place -- I had expected most platforms to support XBACKLIGHT [14:11] and that doesn't need any crazy pkexec helpers in the first place [14:13] pitti: looking at cking's original report plus the usd code, to me it looks like pkexec is only being used with --set-brightness, not with --get-brigtness or --get-max-brightness. but the later two still do this through calling usd-backlight-helper, so they still spawn a process (just not as heavy as spawning through pkexec) [14:13] jderose: I thought get would go through pkexec too [14:14] pitti: i know in some circles, /sys/class/backlight is now the preferred approach. i know gnome-settings-daemon (since usd was forked) as dropped use of xbacklight altogether. but this is problematic because the nvidia proprietary driver only supports xbacklight, no longer supports /sys/class/backlight [14:16] jderose: oh, I thought XBACKLIGHT was the modern one which can be done through xrandr and thus unprivileged (ICBW) [14:17] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.6 [source] (yakkety-proposed) [1:3.6.2-3ubuntu3] [14:18] -queuebot:#ubuntu-release- Unapproved: aodh (yakkety-proposed/main) [3.0.0~rc1-0ubuntu3 => 3.0.0-0ubuntu1] (openstack) [14:21] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [amd64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:21] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [ppc64el] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:21] pitti: as far as i can tell, just the set actions are using pkexec. if you compare backlight_helper_get_value() to backlight_helper_set_value() - http://bazaar.launchpad.net/~unity-settings-daemon-team/unity-settings-daemon/trunk/view/head:/plugins/power/gpm-common.c#L1257 [14:21] jderose: ah, good [14:22] only the later is wrapping the call with pkexec (seems the comment at the tom of backlight_helper_get_value() is out of date) [14:23] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [i386] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:25] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [arm64] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:26] pitti: one thing that stands out to me from cking's forkstat... doesn't it look like usd is doing everything 4 times? 4 for --get-max-brightness, 4 for --get-brightness, 4 for --set-brightness. like maybe instead of getting 1 event, it's getting 4? [14:26] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [armhf] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:27] jderose, it did seem like that when I ran it [14:29] cking: looking at what changed in usd since xenial, nothing stands out as something that could have introduced this. where do the events come from that usd is using? udev? [14:29] no idea where they come from [14:30] i think I tried and older 4.4 kernel and the same thing happened [14:30] *an older [14:31] jderose, the added cost of running pkexec is new i beleive, triggering systemd to do literrally 100s of things [14:31] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [powerpc] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:31] cking: yeah, saw that in your bug report. so thanks for ruling out the kernel :) [14:32] at that point I kinda thought it's something weird in the plumbing layer and I lost hope of fixing it easily [14:33] cking: something weird somewhere for sure :) [14:34] -queuebot:#ubuntu-release- Unapproved: glance (yakkety-proposed/main) [2:13.0.0~rc2-0ubuntu1 => 2:13.0.0-0ubuntu1] (openstack, ubuntu-server) [14:34] -queuebot:#ubuntu-release- New binary: libkf5calendarsupport [s390x] (yakkety-proposed/universe) [4:16.04.3-0ubuntu1] (no packageset) [14:35] cking: did you only notice this around the time you filed the bug, or were you experiencing this for a while before you filed the bug? [14:36] (just trying to narrow down the timeframe for when this was introduced) [14:36] jderose, about a day or so before it was drawn to my notice by somebody else with a Lenovo X230 so I tried it on my spare lenovo [14:36] so who knows when it started [14:37] apw: if the root problem pkexec being more expensive, is that something that can be addressed, or are these new expectations too deeply tied in already? [14:37] cking: okay, thanks [14:39] jderose, i don't think i know, i was just observing when it was being diagnosed, i thought pitti wrote up the issue pretty well [14:39] -queuebot:#ubuntu-release- Unapproved: snap-confine (yakkety-proposed/main) [1.0.42-0ubuntu3 => 1.0.43-0ubuntu1] (no packageset) [14:40] yeah, lots of great information in the bug. [14:41] jderose: yeah, hence my suspicion that pkexec was being used for get too [14:41] pitti: yeah, that would have been a nice, easy way to improve things [14:42] * apw is looking at snap-confine [14:43] -queuebot:#ubuntu-release- Unapproved: designate (yakkety-proposed/main) [1:3.0.0~rc2-0ubuntu1 => 1:3.0.0-0ubuntu1] (openstack) [14:45] -queuebot:#ubuntu-release- Unapproved: python-tooz (yakkety-proposed/main) [1.40.0-1ubuntu1 => 1.43.0-0ubuntu1] (ubuntu-server) [14:46] cyphermox: while I was trying things out on xubuntu with different themes (we've got an issue with theme and resize partition window there) I thought I would try Ubuntu using hi-contrast theme - ubiquity crashes - bug 1614848 [14:46] bug 1614848 in Ubuntu GNOME "ubiquity crashed with GLib.GError in configure_icons(): gtk-icon-theme-error-quark: Icon 'gtk-missing-image' not present in theme Adwaita (0)" [Critical,New] https://launchpad.net/bugs/1614848 [14:46] our issue is bug 1617711 [14:46] bug 1617711 in ubiquity (Ubuntu) "Resize screen hard to read" [Undecided,New] https://launchpad.net/bugs/1617711 [14:46] ack [14:47] -queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (yakkety-proposed) [1.0.43-0ubuntu1] [14:49] about the only theme you can sensibly see *our* resize window is numix, default is readable if you squint :p [14:50] ah, so it's straight theme fail? [14:50] apparently not according to ochosi [14:51] afaik there were some theme changes for gtk [14:51] ochosi> flocculant: if hi-contrast doesn't work it's a ubiquity bug, not a theme bug. plain and simple as that. [14:51] -queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.0~rc3-0ubuntu1 => 3:10.0.0-0ubuntu1] (openstack, ubuntu-server) [14:52] flocculant: how did you catch the gtk-missing-icon crash? does your icon theme not provide that icon? [14:52] flocculant: do you have a screenshot with adwaita? if not, no big deal, I'll pull today's images and look [14:52] cyphermox: I can get you whatever you need here pretty quick [14:53] as long as it takes to boot a vm [14:54] cyphermox: xubuntu using adwaita > http://i.imgur.com/GY1Lyja.png [14:55] thanks [14:55] so clearly not a theme fail, but a ubiquity bug because Gtk [14:55] pitti: on yaakety, is u-s-d no longer started by upstart? `status unity-settings-daemon` gives me "stop/waiting" on yakkety, but gives me "start/running" on xenial [14:56] cyphermox: and with high contrast > just so you've seen it :) http://i.imgur.com/nxSMm0u.png [14:56] such high contrast [14:56] jderose: no, moved: systemctl --user status unity-settings-daemon.service [14:56] jbicha: not a clue - I just ran ubuntu installer with high contrast, it crashed and then pointed me at ^^ bug [14:57] though there appear to be icons missing from ubuntu with that theme - like main icons system settings etc in the top menu bar [14:58] pitti: gotcha, thanks. well i guess that's one key difference between X and Y. can you think of any weirdness that might be introduced by running it under the systemd user session vs upstart? [14:59] jderose: not really from upstart → systemd; but it could certainly be influenced by the move to dbus-user-session [15:00] jderose: you can boot with the upstart session by disabling the /usr/share/upstart/systemd-session bit in /etc/X11/Xsession.d/00upstart [15:00] jderose: i. e. change the condition to "if false && [ "${1#*.target}" != "$1" ]" or comment out that block [15:01] pitti: okay, i'll give that a quick try for kicks. also, tell me more about this "dbus-user-session" of which you speak, please :D [15:02] jderose: this moves the dbus instance and user services like gvfs or pulseaudio from being per-session to per-user, i. e. the grpahical session and all VT/ssh logins share the same instance [15:02] pitti: if i start usd with upstart, will dbus-user-session still be used (sorry, i don't know anything about dbus-user-session) [15:02] jderose: yes, it will [15:02] jderose: you can also try to purge dbus-user-session (--force-depeds perhaps) [15:03] jderose: also, → #u-devel [15:03] okay, thanks. well, i'll hack around on this for a while, see if i can come up with anything [15:03] oops, yeah, would be better for #ubuntu-devel i guess :) [15:04] -queuebot:#ubuntu-release- Unapproved: heat (yakkety-proposed/main) [1:7.0.0~rc2-0ubuntu1 => 1:7.0.0-0ubuntu1] (openstack, ubuntu-server) [15:04] -queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.0~rc2-0ubuntu2 => 2:10.0.0-0ubuntu1] (openstack, ubuntu-server) [15:06] flocculant: /usr/share/icons/HighContrast/index.theme [15:08] but you ship gnome-icon-theme so that should work [15:09] jbicha: what's that for? if you're about ubiquity crashing with high contrast - that was in Ubuntu not Xubuntu [15:10] -queuebot:#ubuntu-release- Unapproved: networking-ovn (yakkety-proposed/universe) [1.0.0~rc2-0ubuntu1 => 1.0.0-0ubuntu1] (no packageset) [15:10] ok, well humanity-icon-theme ships that icon then [15:11] no idea - I was just telling cyphermox what I saw in ubuntu and what we are seeing in xubuntu [15:11] -queuebot:#ubuntu-release- Unapproved: accepted networking-ovn [source] (yakkety-proposed) [1.0.0-0ubuntu1] [15:11] -queuebot:#ubuntu-release- Unapproved: snap-confine (xenial-proposed/main) [1.0.42-0ubuntu3~16.04.1 => 1.0.43-0ubuntu1~16.04.1] (no packageset) [15:14] -queuebot:#ubuntu-release- Unapproved: akonadi (yakkety-proposed/universe) [4:16.04.3-0ubuntu1 => 4:16.04.3-0ubuntu2] (kubuntu) [15:16] pitti: ↑ fix for akonadi autopkgtests uploaded [15:18] santa_: cheers [15:19] flocculant: ubiquity with yakkety unity works here with high contrast [15:23] jbicha: it's all good I've got this covered [15:24] cyphermox: thanks [15:25] :) [15:25] jbicha: ok - I just used the latest daily *shrug*, only did that to check what we're seeing over where I do qa :) [15:29] -queuebot:#ubuntu-release- Unapproved: manila (yakkety-proposed/universe) [1:3.0.0~rc1-0ubuntu1 => 1:3.0.0-0ubuntu1] (openstack) [15:46] -queuebot:#ubuntu-release- Unapproved: openstack-trove (yakkety-proposed/universe) [1:6.0.0~rc2-0ubuntu1 => 1:6.0.0-0ubuntu1] (no packageset) [15:47] -queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (yakkety-proposed) [1:6.0.0-0ubuntu1] [16:05] * pitti cuts short the glibc tests, 'nuff green [16:07] will do some manual testing and the hinting when I'm back in ~ 3 h [16:09] pitti, ack [16:18] pitti: ≤ check on the version for matching - ugh, you pragmatist :) [16:20] pitti: glibc, I see a non-zero number of tests as red, have those all been confirmed to be not glibc's fault? [16:21] slangasek, i have spot checked a few and nothing jumped out, nothing systematic though [16:22] (and we should do something systematic) [16:23] * apw also notes that we are down to just wine causing NBS right now [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [amd64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [armhf] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [powerpc] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [s390x] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [arm64] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [ppc64el] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:24] -queuebot:#ubuntu-release- New: accepted libkf5calendarsupport [i386] (yakkety-proposed) [4:16.04.3-0ubuntu1] [16:27] -queuebot:#ubuntu-release- Unapproved: cpustat (yakkety-proposed/universe) [0.01.27-1 => 0.01.27-1ubuntu0] (no packageset) [16:28] -queuebot:#ubuntu-release- Unapproved: accepted cpustat [source] (yakkety-proposed) [0.01.27-1ubuntu0] [16:46] -queuebot:#ubuntu-release- Unapproved: accepted snap-confine [source] (xenial-proposed) [1.0.43-0ubuntu1~16.04.1] [16:52] hello folks,is here anybody who could ack the rules changes for the UITK release? https://bileto.ubuntu.com/#/ticket/2035 [16:53] anyone reviewing grub2/xenial? (it's the last piece to be able to say is at least in -proposed...) [16:53] pitti: slangasek: maybe ^^ [17:08] lamont, there is previous grub2 in the -proposed pocket -- does your base on that or not ? [17:09] apw: the request is to accept the one that's been sitting in unaccepted all this time [17:09] apw: specificly cyphermox' 2.02~beta2-36ubuntu3.4 from 3 days ago [17:10] oh, how about if I actually answer the question... gimme a mo [17:10] apw: 3.4 includes the stuff [17:10] or let him do that. :D [17:10] lamont, right but does it include the one which is already there, as that is currently marked verfication-fail [17:10] ta [17:10] yeah, verification-fail because you need the extra patches from 3.4 [17:10] apw: the new one is because I marked the old one failed [17:11] slangasek: you mentioned you had promoted taglibs-standard, no? [17:11] doko was asking me to review the MIR yesterday (and I just did now, anyway) [17:11] cyphermox: yes [17:11] apw: so onece 3.4 lands in porposed, I'll retest and mark the failed as done [17:11] cyphermox: it's a straight-swap for jakarta-taglibs-standard (source package rename), I've already demoted that one in exchange [17:12] slangasek: what about the packages that will need to transition to the new binary names eventually? [17:12] cyphermox, perfect thanks [17:12] slangasek: yeah, I know [17:12] cyphermox: didn't ever notice there was an MIR, I guess ~ubuntu-mir wasn't subscribed to it so it's not on the report [17:12] seems subscribed to me now *shrugs* [17:12] k [17:13] slangasek: I was more asking about did you talk to the server team about the reverse-depends that will eventually need to be updated? [17:13] cyphermox: no, because they're not server team packages [17:13] oh [17:13] this was the only revdep in main [17:13] ack [17:22] bzoltan: hmm, it looks like this is new build system code, and unlike for cmake, bileto doesn't have qmake awareness to include those build system diffs in the 'packaging' diff (robru?) but yes, I'll review them all and ack them [17:23] slangasek: thank you [17:24] bzoltan: so before this change, were these packages not being built with -fstack-protector, etc? [17:25] bzoltan: the bad thing about this implementation is that it's hard-coding flags that are supposed to come dynamically from the current toolchain policy. If the previous behavior was that these flags were not applied /at all/, then it's an improvement and better than nothing. But if the flags were previously picked up, then nack... [17:25] slangasek: some long time ago train attempted to include build systems in the packaging diff but then at some point it was decided to only care about debian/ [17:26] robru: it wasn't that long ago; was I part of the discussion to stop including the build systems diff? I might've been and don't remember [17:27] slangasek: i don't remember. It was over a year ago I'm sure. Probably i pushed for the change for simplicity sake and nobody objected [17:28] robru: ehm; "nobody objected" is not a valid policy change procedure [17:28] since this is a question of what kinds of changes require or don't require sign-off by core-devs before being uploaded to the archive, you should be expecting affirmative assent :) [17:29] slangasek: this was introduced as new flags with this change set - http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/2120 [17:30] robru: as I recall the build system diff was there so that we could see whether there really ought to be packaging changes for say, a new build dependency [17:31] slangasek: right, i don't recall all the details, it was quite some time ago. Probably only shortly after Didier left the project. [17:31] cyphermox: yeah that sounds right. [17:32] bzoltan: that doesn't answer my question of whether the build previously inherited the correct flags from the environment or not [17:36] robru: so my dim recollection is that we dropped this because *if* you're only changing the upstream build system and not changing the debian directory, it doesn't need review; and if you're changing both, there's a packaging diff (which triggers the check), and you have the full diff available for inspection separately if you want it [17:36] slangasek: seems reasonable [17:37] slangasek: yes the full diff is guaranteed to always be available as the packaging diff is created from that [17:39] -queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.0.0~rc3-0ubuntu1 => 2:9.0.0-0ubuntu1] (openstack, ubuntu-server) [17:44] -queuebot:#ubuntu-release- Unapproved: ironic (yakkety-proposed/universe) [1:6.2.0-0ubuntu2 => 1:6.2.1-0ubuntu1] (openstack) [17:51] slangasek: the dpkg-build flags were correctly applied at package build before and after this change, at packaging build it's actually exactly the same flags before and after, loicm made this change because the dpkg-build flags are stored in qmake mkspecs files (that comes from the qtbase pacakging) and, before this change, were always applied when building the toolkit for development (!debuild) causing a bunch of issues: incompatibility [17:51] with compilers other than GCC, -g forced even in release builds, etc [17:51] slangasek: so yes, the right flags were applied before, and are still applied now [17:52] bzoltan: right, but the difference is now you're *hard coding* the flags in your package, which means that when they change, your package will not follow [17:55] bzoltan: and indeed, the hardcoded flags are already different than what we're applying in yakkety today [17:55] because we use -fstack-protector-strong in yakkety, but this is not supported by older toolchains [18:01] -queuebot:#ubuntu-release- Unapproved: cdist (yakkety-proposed/universe) [4.3.1-2 => 4.3.1-2build1] (no packageset) [18:01] slangasek: yes we are hard-coding the flags, but these hard-coded flags are used only when debian_build is not defined and if you look at debian/rules debian_build is passed to qmake, that allows us to have almost the same flags applied when building the toolkit for development purpose and when it's built on CI, and to spot issues early. The only difference is that these hard-coded flags are applied in a more qmake friendly way. Just when GCC is used, [18:01]