[01:45] <michi> robru: Any movement on the train?
[01:45] <robru> michi: nope, everything has completely imploded. webops is on it, I can only wait for them
[01:46] <robru> michi: I blame juju
[01:46] <michi> OK. Looks like it’s in their hands :)
[01:46] <michi> No ETA, I take it?
[01:47] <robru> michi: nope. we've just begun to upgrade the juju environment, because we were running an ancient version. would not surprise me in the slightest if this took hours.
[01:47] <michi> :(
[01:47] <michi> OK, I better plan on doing something else then
[01:47] <michi> Thanks for letting me know!
[10:31] <xnox> Laney, seb128 - could libfsharp-data-typeproviders4.3-cil  please be removed? it's an "old binary" with no reverse-depends?
[10:31] <xnox> blocks fsharp from being considered - http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#fsharp
[10:32] <seb128> old as NBS?
[10:32] <xnox> si
[10:32] <xnox> well, it is built from release source, it's no longer build from proposed source
[10:32] <xnox> new package name is libfsharp-data-typeproviders4.4-ci
[10:32] <xnox> but britney is silly about it.
[10:32] <seb128> xnox, http://paste.ubuntu.com/14025753/ ?
[10:33] <xnox> let me check this
[10:33] <xnox> seb128, correct please do that =)
[10:33] <xnox> (stale package in -proposed)
[10:33] <seb128> done
[10:33] <xnox> thanks.
[10:33] <seb128> yw
[10:34] <xnox> ok, i have more
[10:35] <xnox> seb128, NBS in xenial-proposed too: libgdcm-java libgdcm2.4 libgdcm2.4-dbg libvtkgdcm-java libvtkgdcm2.4
[10:35] <seb128> same reasons?
[10:35] <xnox> yeap.
[10:35] <seb128> ah you said so, NBS
[10:36] <xnox> 2.4.4-4ubuntu2 never migrated to release, and now NBS.
[10:37] <xnox> we have nbs release & rtm...
[10:37] <xnox> can we have NBS report for -proposed i wonder.
[11:06] <xnox> seb128, Laney: so i have a proposal to unstick gdcm transition from mono transition, to migrate mono. As follows:
[11:07] <xnox> remove libvtkgdcm-cil binary from xenial-release. Which should allow removing obsolete (bogus, leaf) - activiz.net mummy boo pinta
[11:07] <xnox> and mono migrates.
[11:12] <Laney> pinta isn't obsolete?
[11:14] <xnox> Laney, what's pinta?!
[11:15] <Laney> image editing / drawing application
[11:15] <sil2100> Hey, since I see some mention of NBSes
[11:16] <sil2100> Could anyone look at LP: #1520206 ?
[11:21] <cjwatson> sil2100: checking
[11:24] <cjwatson> sil2100: done
[11:24] <sil2100> cjwatson: thank you! :)
[11:50] <Laney> xnox: Might be easiest to upload a gdcm with -cil stuff disabled, seems not to have any rdeps
[11:50] <Laney> to break them apart temporarily
[12:20] <xnox> Laney, wouldn't be removing -cil package from release have the same effect anyway?
[12:21] <xnox> i don't want to pointlessly upload a diff, to remove it after migrate. Surely we can hint britney things.
[12:22]  * xnox looks at pinta
[12:22] <Laney> Don't
[12:22] <Laney> It'll work after mono builds
[12:22] <xnox> oh
[12:23] <xnox> Laney, indeed that upload is very handy - making xbuild default to something sane.
[12:24] <Laney> yes, please make sure to remove your deltas
[12:25] <Laney> and I imagine removing gdcm-cil would work too
[12:27]  * cjwatson removes the -proposed NBS for gdcm
[12:27] <cjwatson> (a report for -proposed is unfortunately not exactly trivial though would be nice)
[12:27] <Laney> thought seb128 said he did that earlier
[12:28] <Laney> evidently not :P
[12:28] <cjwatson> appears not
[12:29] <apw> cjwatson, i have been generating an nbs report for xenial-proposed using britney's list of old binaries as it affects the kernel much of the time
[12:30] <apw> cjwatson, not sure if that can be accurate in the general case
[12:31] <cjwatson> britney's list of old binaries unfortunately includes both build failures and stuff that's intentionally not built any more
[12:31] <xnox> well, a bunch of these would go away if when autosyncs happen and a package exists in -proposed, it should remove it from -proposed first before syncing over.
[12:32] <cjwatson> I don't think that's a good idea!
[12:33] <xnox> ok.
[12:36] <apw> cjwatson, good point, it would need to elide those in concert with missing build to be useful
[12:40] <xnox> Laney, about gdcm transition. i'll need to wait forever for inisghtooolkit4 to be built, and then rebuild remaining 3 packages for the transition and it should be all good =/
[12:48] <Laney> xnox: righto
[12:48] <Laney> you want to try and split mono or just wait?
[12:49] <xnox> Laney, insighttoolkit4 takes 3 days and 4 hours to build on amd64.... unless it needs a little help and killing stray processes or some such.
[12:49] <xnox> Laney, i do want gdcm-cil things removed from -release (no rdeps) to see if mono migrates.
[12:50] <Laney> it'll need those other removals + pinta
[12:51] <xnox> well, once mono builds and becomes a candidate.
[12:51] <xnox> i re-tried no-change rebuild of pinta in my ppa, it's building (arch:all so amd64 only)
[12:51] <xnox> if it builds, i'll copy it over.
[12:51] <xnox> Laney, and it still fails with cryptic stuff https://launchpadlibrarian.net/230079759/buildlog_ubuntu-xenial-amd64.pinta_1.6-1build1_BUILDING.txt.gz
[12:51] <xnox> Actions/AddinActions.cs(28,12): error CS0234: The type or namespace name `Unix' does not exist in the namespace `Mono'. Are you missing an assembly reference?
[12:52] <xnox> et.al.
[12:55] <xnox> Laney, will you look into pinta build failure please? i am confused about it =)
[12:58] <Laney> ok
[12:58] <seb128> Laney, sorry, I queued that but was in middle of something and wanted to check rdepends etc before doing it and then I had to go for lunch
[12:58] <seb128> cjwatson, thanks for doing those
[13:16] <xnox> Laney, we can file a block for pinta, and do demote-to-proposed against it + removals, to migrate mono. unless you have thought on how to fix pinta?
[13:16]  * xnox should try building latest upstream.
[13:17] <Laney> I probably know how to do it, don't worry
[13:17] <xnox> oooh =)
[13:19] <Laney> you get the rest of the removals taken care of :P
[13:20] <Laney> hooray for incoming.d.o as proper archive
[13:27] <xnox> Laney, looks like the deps need to be bumped to 4.0.0.0__0738eb9f132ed756 from Version=2.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 or some such.
[13:47] <Laney> xnox: DONE
[13:48] <xnox> Laney, well done =)
[13:48]  * xnox ponders if i managed to figure it out too... http://paste.ubuntu.com/14027120/ i guess i should have been doing something productive.
[13:49] <Laney> umm, probably yes
[13:50] <xnox> Laney, i drop toolsversion & targetversion in my diff, but meh, same difference. anyway this is cool. once it's built and published we may be in a possition to bribe AAs to remove things to migrate mono
[14:40] <coreycb> hello, can an archive admin please remove the python3-os-win binaries?  they've been dropped for now as the upstream code is not yet py3 compatible.
[14:44]  * didrocks flushes
[14:44] <didrocks> coreycb: binary removed from xenial-proposed
[14:44] <coreycb> didrocks, thanks!
[14:44] <didrocks> yw ;)
[15:47] <xnox> fyi for everyone that looks into proposed migration insighttoolkit4 is building in a nonvirt ppa, to be copied over once it builds over the coming days.
[15:48] <xnox> building in a ppa, to avoid pointless arch-skew for it, not that it's installable anyway at the moment in -proposed.
[19:29] <xnox> was my insighttoolkit4 ppc64el build killed?
[19:30] <xnox> doko, https://launchpadlibrarian.net/230102849/buildlog_ubuntu-xenial-ppc64el.insighttoolkit4_4.8.1-1ubuntu4_BUILDING.txt.gz
[19:30] <xnox> any thoughts?
[19:30] <xnox> shall i retry?
[19:32] <cjwatson> looks like OOM, but you might as well retry
[19:37]  * xnox downloads the log
[19:37] <xnox> http://people.canonical.com/~xnox/buildlog_ubuntu-xenial-ppc64el.insighttoolkit4_4.8.1-1ubuntu4_BUILDING.txt.gz
[19:58] <infinity> cjwatson: Did we never adjust VM sizes after the mem/core discussions?
[20:03] <cyphermox> mdeslaur: I think we're missing a grub2-signed upload for grub2 2.02~beta2-9ubuntu1.6 in trusty-security.
[20:06] <mdeslaur> cyphermox: oh, d'oh
[20:06] <cyphermox> same for the other releases too
[20:07] <mdeslaur> cyphermox: It's just a no-change rebuild?
[20:07] <cyphermox> no, you also need to change the build-depends
[20:07] <mdeslaur> well, with a more recent build-dep
[20:07] <infinity> mdeslaur: With adjusted build-deps, if you're being picky, but that's not necessary.
[20:07] <infinity> mdeslaur: And it *must* build in the archive.  This needs the same procedure as kernel embargos.
[20:08] <mdeslaur> cyphermox, infinity: cool, thanks for the heads up
[20:08] <infinity> mdeslaur: ie: needs to copy from PPA to proposed, build in proposed, then release the mess to security.
[20:08] <mdeslaur> infinity: ok, so I let you know once it's in the ppa?
[20:08] <cyphermox> I only noticed it because I was preparing a SRU :/
[20:08] <mdeslaur> crud, I didn't know this was needed, sorry for the trouble
[20:08] <infinity> mdeslaur: Well, and I need to copy all your security updates to proposed. :P
[20:11]  * infinity sets about doing all of that.
[20:11] <infinity> mdeslaur: If you guys have special "Talk to Adam" instructions for kernel embargos, you might want to add grub to the same list. :P
[20:14] <infinity> mdeslaur: But, basically, the procedure for both is the same.  linux/grub2 get binary copied from PPA to proposed.  linux-signed/grub2-signed get source-only copied (or uploaded) to proposed.  When all is built and happy, the lots gets released to security/updates.
[20:17] <mdeslaur> infinity: yeah, I'll add a note to our scripts so it doesn't happen again
[20:19] <mdeslaur> infinity: uploading to ppa here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages
[20:21] <infinity> mdeslaur: Kay.  When everything looks sane on the archive side, I'll copy them over.
[20:22] <mdeslaur> I gather the ftbfs in the ppa is normal...
[20:22] <infinity> Yes.
[20:39] <infinity> mdeslaur: Alright, reviewed them all for sanity.  Will copy as soon as they'll actually be buildable.
[20:40] <mdeslaur> thanks infinity
[20:41]  * infinity runs across the street for pizza while he waits.
[22:51] <doko> xnox, you could retry. looks like the oom killer