[01:01] <newb123> I'm playing around with an experimental driver I wrote and at boot it keeps on dumping me into initramfs saying that /dev/disk/by-uuid/XXX.... does not exist. I've checked that the uuid is correct and blockdev --rereadpt /dev/vda displays the correct partitions. Any idea how I might go figuring out why /dev/disk/by-uuid doesn't exist
[05:26] <Mirv> pitti: should not be, but looking
[05:33] <Mirv> maybe some #include problem in the qca-qt5 that has not seen updates in ages
[05:50] <Mirv> hmm, Debian does not have qca-qt5 and builds okteta without it
[05:52] <Mirv> aha, nope, they have 'qca2' ie different source name but same binary names
[05:52] <Mirv> and the newer version they have fix FTBFS with 5.5...
[06:05] <Mirv> (and looks like ubuntu also has qca2, but Kubuntu people have split of the qt5 part to its own source instead of having everything come from single source)
[07:10] <pitti> Good morning
[07:10] <pitti> chiluk: it's not so much a merge (we have no modifications), but the newer version should rather be tested thoroughly
[07:10] <chiluk> I completely agree.
[07:11] <chiluk> that's why I'd rather see it go in xenail while in development than something else.
[07:11] <chiluk> pitti ^^
[07:11] <pitti> cjwatson: I found out last night why so many tests were stuck "in progress" -- it was those which included a package build that failed
[07:11] <chiluk> sometimes I wish IRC would just add the highlights accordingly
[07:12] <pitti> cjwatson: fixed, and I reran all the tests over night, it's okay now
[07:12] <pitti> chiluk: right
[07:12] <chiluk> pitti, I think the "user" understands the issue of this not being SRU-able.
[07:12] <pitti> chiluk: heuristic content based notifications -- just wait until freenode connects to the big google brain
[07:13] <chiluk> but I really think we need to bite the bullet and do it before xenial lands
[07:13] <pitti> chiluk: the crash fix is for sure, but certainly only that backport, not the wholly new version
[07:41] <dholbach> good morning
[07:42] <pitti> chiluk: did you already give that version some testing, with some basic use cases? or need me to do that?
[07:42] <seb128> hey dholbach ;-)
[07:42] <chiluk> pitti I have not, and unfortunately I'm headed on another vacation here till monday.
[07:43]  * dholbach hugs seb128
[07:43] <chiluk> also I should probably be sleeping... infinity must be rubbing off on me.
[07:43]  * seb128 hugs dholbach back
[07:43] <chiluk> and i don't want infinity rubbing anything on me.
[07:55] <pitti> chiluk: ok, seems to work reasonably well here and it has a good test suite too
[07:55] <chiluk> yeah it does have a reasonably good test suite.
[07:55] <chiluk> wow that would be super awesome pitti.
[07:56] <pitti> (I synced it)
[08:31] <pitti> Mirv: so five failures are overridden, what's left are okteta (see above), step (which looks unrelated, I'll hint it), and unity-scope-click (which looks flaky, I'll retry)
[08:34] <pitti> step is debian bug 786351, so someone needs to merge it
[08:37] <Mirv> pitti: can you retry okteta, I uploaded a new qca-qt5 and it was published in proposed 38 minutes ago?
[08:38] <pitti> Mirv: oh cool, thanks! triggered
[08:51] <Mirv> pitti: hmm not sure if the 2.1.1 is in archive indexes yet, I can't update my xenial(-proposed) lxc for some reason yet even though it was that many minutes ago
[08:52] <Mirv> usually that amount of time is enough, but no, not seeing https://launchpad.net/ubuntu/+source/qca-qt5/2.1.1-0ubuntu1 contents in Packages.gz yet
[08:54] <pitti> Mirv: maybe ftpmaster already has it; but anyway, if it still fails we retry later
[08:54] <pitti> Mirv: I'm looking into the step merge btw; but I'll ignore qt's tests once step is the only remaining regression
[08:54] <pitti> (I don't want to ignore it for other packages as they cause the step regression)
[09:02] <Laney> slangasek: It has a patch to review and is in the sponsor queue, so I'm wondering who should review or otherwise deal with it
[09:14] <ginggs> thanks seb128 for the rebuilds :)
[09:15] <seb128> ginggs, yw, thanks for debdiffs and sorry for taking some extra days
[09:19] <pitti> Mirv: uploaded step, that works on xenial release now
[09:27] <cjwatson> pitti: aha, thanks!
[09:43] <Mirv> pitti: got now updated libqca-qt5-2-dev proposed and compiled okteta successfully with that
[09:44] <Mirv> looking good on the autopkgtest infra too, I guess they got it from ftpmaster
[09:44] <Mirv> still running though
[10:29] <pitti> Mirv: but it still fails on the infra
[10:30] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/o/okteta/20151208_094327@/log.gz
[10:33] <Mirv> pitti: hmm, amd64 is still running at http://autopkgtest.ubuntu.com/running.shtml#pkg-okteta and armhf + i386 + ppc64el show success at eg http://autopkgtest.ubuntu.com/packages/o/okteta/xenial/armhf/
[10:33] <pitti> Mirv: ah ok, so that was just an auto-triggered previous run
[10:34] <pitti> Mirv: right, in the above log it still was 2.1.0.3-0ubuntu4
[10:34] <Mirv> so once amd64 finishes it should be all green
[10:34] <pitti> http://autopkgtest.ubuntu.com/packages/o/okteta/
[10:34] <pitti> indeed, nicely green on the others
[10:34] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src hasn't caught up yet, but it should soon
[10:53] <Mirv> xnox: did you get anywhere with the checkbox, or are you familiar with it so that you could get somewhere?
[11:01] <Mirv> xnox: I can't even build it locally for some reason, complies about some patching of vendorized_packages_removal.patch .. but as I linked yesterday, it did start to compile in the PPA but failing later in udev related tests
[11:15] <xnox> Mirv, not yet, i was at end of my day, and i simply added it to my todo list
[11:53] <xnox> okteta still runing, ok.
[12:07] <xnox> pitti, okteta ftbfs
[12:07] <xnox> pitti, can we skip it? and get qtbase in. It is good enough.
[12:07] <xnox> Mirv, ^
[12:08] <xnox> also okteta propbably needs a merge with debian experimental
[12:09] <pitti> xnox: sure we can skip it, but it'll keep breaking other stuff if the new qt makes it ftbfs
[12:10] <pitti> but I thought the new qca-qt5 fixed that
[12:10] <pitti> xnox: no, it's good, it passed
[12:11] <pitti> xnox: results got published 10 s ago
[12:11] <xnox> oh
[12:11] <pitti> http://autopkgtest.ubuntu.com/packages/o/okteta/
[12:11] <mdeslaur> @pilot in
[12:11] <xnox> pitti, it was gone from currently running, but it was not yet up on the package board.
[12:11] <xnox> i guess there is a delay between the two
[12:11] <xnox> ok awesome
[12:11] <pitti> xnox: right, autopkgtest.u.c. pulls every 5 mins
[12:11] <pitti> still waiting on http://autopkgtest.ubuntu.com/running.shtml#pkg-step
[12:11] <pitti> that should build again now too
[12:12] <xnox> pitti, and does kwayland regression on ppc64el affect migration?
[12:12] <pitti> oh, step succeeded too
[12:12] <pitti> so britney should stop complaining about qt the next run
[12:13] <pitti> xnox: oh crap, yes; I'll hint over that
[12:13] <xnox> pitti, and unity-scope-click?
[12:13]  * xnox ponders why it failed
[12:13] <pitti> I reran that one, looked flaky
[12:13] <xnox> pitti, unity-scope-click clearly had a network problem.
[12:14] <xnox> but can be peppered over, no?
[12:15] <pitti> ah, so the rerun failed too
[12:16] <pitti> xnox: ack, hinted, qt etc. will be a valid candidate on the next run
[12:16] <pitti> Mirv: ^
[12:16] <pitti> (could still be some ABI transitions etc. on update_output, of course)
[12:19] <pitti> xnox: FYI, ubuntu-meta is stuck on ubuntu-desktop uninstallability on s390x; perhaps add some [!s390] there?
[12:19] <pitti> there == to the seeds?
[12:20] <xnox> i could do that, or i could get things building
[12:20] <xnox> so i need qt5 on s390x next =)
[12:20] <xnox> and to do that, we need current one migrated
[12:20] <xnox> to upload next one ;-)
[12:21] <Laney> wasn't that caught up with poppler?
[12:29] <rbasak> I'm tempted to s/nagios-plugins/monitoring-plugins/ in the seeds since nagios-plugins-* are now transitional packages that will disappear after Xenial, and if I forget to change the seeds next cycle they will fall into universe.
[12:29] <rbasak> OTOH that will put nagios-plugins-basic/-standard transitonal packages into universe in Xenial.
[12:30] <rbasak> Which may not be good I suppose if someone upgrading has main disabled maybe?
[12:30] <rbasak> I just answered my own question perhaps then - don't do until next cycle?
[12:30] <cjwatson> We normally seed transitionals with a comment saying to drop them after the next LTS
[12:30] <cjwatson> important ones anyway
[12:30] <cjwatson> But changing to monitoring-plugins makes sense
[12:33] <xnox> =) Should wait for tests relating to qtbase-opensource-src 5.5.1+dfsg-6ubuntu2, but forced by pitti
[12:33] <rbasak> I meant if someone upgrading has universe disabled, sorry
[12:33] <rbasak> cjwatson: so should I change now and ignore the transitionals, or add the new ones and keep the transitionals for the transition in main with a comment to remove next cycle, or do nothing until next cycle?
[12:34] <xnox> Laney, pitti, Mirv looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt i say it's foobar to transition =)
[12:34] <cjwatson> rbasak: I would s/nagios-plugins/monitoring-plugins/ and add the transitionals with a comment
[12:34] <rbasak> cjwatson: OK, I'll do that. Thanks!
[12:35] <Laney> xnox: A lot of those are because the other qt* aren't candidates yet
[12:35] <Laney> (I think)
[12:35] <xnox> Mirv, can you throw next qtbase in, which will build on s390x, cause there are binaries that are built with old poppler and they do become uninstallable with new qtbase and thus hold things up.
[12:35] <xnox> Mirv, and yes we do have qt 5.4 & old poppler based binaries in launchpad s390x xenial release pocket.
[12:37] <xnox> and qtbase-opensource-src-gles  is still borked
[12:38] <Laney> qtdeclarative, qtscript, maybe others
[12:39] <xnox> and then it would still block on popler and blocked on s390x old popler, hence i do need another qtbase upload
[12:39] <xnox> which we knew anyway, should have done it days ago.
[12:42] <xnox> Mirv, are you gonna make the next qtbase upload please?
[12:45] <Mirv> xnox: ok, sounds like there's still some things to fix or at least override, so I guess I can put your s390x enablement in
[12:45] <xnox> Mirv, yeap.
[12:45] <xnox> Mirv, and s390x are part of the blockers via poppler.
[12:46] <Mirv> pitti: I think kwin+rocs would need hinting for the other Qt packages too
[12:47] <seb128> doko, hey, did you see my question about pep8 yesterday?
[12:53] <Mirv> Laney: pretty much all qtdeclr* qtscript etc are the same that are overridden for qtbase already (kwin, rocs) or already fixed but status not updated (marble, okteta)
[13:13] <pitti> Mirv: didn't I already?
[13:14] <pitti> Mirv: oh yes, it's currently landing
[13:19] <Mirv> pitti: what's currently landing?
[13:19] <pitti> Mirv: qtbase-opensource-src and friends
[13:19] <Mirv> xnox: I think the checkbox with qt3d5-dev removed should be fixed because of the main <-> universe
[13:19] <Mirv> pitti: I thought qtmir-gles failure prevented that, plus xnox just convinced me to copy over ubuntu3 of qtbase which I did since the migration was supposed to take ages still :)
[13:20] <pitti> oh, or it's that -- https://launchpad.net/ubuntu/+source/qtbase-opensource-src/+publishinghistory
[13:20] <pitti> it's a valid candidate, and https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-6ubuntu2 had no publication, which is usually teh case in between ubuntu2 and ubuntu3
[13:20] <pitti> Mirv: uh, so that will trigger everything again
[13:21] <xnox> pitti, valid candidate.... yet piles of unisntallable packages and thus will not migrate.
[13:21] <xnox> pitti, autopkgtest is not the only thing blocking qtbase migration.
[13:21] <pitti> ok, I didn't check that yet
[13:21] <Mirv> pitti: yeah, xnox wants the s390x to proceed and apparently update_output has more work to be done
[13:22] <xnox> pitti, 5th ctrl-f hit of 'qtbase' on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[13:22] <xnox> in there there are a bunch of todos
[13:22] <xnox> including s390x packages
[13:22] <xnox> * s390x: 4ti2, aweather, foxtrotgps, ....... and so on
[13:23] <pitti> ok; hopefully this round of tests will be much quicker, with the infrastructure currently working and the eternal "test in progress" bug fixed
[13:23] <xnox> Mirv, awww, sybmols. do you want a patch for that?
[13:23] <Mirv> xnox: foxtrotgps is gtk, I wonder if there's an easy root problem
[13:23] <Mirv> xnox: yes please
[13:24] <Mirv> to the installability things
[13:24] <xnox> it builds real quick without the tests =)
[13:24] <Mirv> anyway, I welcome any help on the migration at this point where things already start to be quite complex
[13:24] <Mirv> plus the dragging of the migration making train a bit more cumbersome
[13:29] <Laney> pitti: might want to skiptest if all that's changed is s390x conditionals
[13:29]  * Laney goes to lunch
[13:29] <pitti> it's quite a bit more
[13:30] <xnox> Mirv, http://paste.ubuntu.com/13823021/ test building on s390x at the moment at https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/8410204
[13:30] <pitti> we don't need to wait for everything again though, let's just run a few to check that not everything is totally broken
[13:30] <pitti> Laney: but doesn't help if the necessary rdepends rebuilds haven't been done yet
[13:30] <xnox> pitti, we shall have ubuntu4 in a second =)
[13:31] <xnox> pmcgowan, rocking ipv6 =)
[13:31]  * xnox likes ipv6
[13:36] <doko> seb128, do you remember packages other than prospector?
[13:36] <seb128> doko, I don't remember them but I fixed a few
[13:37] <seb128> it just seems suboptimal to carry ubuntu delta there
[13:37] <seb128> is there any reason the change doesn't make sense for Debian?
[13:38] <seb128> doko, http://launchpadlibrarian.net/222749166/shortuuid_0.4.2-4_0.4.2-4ubuntu1.diff.gz is another one you did
[13:38] <seb128> doko, http://launchpadlibrarian.net/222797987/actdiag_0.5.3-5_0.5.3-5ubuntu1.diff.gz as well
[13:39] <doko> ta
[13:40] <doko> seb128, I'm currently compiling the list of affected packages
[13:41] <Mirv> xnox: I'm also prebuilding in a landing PPA
[13:41] <seb128> doko, k, thanks
[13:53] <doko> cjwatson, https://bugs.debian.org/807366 this requires gcc-5-5.3, or else the options will be unknown
[13:53] <cjwatson> doko: ok, not sure that's a problem for ghc though?
[13:55] <doko> cjwatson, don't know, just in case it wants to pass this to the compiler
[13:55] <cjwatson> doko: it will do, but backporting ghc is somebody else's problem :-)
[13:55] <doko> =)
[13:59] <doko> seb128, http://bugs.debian.org/807409  feel free to comment on the issue when you find more. prospector now fixed too
[14:00] <seb128> doko, thanks
[14:17] <xnox> Mirv, succeeds on s390x.
[14:17] <xnox> Mirv, so once it's ready copy it over please.
[14:37] <Saviq> tvoss, hey, u8 is crashing on me on exit http://pastebin.ubuntu.com/13824663/
[14:37] <Laney> xnox: It helps it get to the next stage, which lets you see what needs updating still
[14:37] <Saviq> looks like a dbus-cpp issue, or a media-hub one, wdyt?
[14:55] <pete-woods> pitti: hey! I still have this PR for python-dbusmock if you have some time (https://github.com/martinpitt/python-dbusmock/pull/17)
[14:55] <pete-woods> I've tried to do all the NEWS / commit messages correctly
[14:55] <pete-woods> and add tests, etc
[14:56] <pete-woods> dammit, pep8 fail, fixing now
[14:56] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/a/ark/20151208_141408@/log.gz
[14:57] <Laney> looks like that pkg-kde-tools upload was bad
[14:57] <pitti> pete-woods: right, sorry, last days were a bit crazy with infra firefighting
[14:58] <pete-woods> pitti: no worries. figured you were just on holiday or something
[14:58] <pitti> pete-woods: no, pretty much the opposite :)
[14:58] <pete-woods> I've had floods / no power here for the last 4 days
[14:58] <pitti> urgh
[14:58] <pete-woods> so I've not done much either
[15:01] <pete-woods> FYI, one of the changes is non-trivial (the one that makes it support having 'secrets' properly)
[15:02] <pete-woods> it intentionally removes some properties from the settings interface that should never have been present
[15:02] <pete-woods> (i.e. they don't exist on the real interface)
[15:02] <pete-woods> I've tried to add a passable level of testing for it all
[15:07] <xnox> Mirv, what other change you need to land in checkbox?
[15:07] <xnox> i fixed it's build.
[15:14] <xnox> barry, unittest is confused by a submodule named dbus, which import system dbus =(
[15:15] <xnox> e.g. i have checkbox.dbus which does 'from dbus import SystemBus' and when running test it trips up on that.
[15:15] <xnox> is there a way to instruct pytest to not "discover" that one?
[15:19] <Mirv> xnox: will do before I go to sleep
[15:21] <xnox> Mirv, well i need to upload my fix, i could upload it with whatever changes you had to land.
[15:21] <xnox> otherwise i'll just upload a straight FTBFS fix.
[15:21] <barry> xnox: python 2?
[15:21] <xnox> barry, python3.5 special =)
[15:22] <barry> xnox: hmm.  absolute imports are the default in 3.  can you pastebin the traceback?
[15:25] <xnox> barry, http://paste.ubuntu.com/13825910/
[15:25] <xnox> barry, so ./setup.py test fails, yet python3.5 -m unittest -v -> succeeds correctly. i blame setuptools-foobarage.
[15:27] <infinity> apw: Hey, uhm.  There's no linux-meta for s390x.
[15:28] <apw> infinity, oh oops, did we forget to add that?
[15:28] <infinity> apw: Yep.
[15:28] <apw> infinity, we just need a -generic for that i presume ... will get that sorted
[15:28] <infinity> apw: And virtual.
[15:28] <infinity> apw: Since you did the split.
[15:28] <apw> now that feel familiar ... why
[15:30] <tvoss> Saviq, looking
[15:30] <xnox> infinity, apw - did you do the split?
[15:31] <xnox> so far everything expects generic.....
[15:31] <xnox> as i thought we don't have a virtual flavour yet.
[15:31] <apw> xnox, it is -generic, -generic gets split
[15:31] <infinity> xnox: Everything should be generic, except the MP I just rejected. :)
[15:31] <barry> xnox: yeah, it's suspicious, but i'm already suspicious of other setuptools foobarisms: LP: #1523806
[15:31] <xnox> infinity, ack.
[15:31] <Mirv> xnox: what your fix, did you have something more than the symbols? the idea is that the armhf build is pre-done so it doesn't take time in the archives.
[15:32] <barry> xnox: is there a branch i can play with?
[15:32] <xnox> Mirv, checkbox, i fixed checkbox to not be crazy.
[15:32] <Mirv> xnox: the reason I'm doing the landing is your fix, I don't have anything else
[15:32] <Mirv> xnox: ah, sorry! I mixed to qtbase
[15:32] <xnox> Mirv, i thought you had something to be changed for checkbox - dependencies?
[15:32] <Mirv> xnox: excellent! so, remove the qt53d-dev from build-deps
[15:32] <xnox> barry, sbuild -A -d xenial checkbox_0.18-0ubuntu4 -> fails at the moment.
[15:33] <Mirv> xnox: so that qt3d-opensource-src can be demoted to universe... otherwise qt3d can't build (or couldn't in archives, but yes when binary-copied from landingn PPA) and I assume it'd block migration too
[15:33] <xnox> barry, it does crazy things, but in essence -> $ cd checkbox-old, in that package is borked. (./setup.py test does not work)
[15:33] <xnox> barry, or well pull-lp-source checkbox 0.18-0ubuntu4
[15:33] <tvoss> Saviq, that's rc-proposed?
[15:34] <xnox> Mirv, right, and checkbox doesn't need it? why it depends on it. Ok will drop
[15:34] <Mirv> xnox: well it didn't seem to require it (and it shouldn't, qt3d wasn't usable really before Qt 5.5), the debian/control looked like copy-paste from somewhere else
[15:35]  * Mirv needs to go now, back to copy the qtbase from landing PPA in a 2-3h
[15:35] <xnox> barry, is that enough for you to play with checkbox? =))))
[15:36] <xnox> Mirv, checkbox fix is python brain-damage and 3 one-liners ;-)
[15:37] <infinity> Odd_Bloke: Looking at the [ "$PROJECT" = "ubuntu-cpc" ] in live-build, why do three arches 'add_task install server', and the rest don't?
[15:37] <infinity> Odd_Bloke: That feels rather broken in one direction or the other.
[15:37] <xnox> infinity, i guess on amd64 -virtual flavour is used which is the default.
[15:38] <infinity> xnox: Yes.
[15:38] <xnox> oh, you are asking about server bits
[15:38] <xnox> it is weird
[15:38] <infinity> xnox: Yes. :P
[15:38] <xnox> yes Odd_Bloke what's up with that =)
[15:39] <Odd_Bloke> That's what we were already doing, so I was aiming to retain parity between what we produced before and what we produced in the buildds.
[15:39] <infinity> Feels like only armhf and arm64 need special-casing there for kernel flavour and flash-kernel, and then the server task should move down to all arches.
[15:39] <infinity> Odd_Bloke: As in, the arches were always mismatched?
[15:39] <tvoss> Saviq, let me see if I can come up with a distilled test case
[15:39] <infinity> Odd_Bloke: Can we aim for that to not be true, since we're doing an LTS? :P
[15:39] <Odd_Bloke> infinity: Oh, you.
[15:39] <Odd_Bloke> :p
[15:40] <infinity> Odd_Bloke: Either the server task should be on all or none, up to you guys which is correct, but the mismatch clearly isn't.
[15:40] <tvoss> Saviq, do you see the crash on regular shutdowns?
[15:40] <Odd_Bloke> infinity: Yeah, I'll bring it up with the others.
[15:42] <infinity> xnox: So, in your MP, I'd drop the s390x stanza from that chunk entirely, since whatever Odd_Bloke decides, it'll wipe out ppc64el and s390x because they'll be the same as the default.
[15:43] <barry> xnox: i see 0.18-0ubuntu4 is building in -proposed.  i can pull down that srcpkg and build locally
[15:43] <xnox> barry, yeah, that one is "fixed" the packaging calls python3 -m unittest, instead of python3 setup.py test.
[15:44] <xnox> barry, but yeah, it should still fail if you do: cd checkbox-old; ./setup.py test
[15:44] <barry> xnox: ack
[15:44] <infinity> Odd_Bloke: Also, did you ever figure out why your powerpc images weren't bootable?  Cause the lack of a powerpc case in that switch could explain it. :P
[15:45] <xnox> plars, i'm not sure where checkbox upstream is for "packaging" of "checkbox-old" but i have made changes to it - https://bugs.launchpad.net/checkbox/+bug/1523969
[15:45] <infinity> Odd_Bloke: (needs KERNEL_FLAVOURS=powerpc64-smp and probably a manual install of whichever bootloader you're using, yaboot or grub2)
[15:45] <Odd_Bloke> infinity: There is a stanza in my PPA version which I'm using. :)
[15:45] <infinity> Odd_Bloke: Ahh.
[15:45] <infinity> Odd_Bloke: So, first half of the question then, did you ever figure it out?
[15:45] <plars> xnox: I'm probably not a good person to ask about that - talk to spineau probably
[15:46] <infinity> Odd_Bloke: Cause I might be able to find an hour or two to look at it.  We're getting to the point where we really want to move PPC into scalingstack.
[15:47] <xnox> infinity, so whilst that case shouldn't be there, it is correct, no?! =)
[15:47] <xnox> i.e. does no harm ;-) until Odd_Bloke fixes the world to be a beautiful place to be in ;-)
[15:47] <infinity> xnox: Minus the KERNEL_FLAVOURS, it's "correct", but just adds noise, since he'll delete it shortly. :P
[15:48] <infinity> (And I suspect it's not correct, I tihnk cloud images aren't meant to have the server task)
[15:48] <xnox> infinity, as far as i can see we don't have virtual flavour yet, and default is virtual.
[15:48] <infinity> Given that 99% of our cloud image users are x86, I'd expect that to be the template.
[15:48] <infinity> xnox: We don't have a virtual or generic yet.
[15:48] <infinity> xnox: That operates on metapackages.
[15:48] <infinity> xnox: We have no linux-meta.
[15:48]  * xnox facepalms
[15:48] <infinity> xnox: One we have meta, we'll have both.
[15:49] <xnox> infinity, anyway, i'm not even building ubuntu-cpc, i only care about server at this point =)
[15:49]  * infinity nods.
[15:49] <xnox> i should stop touching nasty things
[15:49] <infinity> So just drop that stanza and merge away, IMO.
[15:49] <Odd_Bloke> xnox: I thought you cared. ;.;
[15:50] <xnox> Odd_Bloke, that was 4 years ago and cross the road to say hello from the other side =)
[15:50]  * xnox chuckles at his Adele reference
[15:50] <xnox> *I crossed
[15:50] <xnox> i bet ogra_ is confused.com =)
[15:51] <Odd_Bloke> xnox: Is it me you're looking for?
[15:51] <xnox> >_<
[15:51] <Odd_Bloke> ^_^
[15:51] <ogra_> xnox, ??
[15:52] <xnox> ogra_, check irclogs.ubuntu.com in an hour ;-)
[15:53] <mterry> pitti, how do I retest a package's autopkgtests?  (without uploading a rebuild, if possible)  cpl-plugin-fors (and similar) got in a weird state when testing against latest gsl upload (ppc64el built against proposed, tested against release)
[15:53] <ogra_> :P
[15:53] <spineau> xnox: Thanks for you fix. We'll remove the checkbox-old very soon from xenial (replaced with the QML checkbox-converged). I'm just waiting on a few RFS to be processed for packages we're maintaining in debian. After a sync with ubuntu we'll update the xenial branch and those FTBFS will be auto solved.
[15:54] <pitti> mterry: for now, ask me, Laney, slangasek, or infinity
[15:54] <xnox> spineau, cool. well we need that bit now, to unblock 5.5 hence i uploaded minimal fix. i hope that's ok with you.
[15:54] <pitti> mterry: does this look reasonable? http://paste.ubuntu.com/13826667/
[15:54] <pitti> mterry: (from "retry-autopkgtest-regressions |grep cpl-plug")
[15:55] <spineau> xnox: it's ok, many thanks for your fix
[15:55] <mterry> pitti, and add astrometry.net
[15:55] <mterry> pitti, thanks!
[15:56] <xnox> spineau, then just close the bug or whatever. no problem.
[15:56] <pitti> mterry: kicked
[15:57] <pitti> mterry: FTR, I'm off for 2 or 3 hours, checking IRC tonight again
[15:57] <spineau> xnox: ok
[15:59] <mterry> pitti, ack thanks
[16:12] <barry> xnox: it's a bug in checkbox: LP: #1523979 has a patch
[16:14] <xnox> barry, yeah, i was expecting something like this. your digging and explanation make sense =)
[16:14] <barry> xnox: cool.  can you take it from here?
[16:14] <xnox> barry, yes, thank you.
[16:14] <barry> xnox: thanks!
[16:14] <xnox> barry, at least it's not setuptools which are broken.
[16:15] <xnox> and that's good.
[16:15] <barry> xnox: not in this case at least :)
[16:17] <sil2100> pitti, Mirv: hey guys! Any luck on the qt5 migration issues?
[16:17] <doko> barry, for the python 2.7 testsuite I disabled the test_cpickle test, and everything is fine. it's now run as part of the "failing" tests in autopkg test, and should succeed
[16:18] <Odd_Bloke> infinity: I did work out the bootability issue; we weren't doing a grub-install.
[16:18] <Odd_Bloke> infinity: Which is actually _quite_ important.
[16:18] <Odd_Bloke> (This just in, etc.)
[16:19] <Odd_Bloke> infinity: I've been sprinting two of the last three weeks, so I haven't actually looked at it since I fixed that; a quick check of whether or not that fixes powerpc booting as well as ppc64el booting would be good.
[16:19] <Odd_Bloke> (I confirmed the latter, but don't know if the lack of the former was due to my not really knowing which qemu flags to use :p)
[16:21] <mdeslaur> @pilot out
[16:45] <xnox> sil2100, it's in progress.
[16:45] <xnox> sil2100, and there is a lot more to do.
[16:46] <xnox> sil2100, there should be a new qtbase to copy into archive done in one of the landings that mirv is maintaining.
[16:47] <xnox> sil2100, how can i find all landing ppas that have qtbase-opensource-src?
[16:48] <sil2100> xnox: https://requests.ci-train.ubuntu.com/#/tickets?search=qtbase-opensource-src
[16:48] <sil2100> xnox: look for those that are not Landed or Abandoned
[16:48] <sil2100> xnox: thanks for the info!
[16:49] <xnox> sil2100, i don't see it, there should be a ppa with ubuntu4 built i believe somewhere, which Mirv uploaded. if it is fully built, it will need a copy to the archive. let me find it via build records.
[16:51] <xnox> sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032
[16:51] <xnox> sil2100, qtbase-opensource-src	5.5.1+dfsg-6ubuntu4 is ready, can you copy that into xenial-proposed please?
[16:51] <xnox> a better and fixed checkbox, is already in xenial-proposed.
[16:52] <xnox> sil2100, ah, no, armhf is still building.
[16:52] <xnox> sil2100, waiting on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+build/8410224 to finish.
[16:52] <xnox> 1.5h to go.
[16:52] <sil2100> xnox: ok, but once that's done, just the qtbase packages, right?
[16:53] <slangasek> mdeslaur, kees, stgraber: so is today's TB meeting cancelled by popular acclaim?  Not sure if there's something we should do to take it off calendars (fridge?) in that case
[16:55] <xnox> sil2100, no, loads more too. we will need to unwind the popler abi transition in -proposed too, and whitelist through a few autopkgtests. I don't think we'll get it done today. But e.g. I need it to migrate as soon as possible, so will be working on unwinding proposed to get it done tonight/tomorrow.
[16:55] <xnox> but for now i'll be afk, until qtbase builds.
[16:56] <sil2100> xnox: was asking since the silo had many packages in it, didn't know if I was supposed to copy all of them or just qtbase from there
[16:56] <mdeslaur> slangasek: perhaps just update the wiki page stating that the meeting was cancelled?
[16:56] <sil2100> Anyway, thanks and let's see in some hours
[16:56] <mdeslaur> slangasek: and the mailing list
[16:56] <xnox> sil2100, just qtbase, others have been copied before already as far as I understand things.
[16:58] <stgraber> slangasek: I'm fine with skipping it. I'm around but there's little point with nothing on the agenda
[17:02] <sil2100> xnox: ACK
[17:03] <cjwatson> oh, bah, I clearly uploaded texlive-bin too early
[17:03] <cjwatson> didn't notice poppler/s390x hadn't actually built
[17:03] <Laney> yeah
[17:04] <Laney> Could we remove the old poppler binaries from the bootstrap archive, maybe?
[17:05] <xnox> Laney, queried, no.
[17:05] <xnox> Laney, once we have qtbase in, i'll spend some time binNMU the lots until -proposed is happy.
[17:05] <xnox> Laney, i'm afk until qtbase builds.
[17:07] <Laney> xnox: If you did that you could start libreoffice building now
[17:07] <Laney> but 'kay
[17:08] <xnox> Laney, well Mirv insisted building in ppa, rather than -proposed. so we could have had s390x build in -proposed already.
[17:08] <xnox> i could stage things in my non-virt ppa, meh. I'll go have dinner and sort things later.
[17:52] <smoser> cjwatson, have you followed grub-emu + kexec at all ?
[17:52] <smoser> https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-s390x-02-kexec-module-added-to-emu.patch?expand=1
[17:53] <Mirv> xnox: the benefit is the armhf build time that was cut by doing it
[17:53] <Mirv> still some 20 mins to go, then copy
[17:53] <smoser> hm.. i see http://people.ubuntu.com/~alanbell/uds-r/uds-r-foundations-r-powerpc-bootloaders-latest.txt . and the limited context there is almost the same as i'm after.  kernel + initrd as a loader.
[17:54] <Mirv> xnox: sil2100: I sometimes use the train in my own ways ;) since I'm not "publishing" it but copying, it's building in 032
[17:54] <cjwatson> smoser: I had a very brief look over it and asked the suse folks if they were going to upstream it; they indicated probably not since it wasn't really a proper architecture port, just an initramfs hack
[17:55] <Mirv> sil2100: so the autopkgtests were fixed but some new qtbase uploads to get s390x building (not available in landing PPA:s yet). a new look again tomorrow morning... (or during the night by US timezone people)
[17:55] <smoser> cjwatson, so... the context is almost identical to what it was previously... except for s/ppc64el/s390/
[17:56] <smoser> we need netboot like functionality on z series.
[17:56] <Mirv> xnox: hehe @ the checkbox, I'd have had zero idea about that..
[17:56] <cjwatson> smoser: yes, I'm aware of the context.  I'm not entirely opposed to integrating that, just haven't fully thought it through
[17:57] <cjwatson> (I think there are several more patches as well)
[17:57] <smoser> probably.
[17:57] <cjwatson> yeah, five in all
[17:57] <smoser> having "real grub" be the thing that parses a grub config file seems more desireable than having petitboot do it.
[17:57] <cjwatson> certainly
[17:57] <smoser> but only if you can reasonably call the thing "real grub"
[17:57] <cjwatson> 02 is non-upstreamable in its current form of course
[17:58] <cjwatson> (hardcodes systemctl, etc.)
[17:58] <cjwatson> not that that's necessarily an impediment
[17:58] <Mirv> xnox: ah now I finally understood that there's a poppler transition intertwined. thanks for the explanation.
[17:58] <cjwatson> my main concern is having to rebase all this stuff in future :-/
[17:59] <smoser> yeah.
[17:59]  * Mirv sees lots of happening while visiting a christmas party.
[17:59] <smoser> bummer to see that they just call kexec.
[17:59] <sil2100> Mirv: ok, so leaving it in your hands then ;)
[17:59] <Mirv> sil2100: yes, I'll handle it before going to sleep
[17:59] <smoser> i'd hoped they'd written a kexec loader themselves. one without https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1297316
[17:59] <cjwatson> anyway, by all means file a bug and we can tear our collective hair out about it.
[18:00] <cjwatson> oh and also this patch set includes a zipl.conf parser ...
[18:00] <cjwatson> and dracut hardcoding
[18:00] <smoser> :)
[18:01] <cjwatson> and some weird stuff to do with hotkeys that I don't currently understand
[18:01] <smoser> well, i assume that there is some work in petitboot too. i can file a bug. I wasn't really at the point where i woudl favor grub.
[18:01] <smoser> petitboot has desire in that i know it works, and we already basically have to support it (powerNV).
[18:01] <cjwatson> having more consistency across Ubuntu architectures would be good too
[18:02] <smoser> which is more consistency ?  we really can't get rid of ppc64+petitboot
[18:06] <cjwatson> grub2 could at least in principle work on powerNV, no?
[18:06] <cjwatson> even if it doesn't today
[18:07] <smoser> in principal yes, but it'd be firmware change to remove petitboot
[18:07] <cjwatson> sure
[18:07] <cjwatson> I'm not pushing urgently for it, just that I'd rather pick something that can at least in principle do everything
[18:08] <cjwatson> (ok, petitboot sort of could as well, but it would be fairly daft to inject that for x86)
[18:08] <smoser> although if we wanted, we could kernel1+initrd1+petitboot (firmware) kexec -> kernel2+initrd2+grub-emu kexec -> real kernel+initrd
[18:08] <smoser> :)
[18:14] <Mirv> sil2100: xnox: ubuntu4 copied. also qt3d demoted and I did a qtmir-gles upload earlier based on the looks of what its autopkgtests complained (even though I couldn't reproduce any problem in just building it myself). finger crossed again, although I don't know about the poppler status etc and whatever else lurks in update-output.txt after these.
[18:14] <smoser> cjwatson, filed bug 1524029
[18:16] <cjwatson> ta
[18:56] <xnox> Mirv, thanks will be sorting things out shortly.
[19:43] <barry> doko: ack.  if/when the upstream issue is resolved we can reenable it
[19:51] <mterry> Laney, can you help me with getting some autopkgtests restested?  I would like the system to reconsider libpdl-stats-perl, pyxplot, theseus, and visp (to help gsl get through)
[20:17] <teward> this may sound insane, but is it possible in a package build to extract the current 'tag' from `git tags` (since the source directory also has the .git from upstream) to define a variable for use during building/compiling of the package?  Trying to do it now but failing (only getting the build args and not what is wanted)
[20:39] <zaytsev> laney: it took me awhile, but there we go: https://bugs.launchpad.net/ubuntu/+source/scons/+bug/1524058 <--- hopefully this time formatted according to the guidelines
[20:41] <cjwatson> teward: if it's in the source then you can do whatever you like as long as you declare the necessary build-deps
[22:41] <BlackFate> Hello ppl, I try to bisect some kernel versions and one of the commits seems to fail during the build. What's the best approach at this point? Should I try and "git bisect skip" the problematic commit?
[23:14] <teward> cjwatson: right, that's what's being done, but for some reason instead of extracting the tag data we want (the git command will only output the git tag we're on, not all of them), it's failing, and catching instead compiler args
[23:14] <teward> cjwatson: and I have no idea how to fix that
[23:16] <teward> cjwatson: or rather, it's being passed as part of compiler rules so... :/  (in the debian/rules)
[23:19] <cjwatson> teward: Can you link to an example?
[23:20] <teward> if i can find the 2FA key for my github, yes :P
[23:20] <teward> (though i'll pull it out of the code and put it into a paste, because codebase is 'not public' yet)
[23:21] <cjwatson> teward: I suspect something like dodgy escaping in some bit of make/shell/whatever.
[23:22] <teward> cjwatson: i would to, 'cept it's a go application, and there's no makefile (it's compiled by overriding dh_autoinstall)
[23:22] <teward> though it is a 'make' file (debian/rules), so maybe variable substitution is failing
[23:26] <teward> that's... odd... paste.ubuntu.com == lagging
[23:27] <teward> cjwatson: this is essentially what is being attempted... http://paste.ubuntu.com/13839102/
[23:27] <teward> cjwatson: can't figure out why it's failing, though if it's 'make' and it doesn't process Bash-style variable substitution...
[23:27] <teward> maybe that's why...
[23:27]  * teward shrugs
[23:27] <teward> cjwatson: i kind of inherited this thing, it's not my code :/
[23:29] <teward> cjwatson: note that link is the 'slightly stripped' make rules, but it gives you the gist of what's being done in debian/rules at least :/
[23:29] <sarnold> teward: make spawns a different shell for every line in a recipe. I think the export DAEMON_VERSION and umask lines are probably no-ops as a result
[23:30] <teward> mmm
[23:30] <teward> sarnold: well, there *is* something passed to the thing via the ldflags, it's setting the version string to '-extld=gcc' internally when it reaches these steps.
[23:31] <teward> which makes me scratch my head
[23:31] <teward> sarnold: so how would you suggest this be done, then, given that the version has to be 'dynamically updateable automatically via the git tags'
[23:32] <sarnold> teward: I'd try 'go build -ldflags "-X main.Version $(git describe --tags)" -o ...'
[23:33] <teward> sarnold: that's a headache given that the copy you see here is stripped - there's 16 individual `go build` lines :/
[23:33] <teward> i'll test though
[23:33] <sarnold> ahh
[23:33] <teward> and if that works, you get the gold star medal
[23:33] <cjwatson> teward: $$(...)
[23:33] <cjwatson> teward: $(...) does not do what you think there
[23:33] <teward> cjwatson: $$(...) will do what we need?  (at the 'export' line?)
[23:33] <teward> or do we have to do that for all variable sub?
[23:33] <cjwatson> teward: also, each line is run in a separate shell
[23:33] <sarnold> teward: then perhaps this is the starting point http://www.gnu.org/software/make/manual/html_node/Variables-in-Recipes.html#Variables-in-Recipes
[23:33] <teward> cjwatson: which is what sarnold said.
[23:34] <cjwatson> right, you have at least two bugs :)
[23:34] <teward> aahhhhhhhh
[23:34] <teward> okay...
[23:34] <cjwatson> teward: you would probably be better off splitting the content of that out to a separate script
[23:34] <sarnold> cjwatson: hehe, nice :)
[23:34] <sarnold> mmm. nice thinking outside of boxes :)
[23:35] <cjwatson> teward: it's certainly possible to fix this up in make - $$(...), and convert the whole thing to a single shell command with ; or && separators - but it probably won't feel very natural
[23:35] <teward> mmm
[23:35] <cjwatson> teward: also the mentions of debian/PACKAGE/ smell like a template gone wrong
[23:36] <teward> cjwatson: as i said i didn't write it :/
[23:36] <cjwatson> but I assume that's you obfuscating it
[23:36] <teward> cjwatson: and yes
[23:36] <teward> works like a charm except for the version string so bleh
[23:36] <teward> i'll stab this a little more :)
[23:36] <teward> thanks for the pointers, cjwatson and sarnold
[23:37] <cjwatson> coo, ghc transition caused me to find a bug in LP's dep-wait handling
[23:37]  * cjwatson declines to retry that one by hand