jbichaclivejo: kdevelop-php-docs is just a transitional package so there's no need to remove it00:09
jbichaif you want it to get out of zesty-proposed, you need to stop having the kde langpacks depend on kdevelop-php-docs-l10n00:10
jbicharun the reverse-depends command I posted earlier to see which packages I'm talking about00:12
cyphermoxcan someone please review grub2 and grub2-signed from zesty unapproved queue (because EFI signing), and review the grub2/grub2-signed SRU for xenial?01:18
naccclivejo: sorry, i was afk, hopefully it made sense from what cjwatson and jbicha said02:01
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (xenial-proposed) [20160930-0ubuntu3~16.04.0]05:14
Mirvcan 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:58
Mirvacheronuk: ^05:59
Mirvthere's always another thing around the corner with Qt transitions, I recommend not holding breathe :)05:59
Mirvthere 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:00
Mirvalso, many of the problems cannot be solved by core devs like this promoting of packages, so we need to wait06:02
ginggsWould 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 VMs07:01
apwginggs, are we going to fix that test ?07:37
ginggsapw: 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 migrates07:38
apwginggs, ok done07:49
ginggsapw: thanks!07:51
Mirvapw: can you see about the promotions too?07:52
Mirvie http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity807:53
Mirvapw: oh sorry, my mistake, they _are_ new dependencies to unity8-tests07:53
MirvSaviq: ^07:53
Mirvapw: 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:56
MirvSaviq: please consider reverting the conflicting changes to unblock Qt, MIRing could take some time07:57
-queuebot:#ubuntu-release- New binary: python-parse [amd64] (zesty-proposed/universe) [1.6.6-0.1~build1] (no packageset)08:05
Mirvok, xvfb could also be promoted, parallel and dbus-test-runner not08:12
-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:14
Mirvand this is the branch that got landed last night https://code.launchpad.net/~unity-team/unity8/installed-qmltests/+merge/29344308:15
SaviqMirv, apw, https://launchpad.net/bugs/165610408:39
ubot5Ubuntu bug 1656104 in unity8 (Ubuntu) "Please demote unity8-tests to universe" [Undecided,New]08:39
Saviqgargh, 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:40
MirvSaviq: ah, great! thanks. and recycling08:42
oSoMoNcan 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:21
LocutusOfBorgcmake revert done /cc xnox09:57
=== jamespag` is now known as jamespage
Mirvarchive admins: when around, please handle bug #1656104 to continue with the Qt 5.7.1 transition10:33
ubot5bug 1656104 in unity8 (Ubuntu) "Please demote unity8-tests to universe" [Undecided,Confirmed] https://launchpad.net/bugs/165610410:33
sil2100rbasak, 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)11:39
=== marcusto_ is now known as marcustomlinson
sil2100bdmurray: 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
sil2100bdmurray: the fix is already long long overdue12:09
sil2100And was tested hundreds of times12:09
rbasaksil2100: 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:10
rbasaksil2100: 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:11
sil2100rbasak: yeah, it's a bit complicated, but one could think of it as a 'straight revert'12:12
sil2100rbasak: 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 contents12:13
sil2100Just waiting for the autopkgtests to re-run and I'll opt for getting it in12:14
rbasakIMHO, 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
rbasakI agree it's subjective.12:15
sil2100Seeing the changes to me personally it's a straight revert as both two fixes were isolated changes, so reverting one cannot impact the other fix12:18
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu14 => 229-4ubuntu15] (core)12:18
sil2100As we're only really using upstart on ubuntu-touch, where the reverted change actually caused a regression12:18
sil2100But 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 already12:20
sil2100So I wouldn't want it to linger around for no reason12:20
* rbasak isn't a veteran!12:23
LaneyProbably don't want to release it on a Friday anyway ;-)12:23
didrocksLaney: anything to say on new release on Friday? :p12:24
didrocksbe warned! ;)12:24
Laneydidrocks: I heard you have 24/7/365 on-call coverage12:25
didrocksLaney: good answer, and pretty much accurate right now :-)12:25
slangasekcan 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 NVME12:26
slangasekthere's an existing SRU in xenial-proposed which hasn't been verified; we should just stack them12:26
sil2100I could, but I am but a newb so someone would anyone have to double-check before I can approve it12:28
sil2100Since bdmurray said I still need to do some coordinated reviews for now12:28
sil2100slangasek: are all those patches present in systemd 323-10 from zesty? Or is that one not affected?12:31
rbasakIs rharper happy to have the aging clock and verification reset?12:36
rbasakslangasek: 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:41
rbasakHow long has this had time to bake in Zesty? It's not marked Fix Released yet.12:42
rbasaksil2100: linux-firmware in xenial lgtm to accept.12:46
slangasekrbasak: the NVME support was added in the kernel publication cycle that released to -updates at the beginning of this year12:47
slangasekrbasak: 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 MAAS13:02
rbasakslangasek: 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:05
sil2100rbasak: thanks!13:07
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.8]13:08
-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:16
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.24+16.10 => 2.25+16.10] (no packageset)13:18
Saviqnow 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:49
Saviqhmm or maybe it just didn't update, they seem to be running13:50
MirvSaviq: it's just slow, now they're running13:52
SaviqMirv, yeah, sorry for the noise13:52
MirvSaviq: 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 lies13:52
Mirvit's hard to see much before unity8 is again valid candidate though13:53
MirvI don't now immediately remember if those old binaries need to be deleted before migration happens? basically bug #1655290 + now also that unity8-fake-env13:53
ubot5bug 1655290 in qtbase-opensource-src (Ubuntu) "RM: Qt 5.7.1 transition related package removals" [Undecided,New] https://launchpad.net/bugs/165529013:53
SaviqMirv, they don't need all-proposed, since they actually depend on Qt 5.7 - they're actually running the tests now13:53
MirvSaviq: great, some time saving there at lest13:53
SaviqMirv, qtbase seems a valid candidate, so should migrate13:54
Saviqnot sure why it didn't, yet, tbh13:54
MirvSaviq: it's far from that simple13:56
Saviqok ;)13:56
MirvSaviq: one needs to also decipher the "13:56
MirvTrying easy from autohinter" sections from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt13:56
Mirvafter everything is valid candidate on the excuses page. there might be something lurking.13:56
acheronukGood luck with that13:57
MirvSaviq: but the first blocker now is qtbase can't migrate without Unity 8 that is built against it13:57
SaviqMirv, right right13:57
acheronukI did degree and PhD in physics with quantum silliness, and a page of that still makes more sense than the update_output.txt13:58
Mirvlast 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:58
Mirvthe 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 queue13:59
Mirvso day by day, new problems arise and they are sorted out a bit too slow to win this game :)13:59
Mirvacheronuk: heh13:59
Mirvso 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 happen14:00
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.24 => 2.25] (no packageset)14:01
LaneyMirv: Things will have to be deleted if they show up as 'old binaries left' on excuses14:02
=== davmor2_ is now known as davmor2
Laneyso just the fake-env I think14:02
MirvLaney: 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
Laneymaybe, check with rmadison14:03
Laneywebbrowser-app -> unity8 seems red fwiw14:03
Mirvrerunning those14:04
Laneyalso, http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_output_notest.txt is useful to see what would happen if all tests were passing14:05
Laneyso you can get out in front of some problems14:05
Mirvright, the previous RM packages are not in zesty-proposed anymore. good.14:05
Mirvoh! that's new to me.14:05
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (yakkety-proposed/main) [1:3.22.0-1ubuntu1 => 1:3.22.2-1ubuntu0.1] (ubuntu-desktop)14:07
Mirvok, there are some problems left there too14:07
Laneyunity8 is because of what I just mentioned14:07
Mirvthere is also ginga and yade at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pyqt514:07
* Laney lunch14:08
Mirvfailing to find python modules14:08
* acheronuk booksmarks that link14:08
slangasekrbasak: ok, we've root-caused the MAAS thing for sure, and yes it is actually fixed by this systemd change so yes it is urgent14:11
slangasekrbasak: and this is a necessary SRU change /anyway/, we just weren't sure how it related to the MAAS regression14:12
bdmurraysil2100: 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:16
slangasekbdmurray: 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
slangasekoh :-)14:21
MirvI 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'd14:23
rbasakslangasek: what's the status of this in Zesty please?14:24
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9ubuntu2 => 231-9ubuntu3] (core)14:26
slangasekrbasak: 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 zesty14:26
rbasakI'm struggling to understand why this is so urgent. Is there some kind of regression that I've misunderstood?14:26
slangasekrbasak: yes there is a regression14:27
jgrimmyes systems that previously worked... no longer do14:27
sil2100bdmurray: 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
sil2100bdmurray: I would be +1 on that in that case14:27
rbasakDid these systems work before Nov 2016?14:27
rbasakAnd was it bug 1642903 that caused the regression, but only triggered now by the kernel update?14:28
ubot5bug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed] https://launchpad.net/bugs/164290314:28
slangasekrbasak: 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 all14:28
slangasekrbasak: therefore, maas fails to provision any system with an attached nvme disk whose serial and/or model contains whitespace14:28
slangasekand this is fixed by this SRU, which was the next thing we already knew we needed to do for systemd14:29
slangaseksmoser: ^^14:29
* rbasak reads up14:29
smoserslangasek, did systemd upstream agree with the fix we proposed ?14:30
smoserlast i saw that was not decided.14:30
slangaseksmoser: yes, it's landed on trunk14:30
rbasakslangasek: would reverting the change from bug 1642903 fix the problem?14:31
ubot5bug 1642903 in systemd (Ubuntu Trusty) "introduce disk/by-id (model_serial) symlinks for NVMe drives" [Wishlist,Fix committed] https://launchpad.net/bugs/164290314:31
slangasekrbasak: I don't know that it would; I don't believe it would14:32
slangasekrbasak: because I think maas picks up on the id as soon as it's in sysfs, regardless of what udev tries to do with it14:32
slangasekrbasak: and anecdotally, I'm hearing that things have been broken for maas users well before that previous systemd sru went in14:34
rbasakI'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:34
slangasekrbasak: that full fix is precisely the set of patches Canonical's STS engineer sent upstream for addressing this issue14:35
barryLaney: ping14:35
smosermaas commissioning that gets the serial number (and thus causes installtion to use serial path) is probably not dependent on the symlinks.14:35
slangasekright; else it would never have seen a mismatch14:35
rbasakslangasek: 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:35
rbasakslangasek: OTOH, a stop gap simple-but-obviously-correct workaround might have lower regression risk.14:36
slangasekrbasak: 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:36
slangasekthough I guess that is a sort of quantifying ;)14:37
rbasakOK, well let me finish reviewing these three patches anyway, and see what I think after that.14:39
rbasakI also won't be offended if you would prefer to pass this to another ~ubuntu-sru.14:39
slangasekrbasak: 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 refactoring14:40
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.25+16.10]14:44
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.25]14:46
-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:17
-queuebot:#ubuntu-release- New binary: pluma [ppc64el] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)15:27
-queuebot:#ubuntu-release- New binary: pluma [i386] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)15:29
-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:31
cyphermoxrbasak: do you have time to review my grub2 SRU for xenial?15:32
rbasakcyphermox: sorry, swamped.15:33
-queuebot:#ubuntu-release- New binary: pluma [s390x] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)15:33
-queuebot:#ubuntu-release- New binary: pluma [powerpc] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)15:35
tjaaltonxnox: xorg-server-lts-xenial uploaded15:35
sil2100bdmurray: 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 already15:35
-queuebot:#ubuntu-release- New binary: pluma [amd64] (zesty-proposed/universe) [1.17.3-0ubuntu1] (ubuntu-mate)15:36
-queuebot:#ubuntu-release- Unapproved: kombu (trusty-proposed/main) [3.0.7-1ubuntu1 => 3.0.7-1ubuntu1.1] (kubuntu, ubuntu-server)15:37
bdmurraysil2100: yes, looks good15:40
xnoxtjaalton, tah.15:40
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (xenial-proposed) [1.8.3-1ubuntu0.3]15:40
Laneyhi barry15:43
barryLaney: hi.  we've been seeing some new regressions on ubuntu-image promotion in zesty but only on armhf.  related to failures in devmapper15:44
barryLaney: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/u/ubuntu-image/20170111_171929_431b1@/log.gz15:44
barryLaney: 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 help15:44
barryLaney: 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 with15:45
Laneyhave you tried using lxd on a different arch?15:45
barryLaney: not yet. ;)15:45
* barry had some trouble with lxd but before this promotion problem15:46
barryand before i upgraded to zesty.  i need to try that tho15:46
Laneybarry: looks like the older version ran again and passed? http://autopkgtest.ubuntu.com/packages/ubuntu-image/zesty/armhf15:49
sil2100bdmurray: thanks!15:49
xnoxbdmurray, 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
xnoxshould be mostly harmless15:52
barryLaney: well, that's weird.  i can't think anything that has changed in that part of u-i15:52
* xnox ponders if in ~ubuntu-sru training book "xnox asking for accept" is a major red flag or not =)15:52
* barry retries15:53
xnoxbarry, 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
barryxnox: in the buildds?15:54
xnoxbarry, 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:54
barryi really think i need to get lxd running on this new zesty install15:56
Laneybarry: yeah, fails like that for me locally in lxd with ubuntu216:01
barryLaney: *very* interesting16:02
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.7]16:02
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.7]16:04
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-lts-xenial [source] (trusty-proposed) [2:1.18.4-0ubuntu0.2~trusty2]16:05
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.7] (core)16:25
barryLaney: 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 problem16:33
Laneybarry: right, I wouldn't expect that to work, I just did amd64 on amd6416:34
Laneydev/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/amd6416:34
Laney^- failed16:34
barryLaney: oh, i thought you did try armhf.  so the failure is any container based autopkgtest16:35
LaneyI guess so16:35
barryLaney: okay!  that's at least a clue.  thanks16:35
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.7 => 2.02~beta2-36ubuntu3.7] (core)16:38
apwthat is definatly hinky ^17:04
apwoh no, that is just the binary bits ...17:06
cyphermoxapw: it's a side-effect of grub2 requiring EFI signing17: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:07
cyphermoxhowever, wat.17:08
cyphermoxs390 ftbfs?17:08
cyphermoxoh, and no log17:08
barryLaney: did you get a ftbfs in the container or a failure in the autopkgtest?17:09
Laneybarry: the test failed, I don't think it rebuilt17:11
barryLaney: 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 seeing17:12
Laneybarry: I saw the same as that autopkgtest log you linked17:13
Laneyexcept I only ran that 'mount' test17:13
barryLaney: ah, ok17:14
-queuebot:#ubuntu-release- New binary: puppet [amd64] (zesty-proposed/universe) [4.8.1-2] (no packageset)17:23
barryLaney: sorry to keep bugging you, but in the container you tried, is /tmp a zfs file system?17:31
LaneyI don't *think* so17:32
Laneygive me 10 minutes to run it again17:32
barryLaney: 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 ext417:33
barry(which will cause two unittests to fail)17:34
Laneybarry: lxd/containers/autopkgtest-lxd-ubfhza on / type zfs (rw,relatime,xattr,noacl)17:35
barryLaney: could you please try the following:17:35
barrytruncate -s 1000000 /tmp/a17:35
barrystat /tmp/a17:35
barryLaney: how many blocks does that report?17:35
barryLaney: 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-proposed17:37
Laneybarry: I used that ^ command which doesn't rebuild unless the test asks for it17:37
barryLaney: awesome, thanks.  that confirms it.17:38
Laneybarry: Glad you were able to understand the issue :-)17:43
barryLaney: one less hirsute yak17:44
Laneyat least the clippings will keep you warm this winter17:44
barryLaney: :D  we'll need it for the ice storm tomorrow (which, of course, because i have a gig)17:44
Laneybarry: http://www.bbc.co.uk/news/live/uk-38601592 <- some really REALLY extreme conditions on there17:46
barrywell, at least that'll be year round when the jetstream collapses17:47
Laneysnowpocalypse... 2" later17:48
* Laney saw a flake this morning and had to go back to bed17:48
barryis that like, see some roadkill and think zombie apocalypse?17:49
cjwatsonI'm not sure that wouldn't improve the UK17:49
LaneyIt'll be hard to distinguish reality from zombie apocalypse if I head into town tonight17:50
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu15]18:18
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (yakkety-proposed) [231-9ubuntu3]18:19
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.3-0ubuntu4~16.04.2]18:38
dmj_s76infinity: Any idea when the kernel and the rest of the HWE stack will land in the xenial daily iso?19:25
=== Guest87783 is now known as med_
=== med_ is now known as medberry
acheronukhi. Qt still seems to be blocked on these old binaries? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity820:25
acheronukis anyone able to sort those?20:26
-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:37
infinityacheronuk: Fixed.20:57
acheronukinfinity: thank you :)20:58
acheronukit's bound to block on something else now, but each step helps....20:58
acheronukyep. Qt 5.7.1 still well and truly stuck, and staring at update_output.txt is doing me no favours22:47
naccacheronuk: aiui, it looks like a bunch of packages become uninstallable if hte updated qt goes in?23:16
acheronuknacc: 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 regard23:20
naccacheronuk: yeah, it seems like it's a whole pile of stuff all at once :)23:21
naccacheronuk: i tend to try and reproduce it with a chdist23:22
naccfor instance, i can reproduce the src:qtsensors-opensource-src failure in my z-p chdist23:22
acheronukchdist? 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
naccacheronuk: http://manpages.ubuntu.com/manpages/trusty/man1/chdist.1.html23:23
naccalthough of course using a more recnet version23:24
nacclet's yuo basically fake a apt setup without having to use a chroot (although it should be reproducible there too)23:24
acheronukah, that jogs a memory now23:24
acheronukmay try that tomorrow when my patience has returned23:25
naccso for http://paste.ubuntu.com/23795038/ I got http://paste.ubuntu.com/23795037/23:25
naccacheronuk: not saying it will really help, but maybe if you have more context, it might point you in the right direction23:25
acheronukany clue is better than 'no clue' :P23:27
naccacheronuk: agreed :)23:30
naccclivejo: 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:34
clivejothats KDE4 version AFAIK23:35
clivejoDebian must be keeping both KDE4 and KF5 versions23:36
naccclivejo: 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:36
clivejobut I dont understand why we are syncing KDE4 stuff23:37
naccclivejo: 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 debian23:37
naccclivejo: that src is still published in debian (albeit only in stable)23:38
naccclivejo: and a transition happened, probably in debian, that didn't get trnaslated correctly to ubuntu23:38
naccbut i'm not 100%23:38
jbichanacc: src:kdevelop-php-docs contains a transitional package; there's no reason to delete if from Ubuntu now23:39
jbichaI don't think you need an AA but you need to not have anything depend on kdevelop-php-docs-l10n any more23:40
naccjbicha: why? kdevelop-php-docs-l10n is provided by src:kdevelop-php now23:40
naccit was a binary package migration between two src packages, afaict23:40
naccso no there is a binaryless src (kdevelop-php-docs)23:41
jbichanacc: 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 it23:41
naccjbicha: huh? it's in the release pocket already23:41
naccjbicha: but those binaries already exist in relase from a *different* src pkg23:43
jbichaoh I see, but still I think it would be a good idea for Kubuntu to fix the packages that depend on that -l10n pkg23:44
nacci 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 available23:44
naccsince it's version is later23:44
naccjbicha: why, though? that package exists and is provided in the release pocket by src:kdevelop-php?23:45
jbichaI see that Debian did drop the kdevelop-php-docs src package so an AA removal is needed here23:45
naccyeah, i think that's all it is, just confusing because of the naming (to me :)23:46
naccclivejo: probably easiest to file a bug and subscribe ubuntu-archive?23:46
clivejoKDE4 stuff is old to us, we are on KF5 now and dont want to maintain old versions23:46
jbichaif you were wondering why 1.7.3-1 hasn't migrated, I think it's because -l10n was removed but packages still depend on it23:46
jbichaclivejo: it's not really KDE4; it's just a transitional package anyway23:47
naccjbicha: 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 z23:47
jbichabut like I think you're saying, we don't even need it to migrate from -proposed if we're just going to delete it anyway23:47
naccjbicha: i think it isn't migrating because it is not making any relevant binaries23:47
naccjbicha: since everything kdevelop-php-docs is already available in z (and z-p) via src:kdevelop-php23:48
jbichaclivejo: https://paste.ubuntu.com/23795136/23:48
naccjbicha: right, but I don't think reverse-depends is 'smart', it just looks at the binaries by a src23:49
naccjbicha: --^ i.e.23:52
jbichaI 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:54
naccjbicha: it's not transitional?23:55
naccjbicha: oh!23:55
naccjbicha: sorry, totally misunderstood23:55
naccjbicha: yes, you're right, and it can then be removed from src:kdevelop-php as well, you mean?23:56
jbichawe'll let Debian handle the removal of that transitional binary when they get around to it23:56
jbichawe might need to keep it until 18.04 anyway since it was included in 16.0423:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!