[05:05] <Mirv> the request from Saturday would still be needed - https://irclogs.ubuntu.com/2016/08/13/%23ubuntu-release.html#t06:03 - at least running the failed unity-scope-click's unity8 tests with --all-proposed, I understand if you don't necessarily want to edit vorlon's hint (visible in update_output.txt)
[06:47] <flocculant> infinity: seems that xubuntu hasn't built since Saturday - not sure why
[07:10] <pishuilu> @all   The Ubuntu Kylin daily iso is not created successfully. The question is about python3-aptdaemon.pkcompat package. Kubuntu and Xubuntu have the same question. But Ubuntu and lubuntu daily iso is created susccessfully. What needs to be done to sovle this question? The URL is https://launchpadlibrarian.net/278816938buildlog_ubuntu_yakkety_amd64_ubuntukylin_BUILDING.txt.gz and
[07:10] <pishuilu> https://launchpadlibrarian.net/278982117/buildlog_ubuntu_yakkety_amd64_xubuntu_BUILDING.txt.gz
=== davmor2_Hols is now known as davmor2
[09:09] <ginggs> hi Laney, ubuntu's libphonenumber needs a fix for gcc6/boost1.61 - you uploaded a newer version to debian a year ago. is there any reason we shouldn't sync from debian?
[09:12] <Laney> hi ginggs
[09:12] <Laney> I don't know, the phone people like to patch that package so I would talk to them
[09:13] <Laney> Maybe it can be merged
[09:14] <ginggs> Laney: ok, thanks - speaking to the phone people first is a reason not to sync
[09:37] <Mirv> likewise --all-proposed for these unity8 tests http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#webbrowser-app
[09:42] <Laney> Mirv: going
[09:43] <Laney> let's see what is left
[09:48] <Laney> a lot of things are coming down to graphicsmagick
[09:48]  * Laney pokes
[10:00] <Mirv> Laney: I guess you can't update the manual hint from slangasek visible at update_output? it lacks some required newer versions.
[10:00] <Mirv> oh, not visible anymore, was still in the morning
[10:01] <Mirv> had these Version mismatch rows
[10:01] <Mirv> anyway, it looked like a good hint
[11:27] <Mirv> doh, webbrowser-app needs a no-change rebuild, on it. that was a weeks old silo that landed.
[11:28] <Laney> what for?
[11:29] <Mirv> it was compiled before Qt 5.6 landed in proposed and depends on the older private ABI
[11:29] <Mirv> I realized it thanks to your script, trying some apt commands
[11:33] <Mirv> ...or not. weird. so click throughing in LP got me to an older deb download, the control.tar.xz of which I examined. I didn't question it since the apt did claim webapp-container depending on qtbase-abi-5-5-1.
[11:33] <Laney> wait
[11:33] <Laney> It's fine, it depends on 5-6-1
[11:33] <Mirv> I know (now)
[11:33] <Laney> you just have to wait for it to pass excuses
[11:33] <Laney> update_output.txt is telling you about the webbrowser-app in yakkety-release
[11:35] <Mirv> oh well proposed seems broken anyway since oxide-qt has failed a build on armhf and arm64 which webbrowser depends on.
[11:35] <Mirv> armhf specifically, arm64 never worked on yakkety
[11:36] <Mirv> maybe that hybris dependency could be now filled, trying a rebuild of oxide
[11:45] <Mirv> hmm, I guess I can workaround that oxide for now, since oxide-qt is not required for the migration since it fortunately nowadays does not depend on the private ABI.
[11:45] <Mirv> filed a bug about that armhf FTBFS anyway, since it seems the dependencies are still unfilled
[11:56] <Laney> Mirv:  libhybris-common1 : Depends: libc6 (< 2.24) but 2.24-0ubuntu1 is to be installed
[11:59] <Mirv> updated bug #1613257
[11:59] <ubot5> bug 1613257 in libhybris (Ubuntu) "oxide-qt fails to build on yakkety due to missing hybris dependencies" [Critical,New] https://launchpad.net/bugs/1613257
[12:19] <kdub> Mirv, I can probably spare some cycles if you need any help on https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1613257, its blocking the mir release too, along with the oxide migration
[12:19] <ubot5> Launchpad bug 1613257 in libhybris (Ubuntu) "oxide-qt fails to build on yakkety due to missing hybris dependencies" [Critical,Confirmed]
[12:23] <Mirv> kdub: I don't have an idea how to fix that, it's likely we need morphis or someone else who knows about the hybris internals to know why glibc 2.24 is banned like that, and how big an issue to solve it would be
[12:24] <morphis> Mirv: is that in yakkety?
[12:24] <Mirv> morphis: yes
[12:24] <morphis> Mirv: we don't define that requirement in debian/control for libhybris
[12:25] <morphis> just for vivid we require gcc 4.7
[12:25] <kdub> morphis, so maybe a nochange-rebuild would fix?
[12:26] <morphis> yes
[12:26] <kdub> cool
[12:27] <kdub> I think there might be a way to nochange-rebuild without a silo? (but I'm not a debian/ubuntu maintainer, and don't know how to do that)
[12:28] <Mirv> I don't see thought where Laney got that, as I only see: Depends: libandroid-properties1, libc6 (>> 2.23), libc6 (<< 2.24), libgcc1 (>= 1:3.5), libstdc++6 (>= 5.2) in the latest yakkety armhf binary, but maybe a no-change rebuild could help
[12:30] <Laney> Then you do see it?
[12:32] <Mirv> Laney: thank you, now I do, I didn't when copy-pasting :D
[12:32] <Laney> :)
[12:33] <Mirv> I'm trying a no-change rebuild in a silo. Meanwhile, I restored the webbrowser-app for now.
[12:33] <Laney> restored?
[12:34] <Mirv> I managed to do that no-change upload before noticing the issue. Now I waved another magic wand to keep it possible for the Qt & KDE migration to happen.
[12:35] <Laney> I see webbrowser-app is building, but I'm not sure why it was necessary to do that
[12:37] <Mirv> it wasn't, originally, but since ubuntu2 bumped into oxide-qt/hybris glibc issue, ubuntu3 is a "restoration" of ubuntu1 so to speak, but still ok for migrations
[12:37]  * Mirv keeps alive the dream of Qt & KDE migration
[12:38] <Laney> Now it's going to re-trigger the unity8 tests
[12:38] <Mirv> however, this week it's also relevant to ask if that can happen now or if I should bite the bullet and eg upload that newer qtbase that's pending
[12:38] <Mirv> but I hope update_output.txt will be ready for another slangasek's hint attempt later today
[12:39] <Laney> I really wish you hadn't done that
[12:40] <Mirv> Laney: you'd rather like the error be visible, or you'd rather have just stayed with the 2 week old webbrowser-app that got binary copied to the proposed earlier today from silo?
[12:40] <Laney> what error?
[12:40] <Mirv> Laney: the ubuntu2 of webbrowser-app that revealed the oxide/libhybris issue
[12:40] <Mirv> ubuntu1 was the two week old build that was ok, and wouldn't have needed a rebuild (strictly). ubuntu3 is more or less the ubuntu1 again, so working.
[12:41] <Laney> I have no idea why webbrowser-app has anything to do with that
[12:41] <Mirv> Laney: it depends on oxide-qt, so can't build on armhf with oxide-qt from proposed
[12:42] <Laney> it was already built on armhf
[12:42] <Mirv> yes it was, using the older oxide-qt
[12:42] <Laney> so?
[12:43] <Mirv> so, nothing, it'd been better to just stay with ubuntu1 instead of juggling around, but now we at least have more bugs filed.
[12:44] <Laney> It looks like you made this one build without proposed anyway
[12:44] <Laney> so I have no idea what this has achieved other than wasting some time
[12:44] <Mirv> Laney: as said, ubuntu2 shouldn't have been done, so yes it's wasting some time, but it's at least not blocking anymore compared to if I had stayed with the broken ubuntu2
[12:44] <Laney> that was about to become a candidate for migration
[12:45] <Mirv> yes, it will be again in an hour or two.
[12:46] <Laney> Right, in future if I'm helping you then please ask before randomly uploading stuff that's going to change the state of play
[12:46] <Laney> now I better go run the tests with all-proposed
[12:47] <Mirv> I will ask, I'm just used to working mostly alone in the last 2.5 weeks, but now it has fortunately changed.
[12:48] <Laney> seems like the new kernel has to go in with all of this stuff too btw
[12:48] <Laney> I don't think any manual hinting will be required once that goes green
[12:49] <Mirv> Laney: ok I will start with double-checking https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6805016/+listing-archive-extra would look ok to binary copy to archives once the binaries are published. built against proposed, looks now proper >> 2.24, << 2.25
[12:50] <Laney> looks good, not related to this current migration though
[12:50] <Laney> it's going to get stuck along with glibc
[12:50] <Mirv> not related, but a broken oxide blocks touch developers none the less
[12:51] <Laney> ya
[12:51] <Laney> just saying, luckily they are separate
[12:51] <Laney> I wonder why it gets these weird depends on armhf only
[12:54] <Laney> right, I triggered unity8 with all-proposed again, for the new webbrowser-app ._.
[12:54]  * Laney goes to find a sandwich
[12:58] <Mirv> thank you, sorry :(
[12:59] <Mirv> it seems the previous i386 run failed with random flakiness so not much time actually wasted too either
[15:12]  * Laney cries, amd64 failed this time
[17:05] <slangasek> Mirv: my hint was superfluous, the autohinter is already showing the correct hint and output
[17:15] <Mirv> looks like unity8 amd64 succeeded now (20160815_171244)
[17:17] <Mirv> this earlier i386 failure may have been overlooked however http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scope-click - even though unity-scope-click should not be mandatory migrator (existing release pocket version should have no trouble with new Qt and friends)
[17:34] <slangasek> wxl: so the missing lubuntu-next builds are because for-project isn't recognizing lubuntu-next as a project; I guess something was missed there in the ubuntu-cdimage patch
[17:39] <jbicha> why does qt think it needs linux 4.6?
[17:59] <tsimonq2> slangasek: what do you think might be missing? I can send an updated MP your way.
[18:00] <slangasek> tsimonq2: haven't looked at it, but the error message is certainly suggestive
[18:00] <slangasek> for-project: error: unrecognised project 'lubuntu-next'
[18:01] <slangasek> tsimonq2: so, lib/cdimage/project.py project_map
[18:01] <tsimonq2> ok slangasek
[19:47] <bdmurray> slangasek: I've uploaded a new update-manager with virtualbox lts packages support
[19:47] <bdmurray> slangasek: for review in the Trusty SRU queue
[19:47] <slangasek> bdmurray: got it, thanks
[19:48] <slangasek> bdmurray: should the existing -proposed package be released first?
[19:54] <bdmurray> slangasek: I'm not certain what would happen if the virtualbox packages were not in sync w/ X and the kernel.
[19:56] <tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-image/+merge/302964
[19:57] <slangasek> bdmurray: I think they'd get uninstalled, because e.g. virtualbox-guest-x11-lts-vivid Depends: xserver-xorg-core-lts-vivid
[19:58] <slangasek> bdmurray: however, as per https://launchpad.net/ubuntu/+source/virtualbox-lts-vivid/+publishinghistory these packages only even landed in -updates this month... so I think the number of users who'll be impacted is fairly small
[19:58] <slangasek> and we could fix it almost immediately
[19:59] <slangasek> but if we go that way, we should definitely use a different SRU bug for this issue
[19:59] <slangasek> LocutusOfBorg: ^^ fwiw
[20:02] <slangasek> tsimonq2: merged
[20:03] <bdmurray> slangasek: I don't think the existing one in -proposed needs to be released first.
[20:03] <slangasek> ok
[20:03] <tsimonq2> slangasek: thanks
[20:04] <tsimonq2> slangasek: could you please trigger the build manually (instead of waiting for cron) to see if I need to fix anything else?
[20:05] <slangasek> tsimonq2: running
[20:05] <tsimonq2> thank you slangasek
[20:08] <slangasek> tsimonq2: I see it failed, haven't looked how/why, will let you investigate
[20:08] <tsimonq2> slangasek: where can I find the logs?
[20:14] <tsimonq2> slangasek: nvm I think I found it
[20:31] <tsimonq2> slangasek: nope, where is the build log?
[20:32] <tsimonq2> argh sorry I *did* find it
[20:37] <tsimonq2> hmmm "No valid suites to build for"
[20:43] <slangasek> tsimonq2: etc/default-arches ?
[20:44] <slangasek> (maybe)
[20:44] <slangasek> nah, the catch-all at the bottom should dtrt
[20:44] <tsimonq2> I'll check after lunch
[20:58]  * infinity fixes the project name.
[21:01] <infinity> slangasek: FWIW, you need to fix ~cdimage/cdimage/production/livefs-launchpad and the livefs itself also needs to be created in LP.
[21:02] <infinity> Also fixed the project name to not have a space, which debian-cd would end up barfing on after you fix the above. :P
[21:12] <tsimonq2> thanks infinity
[21:22] <infinity> slangasek: And https://launchpad.net/~adconrad/+livefs/ubuntu/yakkety/lubuntu-next created for you.
[21:24] <slangasek> infinity: hmm livefs-launchpad seems awfully redundant with default-arches, why do we need two of these?
[21:25] <infinity> slangasek: It's mapping project to lp livefs.  It could perhaps be done more intelligently.
[21:25] <infinity> (or, indeed, default-arches could perhaps grow a column)
[21:25] <slangasek> infinity: k. anyway, thanks
[21:26] <infinity> slangasek: When we were split across old-style builders and lp-buildd builders, production/livefs-* made more sense.
[21:27] <infinity> Err, pretend I didn't paste what I did above, but rather https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/lubuntu-next
[21:27]  * infinity fixed the owner... Derp.
[21:28] <slangasek> ;)
[21:30] <tsimonq2> infinity, slangasek: what now?
[21:30] <slangasek> tsimonq2: basically, all the missing bits were things the cdimage team needed to do but only some of us know how to ;)
[21:31] <tsimonq2> ok slangasek :)
[21:31] <tsimonq2> slangasek: so etc/default-arches doesn't need to be edited I assume?
[21:32] <slangasek> tsimonq2: it does not
[21:33] <tsimonq2> slangasek: ok, so I don't need to do anything else?
[21:34] <infinity> tsimonq2: Not until you hit the next failure. ;)
[21:34] <infinity> But the current batch of failures was on us.
[21:34] <tsimonq2> hehehehehe
[21:35] <tsimonq2> so can we get another respin then so I can mov on to the faliures I have to fix?
[21:56] <LocutusOfBorg> thanks
[21:56] <LocutusOfBorg> BTW I'm building only the guest packages, so the users are confined to people running ubuntu inside a virtualbox vm