[07:52] <Mirv> hi. we're trying to free up CI silos and there are 3 trusty landings in trusty unapproved queue that have been in the queue 1-4 weeks: indicator-session, unity and compiz
[08:20] <infinity> Mirv: Lemme have a poke.
[08:25] <infinity> rsalveti: 95% of the diff for that hybris upload seems to have nothing to do with the changelog.
[08:34] <Mirv> infinity: thanks. oh right, there is some packages in vivid queue too.
[08:35] <infinity> Mirv: vivid's sorted, except for the hybris I just asked Ricardo about.
[08:53] <infinity> Mirv: BTW, is your team represented at the Launchpad stakeholders' meetings?
[08:53] <infinity> Mirv: Cause there's an item there (soyuz redesign) that could use a vote from you guys, so you don't have to keep bugging is to clear your silos out. :P
[08:56] <Mirv> infinity: which of my teams you mean? :) SDK, Landing team, ?
[08:56] <infinity> Mirv: Any or all who might have interest in the silo->launchpad part of landings being more smooth? :P
[08:56] <infinity> silo->archive, I guess.
[08:56] <Mirv> I guess landing team, sil2100 do you know if anyone from our side participates in ^?
[08:57] <infinity> Mirv: Well, sil2100 has representation from me, as the Foundations rep at the meetings. :P
[08:57] <Mirv> infinity: re: rsalveti's libhybris there is a note: " Pkgdiff is huge because of git-buildpackage, real diff can be found at https://code-review.phablet.ubuntu.com/gitweb?p=ubuntu/libhybris.git;a=commitdiff;h=dae292c01471a1c5994c3e17befb90990cbef867;hp=0ecf8ff1f32b0ce360a1b4bc31560e9e4e19def8"
[08:57] <infinity> Mirv: But I wouldn't mind people from !Foundations weighing in.
[08:57] <Mirv> infinity: well then we have representation, and thanks for representing us! :)
[08:58] <Mirv> seriously there is not too many besides sil2100's and robru's possible input that might be needed
[08:58] <sil2100> Yeah ;p
[08:58] <infinity> Mirv: I appreciate that Ricardo thinks that's the real diff, but the rest of his diff really isn't just noise...
[08:59] <Mirv> ok
[09:00] <infinity> Oh, ugh.  No, maybe it is.  WTF has happened here. :/
[09:00] <infinity> Just randomly moving hunks around willy-nilly.  Gross.
[09:00] <infinity> The word for this is "unreviewable".
[09:01]  * infinity will attempt to read it anyway.
[09:09] <infinity> rsalveti: Ahh, interdiff to the rescue, it sorted out the old debian-changes and new.
[09:10] <infinity> Mirv: silo land should be happier.
[09:10] <Mirv> nice
[09:17] <rbasak> infinity: so are you waiting for us on the FFe docker bug? Or are you expecting us to do something more?
[09:18] <infinity> rbasak: Sorry, no, I got sidetracked with 1001 things.
[09:19] <infinity> rbasak: Though, I was waiting to see if you were going to cherrypick that one debian bit.
[09:19] <infinity> rbasak: Also, does docker have a testsuite at all, or is it just "it builds, ship it"?
[09:20] <rbasak> infinity: we can, but then I'd ask that we do another QA cycle, which is manual. There's no test suite of which we're aware, so we smoke it by hand ("can we get a shell prompt on an image from the registry?")
[09:21] <rbasak> infinity: so I'd like a final answer, and then we can do it and test it and upload.
[09:21] <rbasak> kickinz1: is there a test suite that upstream use that I don't know about?
[09:21] <infinity> rbasak: If this is our only way out of the compiler/upstream mismatch, I'm not sure I can say "no", as much as I'd like to. :P
[09:23] <infinity> rbasak: Are we going to run into that same problem inverted with the request to SRU newer docker versions to older releases?  Cause I really don't like the idea of random packages dictating insanity like uploading new toolchains to stable releases.
[09:23] <rbasak> I'm not sure I'm clear on the mismatch. Apart from it being gccgo vs. golang, we're just using the toolchains in the archive, aren't we?
[09:24] <rbasak> I'm relatively new to Docker - kickinz1 and I are taking it over from jamespage.
[09:26] <rbasak> If a newer docker version SRU requires a newer toolchain, then we'll have a problem that we'll have to tackle somehow (which maybe will mean we won't do it as we want in an SRU)
[09:26] <rbasak> But I don't think that really has a bearing on Docker in Vivid. Right now it's just in Vivid and we want to bump it.
[09:26] <rbasak> Like any other package.
[09:26] <rbasak> (that we might want an exception for)
[09:27] <rbasak> If we don't bump it, we'll be in a worse situation. The only alternative is to remove it, which I don't think we want to do.
[09:27] <rbasak> As it's pointless to ship an old version.
[09:27] <infinity> rbasak: The mismatch I refer to was the claim that the compilers in vivid can't build the docker in vivid -- it's the entire argument for the FFe.
[09:28] <rbasak> Oh, so it FTBFS?
[09:28] <rbasak> I want 1.5 in VIvid for ppc64el support.
[09:28]  * rbasak reads the bug
[09:28] <rbasak> I see
[09:29] <infinity> rbasak: This may be specific to the PPC situation, mind you.
[09:29]  * infinity tries to remember those calls.
[09:29] <infinity> rbasak: Anyhow, if your by-hand testing has proven that it's not crap, you have my blessing.
[09:30] <infinity> rbasak: If I had my way, docker would be removed from the archive and, shortly thereafter, the internet, but I don't think I'll get to win either of those.
[09:30] <rbasak> infinity: OK. Thanks!
[09:31] <rbasak> kickinz1: do you want to do the cherry-pick then to produce a final debdiff, then test that across every architecture you can? Once that's done we can upload.
[09:31] <rbasak> infinity: I assume arm64 is still if-it-works, and OK to upload if it doesn't?
[09:31] <infinity> rbasak: Err.  Well, it should at least build.  And work as well as it used to, whatever that was. :P
[09:32] <infinity> rbasak: But it would also be nice to look at why it doesn't work, if it's not working.
[09:32] <rbasak> I believe it never worked, previously built, but now fails to build.
[09:32] <rbasak> infinity: it would be nice, but I'm not sure we have the time this cycle. I have some other things I need to take care of, and kickinz1 is working on Docker for snappy too :-/
[09:33] <infinity> rbasak: And snappy also exists on arm64...
[09:34] <infinity> If it's fundamentally broken in the toolchain or something, I can accept that's the state of things today, but if it's just a "we can't be bothered to investigate" deal, I'm less sympathetic.
[09:35] <rbasak> I'm just focused on doing one thing at once.
[09:35] <rbasak> I wouldn't accept a regression in functionality.
[09:36] <rbasak> But my understanding is that there is no regression in functionality. So I'm focused on enhancing what we have right now, which is to get 1.5 in with ppc64el support within the time we have.
[09:36] <rbasak> I don't think it's fair to use that as a lever to get us to take on new functionality that didn't work before too.
[09:36] <infinity> Well, I'd kinda like to know who decided there was no regression here.
[09:36] <infinity> The mention in the bug is based on hearsay.  Not any actual first-hand testing.
[09:37] <rbasak> Would it be sufficient to get a first hand report in the bug confirming that arm64 has never worked previously?
[09:38] <infinity> I see no evidence that you'll get that. :P
[09:38] <rbasak> I will ask
[09:38] <infinity> The claim in the bug report is based on the first attempt in the changelog to enable it and subsequent failure.
[09:38] <infinity> And then doko enabled it in another upload.
[09:38] <kickinz1> rbasak, there is a test suite but it is used when built using docker in docker, I will look if wae can re-use it.
[09:40] <rbasak> infinity: I was under the impression that it didn't work despite a build success.
[09:40] <rbasak> If I'm wrong and it did work then it's reasonable to require that we don't regress it now.
[09:40] <rbasak> I'll ask about it further.
[09:40] <infinity> rbasak: There's no indication of that in the changelog (which was the source referenced in the bug).
[09:42] <infinity> rbasak: Basically, jamespage "enabled" it in ubuntu4, it FTBFS, he disabled it in ubuntu5, and then doko fixed it in the combination of 6+7
[09:44] <jamespage> infinity, rbasak: there was an issue in one of the go deps which caused the build failure
[09:44] <jamespage> I think doko fixed that up and re-enabled the support
[09:44] <jamespage> but afaik its untested in terms of function
[09:45] <infinity> I'd bet some hyperscale people have tried it out, or their customers.
[09:45] <jamespage> infinity, rbasak: that's quite likely - lemme check
[09:45] <rbasak> I see, thanks. I was under the impression that it was actually verified to be broken on arm64.
[09:46] <rbasak> kickinz1: can you see if the latest debdiff builds on arm64 now? doko's latest change makes it actually try gccgo which is what we want I guess.
[09:46] <rbasak> kickinz1: and if it fails, could you post the latest failure log to the bug please?
[09:46] <kickinz1> rbasak: I'll look, but I already tried to build with dyngccgo. Re-trying anyway.
[09:47] <infinity> I'm trying...
[09:49] <jamespage> rbasak, infinity, kickinz1: I've requested test status from the hyperscale engineering manager
[09:55] <infinity> Man, dist-upgrading rugby was a bad idea.
[09:55]  * infinity twiddles his thumbs.
[10:04] <infinity> kickinz1|afk: I don't understand how that debdiff works at all, it has build-deps that aren't in Ubuntu...
[10:04] <infinity> Should we, I dunno, sync those? :P
[10:06] <infinity> Ahh, that was mentioned in the bug.  Someone should have done that.
[10:06] <infinity> Doing it now.
[10:07] <rbasak> infinity: I thought we needed the FFe approved before syncing those? :)
[10:07] <infinity> rbasak: Nah.  Random leaf packages don't break FFe.  Hard to freeze features in a package that didn't exist before.
[10:08] <rbasak> OK
[10:56] <infinity> kickinz1: So, the arm64 build dies pretty quickly with:
[10:56] <infinity> obj-aarch64-linux-gnu/src/github.com/docker/libcontainer/namespaces/init.go:202:19: error: reference to undefined identifier 'system.Setgid'
[10:57] <kickinz1> YEs I got this error before (you can see i tin the build logs in the bug comments).
[10:58] <infinity> That seems like something that really shouldn't be arch-specific...
[10:59] <infinity> Oh, you're kidding...
[10:59]  * infinity vomits at libcontainer/system/syscall_linux_*
[10:59] <infinity> So, that looks like it'd be trivial to fix, but wow.
[10:59] <rbasak> That sounds like fun.
[10:59] <rbasak> An aversion to libc?
[10:59] <infinity> WAY TO WRITE PORTABLE CODE, PEOPLE.
[11:00] <rbasak> System call numbers are defined in a Linux include file too!
[11:15] <infinity> rbasak: http://paste.ubuntu.com/10771978/
[11:15] <infinity> kickinz1: ^-- That makes it build on arm64.
[11:16] <infinity> Err, fix my bad whitespace in that first hunk. :P
[11:16] <rbasak> Thanks!
[11:17] <infinity> http://paste.ubuntu.com/10771992/
[11:17] <infinity> There.
[11:17] <infinity> Prettier.
[11:17] <infinity> It still throws one compiler warning that should porbably be investigated, but otherwise seems fine.
[11:18] <infinity> /usr/lib/gcc/aarch64-linux-gnu/5/libgo.a(syscall.o): In function `syscall.Ustat':
[11:18] <infinity> /build/buildd/gccgo-5-5-20150401/build/aarch64-linux-gnu/libgo/libcalls.go:3356: warning: ustat is not implemented and will always fail
[11:18] <infinity> THat sounds like a toolchain/libgo issue anyway.
[11:18] <infinity> I think.
[11:22] <infinity> rbasak: No idea if it works, given the warning, it might not, but that would be doko's bug, not yours, at least it builds.
[11:28] <infinity> rbasak: Ahh, I don't think docker actually calls ustat, I think it just masks the syscall, so that should be fine.
[11:28] <infinity> rbasak: So, this might actually work.
[12:31] <infinity> mdeslaur: Ew.
[12:31] <mdeslaur> infinity: yeah, Ew++
[12:32] <infinity> mdeslaur: Another one for the "why static linking is bad" bin, if you guys are keeping track so you have ammunition.
[12:32] <mdeslaur> infinity: it's a macro
[12:32] <infinity> mdeslaur: I know.
[12:32] <mdeslaur> oh, I see what you mean, yeah
[12:33] <infinity> mdeslaur: Point being that if the few inline bits from some headers can cause this much hassle, hundreds of thousands of lines of static crap is probably worse. :P
[12:33] <mdeslaur> yeah, exactly
[12:59] <jamespage> ScottK, hey - how are you feeling re https://bugs.launchpad.net/ubuntu/+source/python-eventlet/+bug/1424639 ?  we've expanded testing - all of our kilo-3 testing was done with this version and I've covered off the other deps manually
[13:04] <ScottK> jamespage: Approved.
[13:10] <sturmflut-work> robru: ping
[15:27] <rsalveti> infinity: hey, got 3 changes for NM, but only one is a bug fix (the other 2 are just removing old code and style cleanup), wonder what would be your opinion on uploading the 3, since while cleanups can help later on when maintaining the code, they are not fixing anything
[15:27] <rsalveti> infinity: the mrs, if you want to take a look first: https://code.launchpad.net/~phablet-team/network-manager/ofono-format-cleanup/+merge/255306
[15:27] <rsalveti> https://code.launchpad.net/~phablet-team/network-manager/ofono-rm-unused-code/+merge/255305
[15:27] <rsalveti> https://code.launchpad.net/~phablet-team/network-manager/lp1418077/+merge/255285
[15:27] <rsalveti> will prepare a landing depending on your feedback
[16:20] <robru> sturmflut-work: hi
[22:09] <infinity> rsalveti: The cleanups are fine, IMO, if they're definitely unused code (the stuff wrapped in "#if 0" is clearly unused, just grep seriously hard to make sure other removed bits aren't referenced or exported somehow)
[23:25] <rsalveti> infinity: yup, cool, thanks