[00:09] <jbicha> clivejo: kdevelop-php-docs is just a transitional package so there's no need to remove it
[00:10] <jbicha> if you want it to get out of zesty-proposed, you need to stop having the kde langpacks depend on kdevelop-php-docs-l10n
[00:12] <jbicha> run the reverse-depends command I posted earlier to see which packages I'm talking about
[01:18] <cyphermox> can someone please review grub2 and grub2-signed from zesty unapproved queue (because EFI signing), and review the grub2/grub2-signed SRU for xenial?
[02:01] <nacc> clivejo: sorry, i was afk, hopefully it made sense from what cjwatson and jbicha said
[05:14] -queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (xenial-proposed) [20160930-0ubuntu3~16.04.0]
[05:58] <Mirv> can you fix unity8 main <-> universe problems leading to uninstallable reports? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 those are not new dependencies so apparently something auto-demoted?
[05:59] <Mirv> acheronuk: ^
[05:59] <Mirv> there's always another thing around the corner with Qt transitions, I recommend not holding breathe :)
[06:00] <Mirv> there was a new qtmir, qtubuntu, unity8 release to proposed last night. that didn't however contain anything that should cause any problems, other than possible delays.
[06:02] <Mirv> also, many of the problems cannot be solved by core devs like this promoting of packages, so we need to wait
[07:01] <ginggs> Would someone please 'force-badtest python-astropy/1.3-4ubuntu4/armhf' and 'force-badtest python-astropy/1.3-4ubuntu4/s390x'? The new test failing with SSL: CERTIFICATE_VERIFY_FAILED is definitely not due to numpy. I think it is due to the armhf and s390x test runners being containers not VMs
[07:37] <apw> ginggs, are we going to fix that test ?
[07:38] <ginggs> apw: yes, i'll look into that and the rest of the python-astropy test failures (Debian switched from convenience copies to external modules for a bunch of things and the dependencies aren't right just yet) as soon as numpy migrates
[07:49] <apw> ginggs, ok done
[07:51] <ginggs> apw: thanks!
[07:52] <Mirv> apw: can you see about the promotions too?
[07:53] <Mirv> ie http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
[07:53] <Mirv> apw: oh sorry, my mistake, they _are_ new dependencies to unity8-tests
[07:53] <Mirv> Saviq: ^
[07:56] <Mirv> apw: Saviq: so only qt5-default could be promoted, xvfb, parallel and dbus-test-runner AFAIK don't have MIR. this's blocking Qt 5.7.1 transition.
[07:57] <Mirv> Saviq: please consider reverting the conflicting changes to unblock Qt, MIRing could take some time
[08:05] -queuebot:#ubuntu-release- New binary: python-parse [amd64] (zesty-proposed/universe) [1.6.6-0.1~build1] (no packageset)
[08:12] <Mirv> ok, xvfb could also be promoted, parallel and dbus-test-runner not
[08:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (zesty-proposed) [2.02~beta3-3ubuntu2]
[08:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (zesty-proposed) [2.02~beta3-3ubuntu2]
[08:15] <Mirv> and this is the branch that got landed last night https://code.launchpad.net/~unity-team/unity8/installed-qmltests/+merge/293443
[08:39] <Saviq> Mirv, apw, https://launchpad.net/bugs/1656104
[08:40] <Saviq> gargh, Mirv can you please recycle http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#qtmir with all-proposed=1, thanks (and we need to skip that test, thought we've managed to stabilize it already)
[08:42] <Mirv> Saviq: ah, great! thanks. and recycling
[09:21] <oSoMoN> can someone please have a look at webbrowser-app in https://people.canonical.com/~ubuntu-archive/pending-sru.html ? there shouldn’t be anything preventing the migration from -proposed to -updates, I guess it’s just a matter of someone ack'ing it?
[09:57] <LocutusOfBorg> cmake revert done /cc xnox
[10:33] <Mirv> archive admins: when around, please handle bug #1656104 to continue with the Qt 5.7.1 transition
[11:39] <sil2100> rbasak, bdmurray, apw: hey! I'm re-checked linux-firmware SRU from the xenial queue and with the SRUified bugs all seems to be clear and good for accepting - could anyone double-check for me before I approve it? (since I'm still in training)
[12:09] <sil2100> bdmurray: also, do you know if we need to always wait the 7-day period for SRUs before letting them into -proposed? I'm asking since I re-released that dbus package with the revert - do we have to wait another 7 days before accepting that?
[12:09] <sil2100> bdmurray: the fix is already long long overdue
[12:09] <sil2100> And was tested hundreds of times
[12:10] <rbasak> sil2100: if it's a straight revert (new upload exactly the same as the original one except changelog), then that's one of the cases that I think we can skip the aging period.
[12:11] <rbasak> sil2100: if it's not a straight revert (further attempt to fix the problem) then I think we should wait since that risks further regression. Which is why I also think a straight revert is the appropriate first step to handle a regression except where we think it'll make the problem worse.
[12:12] <sil2100> rbasak: yeah, it's a bit complicated, but one could think of it as a 'straight revert'
[12:13] <sil2100> rbasak: since we had dbus with 2 fixes, one got verified fine and the other failed, so I reuploaded with just the one fix that was verified - the revert was a simple revert of an upstart file to the original contents
[12:14] <sil2100> Just waiting for the autopkgtests to re-run and I'll opt for getting it in
[12:15] <rbasak> IMHO, that's not a straight revert, and in the general case there's potential for an unexpected interaction by landing only half the SRU.
[12:15] <rbasak> I agree it's subjective.
[12:18] <sil2100> Seeing the changes to me personally it's a straight revert as both two fixes were isolated changes, so reverting one cannot impact the other fix
[12:18] <rbasak> OK
[12:18] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu14 => 229-4ubuntu15] (core)
[12:18] <sil2100> As we're only really using upstart on ubuntu-touch, where the reverted change actually caused a regression
[12:20] <sil2100> But yeah, I'll leave this to you veteran SRUers to decide, I just know this dbus bug is high-heat with a rather annoying priority that should have been fixed-released many weeks ago already
[12:20] <sil2100> So I wouldn't want it to linger around for no reason
[12:23]  * rbasak isn't a veteran!
[12:23] <Laney> Probably don't want to release it on a Friday anyway ;-)
[12:24] <didrocks> Laney: anything to say on new release on Friday? :p
[12:24] <didrocks> be warned! ;)
[12:25] <Laney> didrocks: I heard you have 24/7/365 on-call coverage
[12:25] <didrocks> Laney: good answer, and pretty much accurate right now :-)
[12:26] <slangasek> can I get expedited SRU review of the above systemd SRU?  It's thought to address an emergent regression introduced by changes in NVME support in the kernel, and blocks being able to run MAAS-based CI against machines with NVME
[12:26] <slangasek> there's an existing SRU in xenial-proposed which hasn't been verified; we should just stack them
[12:28] <sil2100> I could, but I am but a newb so someone would anyone have to double-check before I can approve it
[12:28] <sil2100> Since bdmurray said I still need to do some coordinated reviews for now
[12:31] <sil2100> slangasek: are all those patches present in systemd 323-10 from zesty? Or is that one not affected?
[12:36] <rbasak> Is rharper happy to have the aging clock and verification reset?
[12:41] <rbasak> slangasek: I'm not convinced about the reason for the urgency here. It looks like NVMe support was added in an SRU in November, and was done wrong. So surely we need to take more time and care this time, not less?
[12:42] <rbasak> How long has this had time to bake in Zesty? It's not marked Fix Released yet.
[12:46] <rbasak> sil2100: linux-firmware in xenial lgtm to accept.
[12:47] <slangasek> rbasak: the NVME support was added in the kernel publication cycle that released to -updates at the beginning of this year
[13:02] <slangasek> rbasak: urgency reduced; we have questions about whether the urgent problem is fixed by this particular patch.  The SRU itself is still good and needful and fairly high prio, it just may not fix the problem people are seeing in MAAS
[13:05] <rbasak> slangasek: OK. I feel that this reinforces my opinion that the right thing to do here is slow down and fix it carefully rather than throwing patches into the SRU process.
[13:07] <sil2100> rbasak: thanks!
[13:08] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.8]
[13:16] -queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (xenial-proposed/main) [1.8.3-1ubuntu0.2 => 1.8.3-1ubuntu0.3] (kubuntu, ubuntu-desktop)
[13:18] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.24+16.10 => 2.25+16.10] (no packageset)
[13:49] <Saviq> now that unity8-tests is demoted #1656104, any idea why britney still didn't run the tests for unity8 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 ?
[13:50] <Saviq> hmm or maybe it just didn't update, they seem to be running
[13:52] <Mirv> Saviq: it's just slow, now they're running
[13:52] <Saviq> Mirv, yeah, sorry for the noise
[13:52] <Mirv> Saviq: if you'll be around, please observe, ask for all-proposed=1 runs if they're not run like that, and then hopefully someone in the US timezone reading this channel can parse update_output.txt to see where the next problem lies
[13:53] <Mirv> it's hard to see much before unity8 is again valid candidate though
[13:53] <Mirv> I don't now immediately remember if those old binaries need to be deleted before migration happens? basically bug #1655290 + now also that unity8-fake-env
[13:53] <Saviq> Mirv, they don't need all-proposed, since they actually depend on Qt 5.7 - they're actually running the tests now
[13:53] <Mirv> Saviq: great, some time saving there at lest
[13:54] <Saviq> Mirv, qtbase seems a valid candidate, so should migrate
[13:54] <Saviq> not sure why it didn't, yet, tbh
[13:56] <Mirv> Saviq: it's far from that simple
[13:56] <Saviq> ok ;)
[13:56] <Mirv> Saviq: one needs to also decipher the "
[13:56] <Mirv> Trying easy from autohinter" sections from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[13:56] <Mirv> after everything is valid candidate on the excuses page. there might be something lurking.
[13:57] <Saviq> aha
[13:57] <acheronuk> Good luck with that
[13:57] <Mirv> Saviq: but the first blocker now is qtbase can't migrate without Unity 8 that is built against it
[13:57] <Saviq> Mirv, right right
[13:58] <acheronuk> I did degree and PhD in physics with quantum silliness, and a page of that still makes more sense than the update_output.txt
[13:58] <Mirv> last night it was qtquickcontrols depending on a non-promoted package (although MIRd). it was fixed but then U8 landed, not sure if there was a moment the migration could have happened or at least showed the next problem.
[13:59] <Mirv> the day before that it was pyqt5 not getting built because a newer version of it was autosynced from Debian that required qtwebengine that was in NEW queue
[13:59] <Mirv> so day by day, new problems arise and they are sorted out a bit too slow to win this game :)
[13:59] <Mirv> acheronuk: heh
[14:00] <Mirv> so that's why it's a wishlist item for US timezone archive/release team members to observe and fix these problems as seen, as often it needs them to happen
[14:01] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.24 => 2.25] (no packageset)
[14:02] <Laney> Mirv: Things will have to be deleted if they show up as 'old binaries left' on excuses
[14:02] <Laney> so just the fake-env I think
[14:03] <Mirv> Laney: right, so that's why I filed the bug on Tuesday. hmm, right, maybe someone fixed those without marking the bug as fixed then, it seems the rest have disappeared.
[14:03] <Laney> maybe, check with rmadison
[14:03] <Laney> webbrowser-app -> unity8 seems red fwiw
[14:04] <Mirv> rerunning those
[14:05] <Laney> also, http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_output_notest.txt is useful to see what would happen if all tests were passing
[14:05] <Laney> so you can get out in front of some problems
[14:05] <Mirv> right, the previous RM packages are not in zesty-proposed anymore. good.
[14:05] <Mirv> oh! that's new to me.
[14:07] -queuebot:#ubuntu-release- Unapproved: gnome-calculator (yakkety-proposed/main) [1:3.22.0-1ubuntu1 => 1:3.22.2-1ubuntu0.1] (ubuntu-desktop)
[14:07] <Mirv> ok, there are some problems left there too
[14:07] <Laney> unity8 is because of what I just mentioned
[14:07] <Mirv> there is also ginga and yade at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pyqt5
[14:08]  * Laney lunch
[14:08] <Mirv> failing to find python modules
[14:08]  * acheronuk booksmarks that link
[14:11] <slangasek> rbasak: ok, we've root-caused the MAAS thing for sure, and yes it is actually fixed by this systemd change so yes it is urgent
[14:12] <slangasek> rbasak: and this is a necessary SRU change /anyway/, we just weren't sure how it related to the MAAS regression
[14:16] <bdmurray> sil2100: Its a 7-day period for letting them into -updates and in the dbus case I was going to look at releasing it on Monday.
[14:21] <slangasek> bdmurray: hi, looks like rbasak may be EOD; could you take a look at the systemd in xenial-proposed/unapproved, per the above discussion?
[14:21]  * rbasak unaways himself from yesterday. Sorry!
[14:21] <slangasek> oh :-)
[14:23] <Mirv> I see also ginga and yade failures with the release pocket version of pyqt5 in some of the logs, so I don't think they are related: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src maybe those could be force-badtest'd
[14:24] <rbasak> slangasek: what's the status of this in Zesty please?
[14:26] -queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9ubuntu2 => 231-9ubuntu3] (core)
[14:26] <slangasek> rbasak: I just finished uploading to yakkety, I will have it fixed in zesty before tonight but I don't have anyone else blocking on me for rolling test images on zesty
[14:26] <rbasak> I'm struggling to understand why this is so urgent. Is there some kind of regression that I've misunderstood?
[14:27] <slangasek> rbasak: yes there is a regression
[14:27] <jgrimm> yes systems that previously worked... no longer do
[14:27] <sil2100> bdmurray: yeah, that's what I was recommending, to let it in earlier than after 7-days - you mean you want to copy it over to -updates on Monday?
[14:27] <sil2100> bdmurray: I would be +1 on that in that case
[14:27] <rbasak> Did these systems work before Nov 2016?
[14:27] <jgrimm> yes
[14:28] <rbasak> And was it bug 1642903 that caused the regression, but only triggered now by the kernel update?
[14:28] <slangasek> rbasak: kernel changed to now be able to expose the nvme id via sysfs. systemd was uploaded to create symlinks in /dev/disks/by-id for these disks.  Disks which have whitespace in their model or serial number now get bad symlinks created.  MAAS relies on this symlink being present and correct if the serial was detected at all
[14:28] <slangasek> rbasak: therefore, maas fails to provision any system with an attached nvme disk whose serial and/or model contains whitespace
[14:29] <slangasek> and this is fixed by this SRU, which was the next thing we already knew we needed to do for systemd
[14:29] <slangasek> smoser: ^^
[14:29]  * rbasak reads up
[14:30] <smoser> slangasek, did systemd upstream agree with the fix we proposed ?
[14:30] <smoser> last i saw that was not decided.
[14:30] <slangasek> smoser: yes, it's landed on trunk
[14:30] <smoser> great.
[14:31] <rbasak> slangasek: would reverting the change from bug 1642903 fix the problem?
[14:32] <slangasek> rbasak: I don't know that it would; I don't believe it would
[14:32] <slangasek> rbasak: because I think maas picks up on the id as soon as it's in sysfs, regardless of what udev tries to do with it
[14:34] <slangasek> rbasak: and anecdotally, I'm hearing that things have been broken for maas users well before that previous systemd sru went in
[14:34] <rbasak> I'm just trying to consider the minimal things that could fix the problem first. So next: is there a possibility of a more minimal patch than the full fix upstream?
[14:35] <slangasek> rbasak: that full fix is precisely the set of patches Canonical's STS engineer sent upstream for addressing this issue
[14:35] <barry> Laney: ping
[14:35] <smoser> maas commissioning that gets the serial number (and thus causes installtion to use serial path) is probably not dependent on the symlinks.
[14:35] <slangasek> right; else it would never have seen a mismatch
[14:35] <rbasak> slangasek: I agree that the fix upstream seems like the correct long term fix. But we're in a hurry, and the proper fix has had very little time to bake. What's the chance that we'll find a problem with that fix again?
[14:36] <rbasak> slangasek: OTOH, a stop gap simple-but-obviously-correct workaround might have lower regression risk.
[14:36] <slangasek> rbasak: non-zero, non-quantifiable, and lower than the chance that I'll time out here given that we're past EOD already at the sprint, and be unable to make any further changes until after the weekend ;)
[14:37] <slangasek> though I guess that is a sort of quantifying ;)
[14:39] <rbasak> OK, well let me finish reviewing these three patches anyway, and see what I think after that.
[14:39] <rbasak> I also won't be offended if you would prefer to pass this to another ~ubuntu-sru.
[14:40] <slangasek> rbasak: I do appreciate the caution; I will say ftr that I am confident in this approach with my SRU hat, and would have accepted it myself if not for the fact that ddstreet's git branches couldn't be used directly but needed refactoring
[14:41] <rbasak> OK
[14:41] <rbasak> Thanks
[14:44] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.25+16.10]
[14:46] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.25]
[15:17] -queuebot:#ubuntu-release- Unapproved: xorg-server-lts-xenial (trusty-proposed/main) [2:1.18.4-0ubuntu0.2~trusty1 => 2:1.18.4-0ubuntu0.2~trusty2] (no packageset)
[15:27] -queuebot:#ubuntu-release- New binary: pluma [ppc64el] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:29] -queuebot:#ubuntu-release- New binary: pluma [i386] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:31] -queuebot:#ubuntu-release- New binary: pluma [arm64] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:31] -queuebot:#ubuntu-release- New binary: pluma [armhf] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:32] <cyphermox> rbasak: do you have time to review my grub2 SRU for xenial?
[15:33] <rbasak> cyphermox: sorry, swamped.
[15:33] -queuebot:#ubuntu-release- New binary: pluma [s390x] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:35] -queuebot:#ubuntu-release- New binary: pluma [powerpc] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:35] <tjaalton> xnox: xorg-server-lts-xenial uploaded
[15:35] <sil2100> bdmurray: can I approve the new gst-plugins-good1.0 SRU for xenial? Looks good to me, and makes sense to re-base the current -proposed version with the new security fix that went into -security already
[15:36] -queuebot:#ubuntu-release- New binary: pluma [amd64] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)
[15:37] -queuebot:#ubuntu-release- Unapproved: kombu (trusty-proposed/main) [3.0.7-1ubuntu1 => 3.0.7-1ubuntu1.1] (kubuntu, ubuntu-server)
[15:40] <bdmurray> sil2100: yes, looks good
[15:40] <xnox> tjaalton, tah.
[15:40] -queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (xenial-proposed) [1.8.3-1ubuntu0.3]
[15:43] <Laney> hi barry
[15:44] <barry> Laney: hi.  we've been seeing some new regressions on ubuntu-image promotion in zesty but only on armhf.  related to failures in devmapper
[15:44] <barry> Laney: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/u/ubuntu-image/20170111_171929_431b1@/log.gz
[15:44] <barry> Laney: are you aware of any recent-ish changes to the autopkgtest infra that might explain this?  it's 100% reproducible in the sense that retries do not help
[15:45] <Laney> nope
[15:45] <barry> Laney: cyphermox has been trying to repro on his local h/w but no luck, and i don't have an armhf box here to test it with
[15:45] <Laney> have you tried using lxd on a different arch?
[15:45] <barry> Laney: not yet. ;)
[15:46]  * barry had some trouble with lxd but before this promotion problem
[15:46] <barry> and before i upgraded to zesty.  i need to try that tho
[15:49] <Laney> barry: looks like the older version ran again and passed? http://autopkgtest.ubuntu.com/packages/ubuntu-image/zesty/armhf
[15:49] <sil2100> bdmurray: thanks!
[15:52] <xnox> bdmurray, do you mind accepting https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=xorg-server-lts-xenial on top of current xorg-server-lts-xenial sru? =)
[15:52] <xnox> should be mostly harmless
[15:52] <barry> Laney: well, that's weird.  i can't think anything that has changed in that part of u-i
[15:52]  * xnox ponders if in ~ubuntu-sru training book "xnox asking for accept" is a major red flag or not =)
[15:53]  * barry retries
[15:54] <xnox> barry, Incompatible libdevmapper 1.02.136 (2016-11-05) and kernel driver (unknown version). hm, kernel upgrade & reboot without maching lvm/devmapper kernel modules loaded on the host side?
[15:54] <barry> xnox: in the buildds?
[15:54] <xnox> barry, note armhf tests are run in containers on arm64 machines. So possibly you need arm64 kernel modules installed, and/or make arm64 machines have needed modules loaded.
[15:56] <barry> i really think i need to get lxd running on this new zesty install
[16:01] <Laney> barry: yeah, fails like that for me locally in lxd with ubuntu2
[16:02] <barry> Laney: *very* interesting
[16:02] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.7]
[16:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.7]
[16:05] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server-lts-xenial [source] (trusty-proposed) [2:1.18.4-0ubuntu0.2~trusty2]
[16:25] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.7] (core)
[16:33] <barry> Laney: i can't seem to start any armhf containers on amd64: http://paste.ubuntu.com/23792953/ (doesn't really matter if x, y, or z distroseries)  amd64 is no problem
[16:34] <Laney> barry: right, I wouldn't expect that to work, I just did amd64 on amd64
[16:34] <Laney> dev/canonical/release/autopkgtest/runner/autopkgtest --apt-pocket=proposed=src:ubuntu-image --apt-upgrade ubuntu-image --env=ADT_TEST_TRIGGERS=ubuntu-image/0.13+17.04ubuntu2 --test-name mount -- lxd autopkgtest/ubuntu/zesty/amd64
[16:34] <Laney> ^- failed
[16:35] <barry> Laney: oh, i thought you did try armhf.  so the failure is any container based autopkgtest
[16:35] <Laney> I guess so
[16:35] <barry> Laney: okay!  that's at least a clue.  thanks
[16:38] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.7] (core)
[17:04] <apw> that is definatly hinky ^
[17:06] <apw> oh no, that is just the binary bits ...
[17:07] <cyphermox> apw: it's a side-effect of grub2 requiring EFI signing
[17:07] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.7]
[17:07] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.7]
[17:08] <cyphermox> however, wat.
[17:08] <cyphermox> s390 ftbfs?
[17:08] <cyphermox> oh, and no log
[17:09] <barry> Laney: did you get a ftbfs in the container or a failure in the autopkgtest?
[17:11] <Laney> barry: the test failed, I don't think it rebuilt
[17:12] <barry> Laney: okay, yeah, i get two test failures during package build which appear to be sparse file related.  that's different than what we see on the infra (there it builds fine on armhf but fails its devmapper/mount a-p-t).  just wanted to confirm you're seeing what i'm seeing
[17:13] <Laney> barry: I saw the same as that autopkgtest log you linked
[17:13] <Laney> except I only ran that 'mount' test
[17:14] <barry> Laney: ah, ok
[17:23] -queuebot:#ubuntu-release- New binary: puppet [amd64] (zesty-proposed/universe) [4.8.1-2] (no packageset)
[17:31] <barry> Laney: sorry to keep bugging you, but in the container you tried, is /tmp a zfs file system?
[17:31] <Laney> umm
[17:32] <Laney> I don't *think* so
[17:32] <Laney> give me 10 minutes to run it again
[17:33] <barry> Laney: okay thanks.  i ask because apparently the image that autopkgtest-build-lxd gives you does use zfs for /tmp and apparently zfs behaves differently for `truncate -s 1000000 /tmp/foo`.  if you stat /tmp/foo you end up with st_blocks == 1 instead of 0 which you definitely get on ext4
[17:34] <barry> (which will cause two unittests to fail)
[17:35] <Laney> barry: lxd/containers/autopkgtest-lxd-ubfhza on / type zfs (rw,relatime,xattr,noacl)
[17:35] <barry> Laney: could you please try the following:
[17:35] <barry> truncate -s 1000000 /tmp/a
[17:35] <barry> stat /tmp/a
[17:35] <barry> Laney: how many blocks does that report?
[17:36] <Laney> 1
[17:37] <barry> Laney: okay, that's what i get.  did you run the tests against the build binary packages in z-proposed perhaps?  i.e. did you build the source package in the container or use pre-build binaries?
[17:37] <barry> *built binary packages in z-proposed
[17:37] <Laney> barry: I used that ^ command which doesn't rebuild unless the test asks for it
[17:38] <barry> Laney: awesome, thanks.  that confirms it.
[17:43] <Laney> barry: Glad you were able to understand the issue :-)
[17:44] <barry> Laney: one less hirsute yak
[17:44] <Laney> at least the clippings will keep you warm this winter
[17:44] <barry> Laney: :D  we'll need it for the ice storm tomorrow (which, of course, because i have a gig)
[17:46] <Laney> barry: http://www.bbc.co.uk/news/live/uk-38601592 <- some really REALLY extreme conditions on there
[17:46] <Laney> (bahaha)
[17:47] <barry> yikes
[17:47] <barry> well, at least that'll be year round when the jetstream collapses
[17:48] <Laney> snowpocalypse... 2" later
[17:48]  * Laney saw a flake this morning and had to go back to bed
[17:49] <barry> is that like, see some roadkill and think zombie apocalypse?
[17:49] <cjwatson> I'm not sure that wouldn't improve the UK
[17:50] <Laney> It'll be hard to distinguish reality from zombie apocalypse if I head into town tonight
[18:18] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu15]
[18:19] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9ubuntu3]
[18:38] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.3-0ubuntu4~16.04.2]
[19:25] <dmj_s76> infinity: Any idea when the kernel and the rest of the HWE stack will land in the xenial daily iso?
[20:25] <acheronuk> hi. Qt still seems to be blocked on these old binaries? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
[20:26] <acheronuk> is anyone able to sort those?
[20:37] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.20.1~14.04 => 2.21~14.04] (no packageset)
[20:37] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.20.1+16.10ubuntu2 => 2.21+16.10] (desktop-core, ubuntu-server)
[20:37] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.20.1ubuntu1 => 2.21] (desktop-core, ubuntu-server)
[20:57] <infinity> acheronuk: Fixed.
[20:58] <acheronuk> infinity: thank you :)
[20:58] <acheronuk> it's bound to block on something else now, but each step helps....
[22:47] <acheronuk> yep. Qt 5.7.1 still well and truly stuck, and staring at update_output.txt is doing me no favours
[23:16] <nacc> acheronuk: aiui, it looks like a bunch of packages become uninstallable if hte updated qt goes in?
[23:20] <acheronuk> nacc: that much I get. it is tracing the few likely root causes of that which is tricky. the output is not overly helpful in that regard
[23:21] <nacc> acheronuk: yeah, it seems like it's a whole pile of stuff all at once :)
[23:22] <nacc> acheronuk: i tend to try and reproduce it with a chdist
[23:22] <nacc> for instance, i can reproduce the src:qtsensors-opensource-src failure in my z-p chdist
[23:23] <acheronuk> chdist? chroot?
[23:23] -queuebot:#ubuntu-release- New binary: hiro [amd64] (zesty-proposed/universe) [0.2-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: redis-py-cluster [amd64] (zesty-proposed/universe) [1.3.3-1] (no packageset)
[23:23] <nacc> acheronuk: http://manpages.ubuntu.com/manpages/trusty/man1/chdist.1.html
[23:24] <nacc> although of course using a more recnet version
[23:24] <nacc> let's yuo basically fake a apt setup without having to use a chroot (although it should be reproducible there too)
[23:24] <acheronuk> ah, that jogs a memory now
[23:25] <acheronuk> may try that tomorrow when my patience has returned
[23:25] <nacc> so for http://paste.ubuntu.com/23795038/ I got http://paste.ubuntu.com/23795037/
[23:25] <nacc> e.g.
[23:25] <nacc> acheronuk: not saying it will really help, but maybe if you have more context, it might point you in the right direction
[23:27] <acheronuk> any clue is better than 'no clue' :P
[23:30] <nacc> acheronuk: agreed :)
[23:34] <nacc> clivejo: hey, looking at it, there are only two binaries produced by src:kdevelop-php-docs (kdevelop-php-docs and kdevelop-php-docs-l10n). Both are also produced by src:kdevelop-php now, it seems, so I think what is actually needed is a deletion of src:kdevelop-php-docs from z-p and z?
[23:35] <clivejo> thats KDE4 version AFAIK
[23:36] <clivejo> Debian must be keeping both KDE4 and KF5 versions
[23:36] <nacc> clivejo: right, and it seems like (iiuc) the versions in z are all KDE5 now, and the dependencies on those two binary packages are being satisifed by the KDE5 version?
[23:37] <clivejo> but I dont understand why we are syncing KDE4 stuff
[23:37] <nacc> clivejo: i'm not sure, you do need an AA to fix this, i think, but it's becuase we at one point or another did sync src:kdevelop-php-docs from debian
[23:38] <nacc> clivejo: that src is still published in debian (albeit only in stable)
[23:38] <nacc> clivejo: and a transition happened, probably in debian, that didn't get trnaslated correctly to ubuntu
[23:38] <nacc> but i'm not 100%
[23:39] <jbicha> nacc: src:kdevelop-php-docs contains a transitional package; there's no reason to delete if from Ubuntu now
[23:40] <jbicha> I don't think you need an AA but you need to not have anything depend on kdevelop-php-docs-l10n any more
[23:40] <nacc> jbicha: why? kdevelop-php-docs-l10n is provided by src:kdevelop-php now
[23:40] <nacc> it was a binary package migration between two src packages, afaict
[23:41] <nacc> so no there is a binaryless src (kdevelop-php-docs)
[23:41] <jbicha> nacc: no, -l10n was dropped in the zesty-proposed package and therefore it can't migrate until the packages that depend on it no longer depend on it
[23:41] <nacc> jbicha: huh? it's in the release pocket already
[23:41] <jbicha> https://launchpad.net/ubuntu/+source/kdevelop-php-docs
[23:43] <nacc> jbicha: but those binaries already exist in relase from a *different* src pkg
[23:44] <jbicha> oh I see, but still I think it would be a good idea for Kubuntu to fix the packages that depend on that -l10n pkg
[23:44] <nacc> i know nothing about kde or any of this, admittedly, but it seems like what has happened is that there kdevelop-php-docs and kdevelop-php-docs-l10n are provided by both src:kdevelop-php and src:kdevelop-php-docs at different versions. But the src:kdevelop-php one will always be the one available
[23:44] <nacc> since it's version is later
[23:45] <nacc> jbicha: why, though? that package exists and is provided in the release pocket by src:kdevelop-php?
[23:45] <jbicha> I see that Debian did drop the kdevelop-php-docs src package so an AA removal is needed here
[23:46] <nacc> yeah, i think that's all it is, just confusing because of the naming (to me :)
[23:46] <nacc> clivejo: probably easiest to file a bug and subscribe ubuntu-archive?
[23:46] <clivejo> KDE4 stuff is old to us, we are on KF5 now and dont want to maintain old versions
[23:46] <jbicha> if you were wondering why 1.7.3-1 hasn't migrated, I think it's because -l10n was removed but packages still depend on it
[23:47] <jbicha> clivejo: it's not really KDE4; it's just a transitional package anyway
[23:47] <nacc> jbicha: right, but i think that's a red herring. -l10n's removal from src:kdevelop-php-docs doens't change the latest version of -l10n provided by ubuntu in z
[23:47] <jbicha> but like I think you're saying, we don't even need it to migrate from -proposed if we're just going to delete it anyway
[23:47] <nacc> jbicha: i think it isn't migrating because it is not making any relevant binaries
[23:48] <nacc> jbicha: since everything kdevelop-php-docs is already available in z (and z-p) via src:kdevelop-php
[23:48] <jbicha> clivejo: https://paste.ubuntu.com/23795136/
[23:49] <nacc> jbicha: right, but I don't think reverse-depends is 'smart', it just looks at the binaries by a src
[23:52] <nacc> http://paste.ubuntu.com/23795147/
[23:52] <nacc> jbicha: --^ i.e.
[23:54] <jbicha> I agree that we need an AA to do the removal, but why not fix the Kubuntu packages to stop depending on a transitional pkg too?
[23:55] <nacc> jbicha: it's not transitional?
[23:55] <nacc> jbicha: oh!
[23:55] <nacc> jbicha: sorry, totally misunderstood
[23:56] <nacc> jbicha: yes, you're right, and it can then be removed from src:kdevelop-php as well, you mean?
[23:56] <jbicha> we'll let Debian handle the removal of that transitional binary when they get around to it
[23:57] <nacc> ack
[23:58] <jbicha> we might need to keep it until 18.04 anyway since it was included in 16.04