[14:12] <cyphermox> infinity: hey, I just remember now. did you contact design about updating the slideshow?
[14:53] <infinity> cyphermox: Nope.  That needs doing.
[14:55] <cyphermox> infinity: k. I will contact people.
[15:00] <kickinz1> o/
[15:00] <rbasak> infinity: kickinz1 has done some testing and prepared a summary of our proposed docker 1.5 bump in bug 1430760 that I think answers your questions. Could you review please?
[15:00] <rbasak> doko: ^^ any comments?
[15:02] <elfy> cyphermox: you managed to get anywhere with the halt after removing install medium in vivid at all?
[15:07] <cyphermox> elfy: not yet :(
[15:07] <cyphermox> I did nail the oem-config though
[15:07] <elfy> okey doke
[15:09] <cyphermox> I'm getting back to getting plymouth to catch input right after my meetings
[15:10] <infinity> cyphermox: Ta.
[15:10] <infinity> rbasak: I can look after this meeting.
[15:10] <rbasak> Thank you!
[15:11] <doko> rbasak, are all build-deps in vivid?
[15:12] <rbasak> doko, infinity: oh, good point, sorry. I forgot about that.
[15:12] <rbasak> We had to sync two packages from Debian.
[15:12] <rbasak> They'd be NEW in Vivid.
[15:12] <rbasak> I will update the bug.
[15:14] <doko> rbasak, gccgo-go [powerpc] drop this, not necessary anymore
[15:15] <rbasak> doko: OK, no problem. I didn't know why that was needed - your changelog entry didn't say.
[15:15] <rbasak> kickinz1: ^^
[15:15] <rbasak> Bug updated noting the two new build deps.
[15:16] <kickinz1> rbasak, OK, was updating bug also...
[15:16] <doko> rbasak, that was working around issue in gccgo-5 on powerpc, not needed anymore
[15:17] <doko> rbasak, any idea why arm64 fails to build?
[15:17] <rbasak> doko: no, but I didn't pay much attention because I'm told it was broken previously, so there's no regression there.
[15:18] <rbasak> I'm treating arm64 as a separate effort that I haven't taken on right now.
[15:18] <doko> +ifeq ($(DEB_BUILD_ARCH),ppc64el)
[15:18] <doko> +    DOCKER_BUILD_TARGET = dyngccgo
[15:18] <doko> +else
[15:18] <doko> +    DOCKER_BUILD_TARGET = dynbinary
[15:18] <doko> +endif
[15:18] <doko> +
[15:18] <doko> this looks wrong ...
[15:19] <rbasak> The patches add a new build target, so we use it on ppc64el. Why is it wrong?
[15:19] <doko> should be ifneq (,$(filter $(DEB_HOST_ARCH), arm64 powerpc ppc64el))
[15:20] <rbasak> And armhf maybe? But it builds and works on armhf with golang-go it seems?
[15:20] <doko> yes, unless you want to use gccgo on armhf
[15:20] <kickinz1> rbasak: yes, builds and seems to work on armhf
[15:20] <rbasak> OK. I have no objection to changing it to your conditional then.
[15:22] <doko> rbasak, do you have a build log for arm64?
[15:23] <kickinz1> doko, I'll get it
[15:24] <rbasak> doko: OOI, why DEB_HOST_ARCH instead of DEB_BUILD_ARCH?
[15:25] <rbasak> Shouldn't the choice of compiler be based on the target architecture?
[15:25] <flexiondotorg> cyphermox, That reference to "plymouth catching input" is that to to fix the issue with entering the full disk encryption passphrase?
[15:26] <doko> BUILD is the arch you build on, HOST the arch you build for
[15:27] <doko> rbasak, ^^^
[15:27] <cyphermox> flexiondotorg: no
[15:27] <cyphermox> it's on shutdown
[15:28] <infinity> rbasak: HOST is the architecture that will be hosting the binaries, BUILD is the arch that's building them.  And yes, we all know it's confusing, and we're a couple decades too late to fix it. :P
[15:30] <rbasak> Ah. Thanks. I should have read the docs more carefully instead of assuming.
[15:30] <doko> and don't confuse HOST and TARGET ;-P
[15:35] <infinity> doko: And then throw all the assumptions out the window when dealing with the kernel, where they renamed everything to make sense, but completely conflict with compiler tradition.
[16:08] <kickinz1> doko, sorry was in a meeting.
[16:26] <slangasek> infinity: looks like update-manager is particularly unhappy with debconf passthrough failures from kernel postinsts
[16:28] <infinity> slangasek: Like, somehow more unhappy than it is with libc6? :P
[16:28] <infinity> slangasek: Or the same brand of unhappy?
[16:28] <slangasek> infinity: I never had to run 'apt-get -f install' for libc6
[16:28] <slangasek> and I'm now getting very bizarre backtraces from u-m
[16:28] <infinity> slangasek: Oh, but that's just pure luck because libc6 debconfs in preinst.
[16:29] <slangasek> actually no, because while I said postinst, looking closely I see that linux-image is also failing in preinst
[16:30] <infinity> Bleh.  I guess I'll bump "figuring out HTF to debug that" further up the list.
[16:33] <apw> slangasek, is that our breakage, or just breakage and we're the victim
[16:33] <infinity> apw: The latter.
[16:33]  * slangasek nods
[16:35] <infinity> I actually dreamt that I fixed the bug the other night, and woke up remembering just enough of the dream to realize that my subconscious is a very, very bad programmer.
[16:35] <infinity> "No, like, really, if you just insert a banana in this loop here, everything works."
[16:40] <slangasek> heh
[16:40] <slangasek> "bug in debconf passthrough; ate more fiber"
[16:40] <kickinz1> doko, rbasak: just updated bug logs with arm64 builds (both golang and gccgo).
[16:41] <doko> kickinz1, arm64 golang?
[16:42] <infinity> slangasek: Too far.
[16:42]  * infinity drafts an HR complaint.
[16:44] <kickinz1> doko, I just tried, didn't check. there seems to be a golang package available for arm64 as it is all arch.
[16:46] <ogra_> infinity, but did you even try the banana thing ? probably your subconscious isnt actually that far off, you just belive it is
[16:46] <infinity> ogra_: My new laptop doesn't have a banana port.
[16:46] <ogra_> ah, damn ... technical hurdles .. yeah, thats bad then
[16:52] <doko> kickinz1, this is an old build log, copied from the debian log archive ... please don't do that. rbasak, if you have a fixed package, please test-build it on vivid/arm64
[16:52] <doko> have to run now
[16:54] <kickinz1> doko, no, I did it tueday, maybe I uploaded the bad one...
[17:10] <slangasek> infinity: because it's an Apple?
[17:13] <rbasak> doko: are you looking at the right file?
[17:13] <rbasak> doko: I see the build log kickinz1 produced. Eg: I: Finished running '/home/ubuntu/docker_test/repo/add'.
[17:13] <rbasak> (hack for sbuild to pick up new build deps not in the archive yet)
[18:22] <infinity> cyphermox: Hrm, did you really want "isolate" and not "start" in oem-config-firstboot?
[18:22] <infinity> cyphermox: The reading of isolate implies that it'll stop anything that graphical.target doesn't depend on.
[18:23] <infinity> cyphermox: Which would include, say, mysql, sshd, whatever other random things might have been running but not necessary to the target you asked for.
[18:23] <cyphermox> infinity: isolate in systemd means "change runlevel"
[18:23] <infinity> cyphermox: Also, how does this work for non-graphical systems (oem-config on a server)?
[18:23] <cyphermox> which before oem-config sounds fine, tbh
[18:24] <cyphermox> server appears to be landing in graphical.target too
[18:24] <infinity> Weird...
[18:25] <cyphermox> it's also not actually starting anything in oem-config unless you reboot into it
[18:25] <infinity> Mmkay.
[18:25] <cyphermox> from which point once it's done, it will go in graphical.target (could be any other target we want, really), to really do the rest of the startup
[18:26] <cyphermox> the point is to avoid starting getty@tty1, or display-manager, since they kind of break the oem-config
[18:28] <infinity> I love this brave new, and super-intuitive world.
[18:28] <cyphermox> ahaha
[18:28] <cyphermox> I agree with "world"
[18:29] <infinity> "I world as well!"
[18:29] <cyphermox> and new.
[18:29] <cyphermox> much less about super-intuitive.
[19:18] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/strike-thru-dupes/+merge/255131
[19:22] <tedg> So I've got a package that is in proposed, but migration is blocked on a boottest error that seems to be a known bug.
[19:23] <tedg> How do I move that along?
[19:23] <slangasek> tedg: which package and what bug?
[19:23] <tedg> Bug: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1421009
[19:23] <infinity> tedg: We just retry the test.
[19:23] <tedg> Package: ubuntu-themes
[19:24] <tedg> infinity, Is that something I can do?
[19:24] <infinity> tedg: I believe so, but not sure exactly how the permissions there work.
[19:24] <slangasek> tedg: people with the necessary jenkins access can; I also don't know what the acl is
[19:25] <infinity> tedg: I retried it, but you can see if http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/BootTest/job/vivid-boottest-ubuntu-themes/ has a "Build Now" link on the left for you after you've logged in (top right).
[19:25] <slangasek> but anyway, yeah, for a boottest failing due to an intermittent bug, we want to retry it and see it *not* fail to be sure the known bug isn't masking unknown bugs
[19:25] <tedg> infinity, I can see it, but I don't have Build Now
[19:26] <infinity> tedg: And you're logged in?
[19:26] <tedg> Yup
[19:26] <infinity> tedg: In that case, the answer to the ACL question is "no". :P
[19:26] <infinity> It should be improved to make sure people with upload rights can also twiddle tests, but I think this is one of the many warts that aren't likely to get fixed before a move away from Jenkins.
[19:26] <slangasek> addendum: "ask the QA team"
[19:27] <tedg> Well I don't have upload rights
[19:27] <infinity> Oh, in that case, nevermind.
[19:27] <infinity> Even if it was working the way I'd think it should, you wouldn't have access.
[19:27] <tedg> So the set may be correct
[19:28]  * tedg should really apply, but there are so many nice people to help
[19:30] <boiko> hello, I have two packages marked with "Regression" labels in the update excuses page (telephony-service and telepathy-ofono)
[19:30] <boiko> do I need to do anything regarding those two packages?
[19:48] <infinity> boiko: They succeeded on a retry.
[20:05] <boiko> infinity: ah nice, thanks
[22:53] <bdmurray> slangase`: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/strike-thru-dupes/+merge/255131
[22:53] <slangasek> bdmurray: ack, looking
[22:54] <slangasek> bdmurray: merged
[22:54] <bdmurray> thanks