/srv/irclogs.ubuntu.com/2015/04/08/#ubuntu-release.txt

=== tmpRAOF is now known as RAOF
=== Termana is now known as Guest49659
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== kickinz1|afk is now known as kickinz1
Mirvhi. 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 compiz07:52
infinityMirv: Lemme have a poke.08:20
infinityrsalveti: 95% of the diff for that hybris upload seems to have nothing to do with the changelog.08:25
Mirvinfinity: thanks. oh right, there is some packages in vivid queue too.08:34
infinityMirv: vivid's sorted, except for the hybris I just asked Ricardo about.08:35
infinityMirv: BTW, is your team represented at the Launchpad stakeholders' meetings?08:53
infinityMirv: 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. :P08:53
Mirvinfinity: which of my teams you mean? :) SDK, Landing team, ?08:56
infinityMirv: Any or all who might have interest in the silo->launchpad part of landings being more smooth? :P08:56
infinitysilo->archive, I guess.08:56
MirvI guess landing team, sil2100 do you know if anyone from our side participates in ^?08:56
infinityMirv: Well, sil2100 has representation from me, as the Foundations rep at the meetings. :P08:57
Mirvinfinity: 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
infinityMirv: But I wouldn't mind people from !Foundations weighing in.08:57
Mirvinfinity: well then we have representation, and thanks for representing us! :)08:57
Mirvseriously there is not too many besides sil2100's and robru's possible input that might be needed08:58
sil2100Yeah ;p08:58
infinityMirv: I appreciate that Ricardo thinks that's the real diff, but the rest of his diff really isn't just noise...08:58
Mirvok08:59
infinityOh, ugh.  No, maybe it is.  WTF has happened here. :/09:00
infinityJust randomly moving hunks around willy-nilly.  Gross.09:00
infinityThe word for this is "unreviewable".09:00
* infinity will attempt to read it anyway.09:01
=== Guest32200 is now known as iulian
infinityrsalveti: Ahh, interdiff to the rescue, it sorted out the old debian-changes and new.09:09
infinityMirv: silo land should be happier.09:10
Mirvnice09:10
rbasakinfinity: so are you waiting for us on the FFe docker bug? Or are you expecting us to do something more?09:17
infinityrbasak: Sorry, no, I got sidetracked with 1001 things.09:18
infinityrbasak: Though, I was waiting to see if you were going to cherrypick that one debian bit.09:19
infinityrbasak: Also, does docker have a testsuite at all, or is it just "it builds, ship it"?09:19
rbasakinfinity: 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:20
rbasakinfinity: so I'd like a final answer, and then we can do it and test it and upload.09:21
rbasakkickinz1: is there a test suite that upstream use that I don't know about?09:21
infinityrbasak: 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. :P09:21
infinityrbasak: 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
rbasakI'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:23
rbasakI'm relatively new to Docker - kickinz1 and I are taking it over from jamespage.09:24
rbasakIf 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
rbasakBut 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
rbasakLike any other package.09:26
rbasak(that we might want an exception for)09:26
rbasakIf 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
rbasakAs it's pointless to ship an old version.09:27
infinityrbasak: 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:27
rbasakOh, so it FTBFS?09:28
rbasakI want 1.5 in VIvid for ppc64el support.09:28
* rbasak reads the bug09:28
rbasakI see09:28
infinityrbasak: This may be specific to the PPC situation, mind you.09:29
* infinity tries to remember those calls.09:29
infinityrbasak: Anyhow, if your by-hand testing has proven that it's not crap, you have my blessing.09:29
infinityrbasak: 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
rbasakinfinity: OK. Thanks!09:30
rbasakkickinz1: 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
rbasakinfinity: I assume arm64 is still if-it-works, and OK to upload if it doesn't?09:31
infinityrbasak: Err.  Well, it should at least build.  And work as well as it used to, whatever that was. :P09:31
infinityrbasak: But it would also be nice to look at why it doesn't work, if it's not working.09:32
rbasakI believe it never worked, previously built, but now fails to build.09:32
rbasakinfinity: 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:32
infinityrbasak: And snappy also exists on arm64...09:33
infinityIf 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:34
rbasakI'm just focused on doing one thing at once.09:35
rbasakI wouldn't accept a regression in functionality.09:35
rbasakBut 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
rbasakI 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
infinityWell, I'd kinda like to know who decided there was no regression here.09:36
infinityThe mention in the bug is based on hearsay.  Not any actual first-hand testing.09:36
rbasakWould it be sufficient to get a first hand report in the bug confirming that arm64 has never worked previously?09:37
infinityI see no evidence that you'll get that. :P09:38
rbasakI will ask09:38
infinityThe claim in the bug report is based on the first attempt in the changelog to enable it and subsequent failure.09:38
infinityAnd then doko enabled it in another upload.09:38
kickinz1rbasak, 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:38
rbasakinfinity: I was under the impression that it didn't work despite a build success.09:40
rbasakIf I'm wrong and it did work then it's reasonable to require that we don't regress it now.09:40
rbasakI'll ask about it further.09:40
infinityrbasak: There's no indication of that in the changelog (which was the source referenced in the bug).09:40
infinityrbasak: Basically, jamespage "enabled" it in ubuntu4, it FTBFS, he disabled it in ubuntu5, and then doko fixed it in the combination of 6+709:42
jamespageinfinity, rbasak: there was an issue in one of the go deps which caused the build failure09:44
jamespageI think doko fixed that up and re-enabled the support09:44
jamespagebut afaik its untested in terms of function09:44
infinityI'd bet some hyperscale people have tried it out, or their customers.09:45
jamespageinfinity, rbasak: that's quite likely - lemme check09:45
rbasakI see, thanks. I was under the impression that it was actually verified to be broken on arm64.09:45
rbasakkickinz1: 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
rbasakkickinz1: and if it fails, could you post the latest failure log to the bug please?09:46
kickinz1rbasak: I'll look, but I already tried to build with dyngccgo. Re-trying anyway.09:46
infinityI'm trying...09:47
jamespagerbasak, infinity, kickinz1: I've requested test status from the hyperscale engineering manager09:49
infinityMan, dist-upgrading rugby was a bad idea.09:55
* infinity twiddles his thumbs.09:55
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
infinitykickinz1|afk: I don't understand how that debdiff works at all, it has build-deps that aren't in Ubuntu...10:04
infinityShould we, I dunno, sync those? :P10:04
infinityAhh, that was mentioned in the bug.  Someone should have done that.10:06
infinityDoing it now.10:06
rbasakinfinity: I thought we needed the FFe approved before syncing those? :)10:07
infinityrbasak: Nah.  Random leaf packages don't break FFe.  Hard to freeze features in a package that didn't exist before.10:07
rbasakOK10:08
infinitykickinz1: So, the arm64 build dies pretty quickly with:10:56
infinityobj-aarch64-linux-gnu/src/github.com/docker/libcontainer/namespaces/init.go:202:19: error: reference to undefined identifier 'system.Setgid'10:56
kickinz1YEs I got this error before (you can see i tin the build logs in the bug comments).10:57
infinityThat seems like something that really shouldn't be arch-specific...10:58
infinityOh, you're kidding...10:59
* infinity vomits at libcontainer/system/syscall_linux_*10:59
infinitySo, that looks like it'd be trivial to fix, but wow.10:59
rbasakThat sounds like fun.10:59
rbasakAn aversion to libc?10:59
infinityWAY TO WRITE PORTABLE CODE, PEOPLE.10:59
rbasakSystem call numbers are defined in a Linux include file too!11:00
=== benonsoftware is now known as clockwork
=== clockwork is now known as benonsoftware
infinityrbasak: http://paste.ubuntu.com/10771978/11:15
infinitykickinz1: ^-- That makes it build on arm64.11:15
infinityErr, fix my bad whitespace in that first hunk. :P11:16
rbasakThanks!11:16
infinityhttp://paste.ubuntu.com/10771992/11:17
infinityThere.11:17
infinityPrettier.11:17
infinityIt still throws one compiler warning that should porbably be investigated, but otherwise seems fine.11:17
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 fail11:18
infinityTHat sounds like a toolchain/libgo issue anyway.11:18
infinityI think.11:18
infinityrbasak: 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:22
=== tmpRAOF is now known as RAOF
infinityrbasak: Ahh, I don't think docker actually calls ustat, I think it just masks the syscall, so that should be fine.11:28
infinityrbasak: So, this might actually work.11:28
=== _salem is now known as salem_
infinitymdeslaur: Ew.12:31
mdeslaurinfinity: yeah, Ew++12:31
infinitymdeslaur: Another one for the "why static linking is bad" bin, if you guys are keeping track so you have ammunition.12:32
mdeslaurinfinity: it's a macro12:32
infinitymdeslaur: I know.12:32
mdeslauroh, I see what you mean, yeah12:32
infinitymdeslaur: 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. :P12:33
mdeslauryeah, exactly12:33
jamespageScottK, 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 manually12:59
ubot93Launchpad bug 1424639 in python-eventlet (Ubuntu) "[FFE] eventlet 0.17.1" [High,New]12:59
ScottKjamespage: Approved.13:04
sturmflut-workrobru: ping13:10
rsalvetiinfinity: 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 anything15:27
rsalvetiinfinity: the mrs, if you want to take a look first: https://code.launchpad.net/~phablet-team/network-manager/ofono-format-cleanup/+merge/25530615:27
rsalvetihttps://code.launchpad.net/~phablet-team/network-manager/ofono-rm-unused-code/+merge/25530515:27
rsalvetihttps://code.launchpad.net/~phablet-team/network-manager/lp1418077/+merge/25528515:27
rsalvetiwill prepare a landing depending on your feedback15:27
robrusturmflut-work: hi16:20
=== bladernr` is now known as bladernr_
=== FunnyLookinHat_ is now known as FunnyLookinHat
infinityrsalveti: 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)22:09
=== kickinz1 is now known as kickinz1|afk
rsalvetiinfinity: yup, cool, thanks23:25

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!