[00:41] <xnox> infinity, could we pretend libreoffice on s390x never happend on s390x, by deleting s390x binaries from xenial-release? there is new libreoffice built in s390x but need more deps build before it can migrate.
[00:41] <xnox> infinity, cause otherwise i'll need to binNMU a bunch of kde* stuff, which i'd rather just naturally build in release pocket.
[00:42] <xnox> infinity, as in, would it be terrible if libreoffice/s390x binaries would be deleted from xenial-release?
[00:44] <xnox> infinity, or like just drop libreoffice-kde from s390x on xenial-release =)
[00:48] <infinity> xnox: What problem are you trying to solve?
[00:49] <xnox> infinity, trying to migrate qt+apt+poppler
[00:49] <infinity> xnox: Which also involves migrating libreoffice?
[00:49] <infinity> xnox: If so, deleting it from release solves nothing.
[00:49] <xnox> yes. which is migratable on all but arches, apart from s390x.
[00:50] <xnox> cause libreoffice built in -release thanks to bootstrap archive skew =)
[00:50] <xnox> oh, is libreoffice at all installable in s390x release i wonder.
[00:50] <infinity> xnox: It's uninstallable in both, I'm sure, but deleting it from release doesn't fix the one in proposed.
[00:51] <infinity> xnox: britney's complaining about the one in proposed.
[00:51] <xnox> sigh.
[00:52] <xnox> and it will not migrate an uninstallable package because... ?!
[00:52] <xnox> it's not a regression.
[00:52] <infinity> Because that's the whole point of proposed-migration.
[00:52] <infinity> Literally.
[00:52] <xnox> and we didn't mark s390x as a f##ked arch
[00:52] <infinity> And we won't.
[00:53] <infinity> Because then you need to go clean up the substantial mess after.
[00:53] <infinity> Which is worse than just fixing things.
[00:53] <infinity> It's not world-ending to take a couple of days to sort it all out.
[01:32] <xnox> infinity, imho undoing things in -release would be easier, cause the whole lot is in dep-wait in release on s390x at the moment. and now i'm rebuilding on all arches, rather than just s390x.
[01:32] <xnox> infinity, thus maybe libreoffice/s390x should be removed on both -proposed and -release pockets.
[01:34] <xnox> however s390x is pretty crap at the moment
[01:34] <xnox> I: [Thu Dec 10 01:21:30 2015] - > Found 781 non-installable packages
[01:34] <xnox> which is a lot, compared with ~22-38 on all other arches
[01:38] <xnox> Laney, looks like we need all of kde built on s390x...
[01:55] <infinity> xnox: Hrm?  What needs rebuilding and why?
[01:55] <xnox> infinity, all of k* packages, cause they only have a dep-wait build records in xenial-release on s390x, rather than -proposed.
[01:55] <xnox> (those that generate libkf5*-dev packages more or less)
[01:55] <infinity> xnox: We can work around that with the bootstrap archive.
[01:56] <xnox> infinity, can you copy existing qt* packages from s390x into bootstrap archive from xenial-release please?
[01:57] <xnox> infinity, can you copy existing qt* packages from s390x into bootstrap archive from xenial-proposed please?
[01:57] <xnox> and then re-trigger builds of all failed & dep-wait packages on s390x
[01:59]  * xnox ponders why release pocket shouldn't have been building with -proposed enabled on s390x, whilst we had bootstrap archive on as well.
[02:00] <infinity> xnox: I might need a better description than "qt*"
[02:01] <xnox> infinity, qt*-opensource-src
[02:02] <infinity> xnox: That didn't help. :P
[02:04] <xnox> infinity, http://paste.ubuntu.com/13877682/
[02:06] <xnox> infinity, that's list of source package, one needs to map that to binaries and take the lot for s390x.
[02:06] <xnox> into bootstrap, and mass-rebuild.
[02:06] <infinity> There are no qt3d binaries.
[02:06] <infinity> And that source is also royally messed up in LP.  Fun.
[02:07] <infinity> wgrant: https://launchpad.net/ubuntu/+source/qt3d-opensource-src/5.5.1-4ubuntu2 <-- lolwut.
[02:07] <xnox> yeah, cause it waits on a dep-wait package, which waits on qtbase-dev in release...
[02:07] <xnox> qt3d is leaf, so skip that one.
[02:08] <xnox> some of them are arch all anyway.
[02:08] <xnox> infinity, yeah, i was not sure what was going on with the builds listings for it....
[02:10] <xnox> infinity, there are a couple arch:all only packages, so take them too.
[02:11] <xnox> does that at all sound like a reasonablish thing to do? cause then by magic binaries in -release will start to appear with the right & installable deps, and then libreoffice will migrate eventually.
[02:11] <infinity> It'll vaguely work.
[02:11] <infinity> Though, going back and getting all the arch:all packages will be annoying. :P
[02:12] <xnox> at least we will avoid rebuilding the qt/kf5* on arm64 & armhf, and running autopackage tests for all qt/kf5* on those platforms which takes eternity, compared with s390x build speed.
[02:21] <wgrant> infinity: Probably a double-accept.
[02:22] <wgrant> https://bugs.launchpad.net/launchpad/+bug/682692 ish
[02:23] <wgrant> infinity, xnox: Are those duplicated builds actually causing any problems? The successful ones look fine to me.
[02:23] <infinity> wgrant: No, probably not.
[02:24] <infinity> wgrant: Though, I'm curious what'll happen if/when those dep-waits clear.
[02:24] <wgrant> infinity: They'll fail to upload.
[02:24] <wgrant> Duplicated binaries and such
[02:27] <wgrant> xnox: Is the qt stack unlikely to migrate to release soon?
[06:18] <Mirv> xnox: ok
[06:22] <Mirv> infinity: xnox: the qt3d was first uploaded and then binaries copied from a PPA. it was a main package that had a new universe dependency, but now qt3d should be demoted to universe.
[06:22] <Mirv> wgrant: my thinking was that Qt should be migrating soon, but now I'm unsure what would be needed next
[06:40] <Mirv> infinity: xnox: hmm, actually, rmadison would tell me it was demoted in xenial but not in xenial-proposed
[06:42] <didrocks> Mirv: what's the binary/source package name exactly? I can give a hand
[07:15] <Mirv> didrocks: qt3d-opensource-src
[07:16] <Mirv> (source)
[07:20] <didrocks> Mirv: done in xenial-proposed
[07:20] <didrocks> Mirv: http://paste.ubuntu.com/13885360/ for ref
[07:26] <Mirv> didrocks: thank you!
[07:27] <didrocks> yw ;)
[08:53] <xnox> wgrant, depends if infinity copied qt 5.5 into bootstrap, and whether that helped at all or not.
[08:53] <xnox> doesn't look like the case.
[08:53]  * xnox goes to the office to meet up with Laney
[09:09] <sil2100> Hello! o/ I'm disabling the system-image importer again for a while
[09:17]  * Ukikie checked to make sure he wasn't in scrollback.
[09:56] <xnox_> cjwatson: last night, infinity and I had an interesting idea.
[09:56] <xnox_> there are a lot of things dep-waiting on qt on s390x in xenial-release, which are incidentally needed to migrate a whole bunch of things from -proposed.
[09:57] <xnox_> instead of rebuilding libkf5*-dev on all arches in -proposed, we thought that taking qt5.5/s390x from proposed and dropping it into bootstrap archive should work
[09:57] <xnox_> and then retrigger builds of everything that dep-waits on qt in xenial-release/s390x.
[09:58] <xnox_> trying things this morning it seems like stuff hasn't been copied into bootstrap archive. Could I get a dump of everything what's in the bootstrap archive and get a few things copied from -proposed.
[09:58] <xnox_> otherwise i'll be binNMUing libkf5*-dev in -proposed, and Mirv will be sad.
[10:00] <Mirv> s/Mirv/phone landers/
[10:02] <Mirv> I was still thinking that if other blockers are resolved (currently checking aptdaemon issues with apt 1.1 AFAIK), s390x being a migration blocker could be postponed. but you know better
[10:15] <xnox_> infinity: oh i see things are in place.
[10:16] <xnox_> cjwatson: never mind.
[10:20] <xnox_> ooh shiny ubuntu-build
[10:26] <xnox_> infinity: thank you a lot!
[10:30] <xnox_> Mirv: i'm not touching xenial-release, and retrying builds on s390x
[10:38] <xnox_> not touching -proposed that is.
[10:38] <xnox_> hopefully s390x builds things really fast.
[10:47] <Mirv> fastness of s390x is a nice thing :) about identical to ppc64el.
[10:51] <xnox_> Mirv: checkout https://launchpad.net/builders =)
[10:52] <xnox_> Mirv: so, hopefully i can build enough of libkf* in release without uploading anything new, thanks for bootstrap archive ;-)
[10:57] <Mirv> xnox_: nice amount of builders too. arm64 could use more.
[10:59] <Odd_Bloke> Mirv: I believe that the Launchpad team are working on ironing out the last problems with arm64 virtualised builders, after which point there should be plenty more. :)
[11:04] <Mirv> Odd_Bloke: that'll be nice
[11:31] <xnox_> trying to fix sonet
[11:31] <xnox_> *sonnet
[11:37] <xnox_> uploaded sonnet, will need it in the bootstrap archive
[11:42] <xnox_> seb128: i want all s390x debs from https://launchpad.net/ubuntu/+source/sonnet/5.15.0-0ubuntu3/+build/8419927
[11:43] <xnox_> plus _all.deb from the amd64 build
[11:43] <xnox_> https://launchpad.net/ubuntu/+source/sonnet/5.15.0-0ubuntu3/+build/8419921
[11:47] <xnox_> seb128: http://paste.ubuntu.com/13891454/
[12:04] <cjwatson> xnox_: I'll sort that out for you.
[12:04] <cjwatson> seb128: ^-
[12:04] <cjwatson> Oh, somebody already has I think?
[12:05] <seb128> cjwatson, yes, I did, sorry
[12:05] <seb128> should have updated the channel
[12:05] <seb128> (we are sitting at the same table so bypassed IRC)
[12:26] <apw> it is probabally best to leave the kernel bits in new as we have a (possibly compiler related) issue with arm64
[15:04] <xnox_> cjwatson: infinity: Laney: i have no idea what happened, but britney says newly uninstallable packages in release: ubuntu-touch
[15:08] <xnox_> xenial-release is so uninstallable on s390x, that migrating broken things brought the total number of uninstallable things down, leading to this:
[15:08] <xnox_> start: 1277+0: a-38:a-22:a-21:i-22:p-24:p-22:s-1128
[15:08] <xnox_> orig: 1277+0: a-38:a-22:a-21:i-22:p-24:p-22:s-1128
[15:08] <xnox_> easy: 1161+0: a-105:a-83:a-145:i-68:p-88:p-82:s-590
[15:09] <cjwatson> Yeah, britney will trade off between arches, unfortunately
[15:09] <cjwatson> Fix it soon :)
[15:10] <xnox_> cjwatson: yes, Laney and I are prioritising to unbreak ubuntu-touch
[15:11] <xnox_> Mirv: so everything migrated, and ubuntu-touch is uninstallable.
[15:11] <Laney> fsvo everything
[15:16] <Mirv> xnox_: weird that it did that trading, but yes let's continue fixing
[16:00] <xnox_> so it's been an hour... lp is still publishing stuff
[16:07] <cjwatson> xnox_: finished a couple of minutes before you said that, actually
[16:08] <xnox_> cjwatson: rmadison for tulip is still at 4.7 on amd64
[16:09] <xnox_> that's the last package to copy.
[16:09]  * xnox_ can check ftpmaster.internal i guess.
[16:10] <cjwatson> xnox_: rmadison lags a little
[16:10] <cjwatson> only updates once snakefruit has got round to an archive-reports run
[16:10] <cjwatson> lag will depend on whether there's something like a very slow proposed-migration run hung off that
[16:52] <xnox_> Mirv: sil2100: ubuntu-touch depends on libqt53d5-gles, should it be renamed to the new package - the renderer thing?
[16:57] <xnox_> ..
[16:58] <infinity> ubuntu-touch is irksome that way, since it has hard deps on libraries and needs to track SONAME and other transitions. :/
[16:58] <xnox_> ditto that I did to ubuntu-core-meta yesterday for apt rename.
[16:58] <infinity> Might be nice if someone wrote an intelligend update script for it so that the preprocessed deps are dev packages, and it can regenrate the library deps without a human hunting them down.
[16:58] <xnox_> ok we are pushing it.
[16:59] <infinity> intellgent, even.
[16:59] <infinity> Argh.
[16:59] <infinity> Irony++
[16:59] <infinity> INTELLIGENT.
[17:00] <infinity> xnox_: subversion merge (which will unstick git) is incoming.  Just test-building locally to make sure it's not crap.
[17:00] <xnox_> good.
[17:00] <xnox_> and i have to do mono still...
[17:02] <infinity> xnox_: Bringing us up to 4.2?
[17:02] <infinity> Which just hit unstable today...
[17:03] <infinity> xnox_: Mono doesn't need a merge, FWIW, all the Ubuntu patches should be in 4.2
[17:03] <infinity> xnox_: Can just force sync and pray.
[17:03]  * infinity might do that now.
[17:05] <infinity> Oh.  But it's arch-restricted in Debian to not build on powerpc.  Irksome.
[17:05] <infinity> I guess I do need to fix that at least.
[17:05]  * infinity will look later.
[17:08] <cjwatson> infinity: directhex deliberately dropped support for powerpc recently on the grounds that he stopped being able to get it to work
[17:09] <cjwatson> infinity: there's a bunch on debian-powerpc@ about it
[17:09] <infinity> Well, I might give it a quick once-over, but if it's not obviously fixable, we can do some cleanup, I guess.
[17:09] <infinity> arm64 is in a similar boat.
[17:10] <infinity> So, clearly we don't need mono to get by.
[17:11] <Mirv> xnox_: sil2100: please remove it altogether, ubuntu-touch does not use Qt3D at all
[17:11] <Laney> oh well, next time :)
[17:12] <Laney> ...which is now
[17:12] <Laney> because I messed up...
[17:13] <cjwatson> infinity: https://gist.github.com/directhex/2b5def025fda42cc334b I believe
[17:14] <infinity> cjwatson: Yeah, found the thread and started reading.
[17:14] <infinity> cjwatson: I think it'll be saner to do an rdep cull for now and make this a side project for if/when I have free time.
[17:14] <infinity> cjwatson: Like I said, the fact that arm64 isn't entirely busted without mono seems to prove we don't "need" it, it's just nice to have.
[17:15] <cjwatson> Probably, yeah
[20:56] <stgraber> hmm, how did that qt mess get to the release pocket? a dist-upgrade on my laptop is trying to upgrade a ton of qt stuff and resolves it by removing chunks of unity, that doesn't seem quite right :)
[20:59] <stgraber> hmm, interesting, looks like installing liboxideqt-qmlplugin solves a lot of problems, it removes two packages from my system (oxideqt-codecs-extra and qtdeclarative5-ubuntu-ui-toolkit-plugin) and makes the upgrade look sane then
[21:01] <stgraber> seems like qtdeclarative5-ubuntu-ui-toolkit-plugin still needs some love so the ubuntu-desktop task is actually installable
[21:48] <xnox> stgraber, yes. britney traded -500 of uninstallable packages for +60 packages on all other arches, sans a dozen resolved things across all architectures.
[21:48] <xnox> stgraber, we are fixing ui-toolkit yes.
[21:49] <xnox> (-500 on s390x that is, so I am very happy about that =) )