[00:04] <nacc> intersting, the phpmyadmin build failure is reproducible locally in a chroot. But if I then immediately run the the same command (phpunit) from the failed schroot, it passes...
[06:30] <cpaelzer> nacc: I know it is in the queue because of new, already checked with rbasak but he meant there is no special action to be taken by us (other than wait to be accepted)
[06:30] <cpaelzer> nacc: we certainly can ping for it if it is still waiting in January
[09:39] <fossfreedom> sil2100: sorry - have been a bit busy.  Just noticed you have approved our merge proposal for lp:ubuntu-cdimage.  Many thanks for that!
[10:15] <akxwi-dave> Morning all, Just want to let you  know that todays iso doesn't Show the   screen to Try or Install, it goes straight to a live desktop.. our build (Xubuntu) does the same as well
[10:33] <sil2100> fossfreedom: yw! That being said, I completely forgot to deploy it on cdimage - I'll do it today
[10:34] <sil2100> fossfreedom: hope all is ready to start getting those images building, right?
[10:36] <fossfreedom> sil2100: yes - I believe so - I've done an informal build today using our own internal iso builder mechanism - ISO was created and runs correctly.
[10:39] <fossfreedom> as an aside - I did see the same observation as akxwi-dave (xubuntu) - you dont see the try or install options - just jumps straight to the desktop
[11:05] <akxwi-dave> bug reported 1651716
[12:33] <sil2100> fossfreedom: anyway, enabling the crontab for daily budgie builds
[15:06] <sil2100> fossfreedom: hey! I just got a notification that the today's build of ubuntu-budgie failed
[15:07] <sil2100> fossfreedom: could you take a look why?
[15:07]  * sil2100 is a bit swarmed right now
[16:31] <GunnarHj> Are translations supposed to work for snaps? See e.g. <http://askubuntu.com/q/836483>.
[17:47] <dobey> GunnarHj: answered
[17:56] <GunnarHj> dobey: Thanks! Is that a bug in the VLC snap then? Btw, I tried the symlink "sudo ln -s /snap/vlc/1/usr/share/locale/sv/LC_MESSAGES/vlc.mo /usr/share/locale/sv/LC_MESSAGES/vlc.mo", but it didn't help. Is that because stuff outside the /snap folder isn't recognized?
[17:57] <dobey> GunnarHj: right, because the snap probably doesn't have permissions to read from the root FS (and it shouldn't)
[17:59] <GunnarHj> dobey: I see. Where do you file snap bugs? (Sorry for being lazy, but just in case you know...)
[18:00] <dobey> GunnarHj: well it's not a bug with snappy. there isn't a canonical location for filing bugs against specific snaps. you'd need to report it to whomever owns that snap in the store i guess
[18:01] <GunnarHj> dobey: Ok, I'll take a look. Thanks again!
[19:16] <gQuigs> how could I go about seeing why a package is not in the zesty archive but is in yakkety (freeipa-server)
[19:16] <gQuigs> it's not on the ftbfs list
[19:21] <slangasek> gQuigs: launchpad.net/ubuntu/+source/freeipa/+publishinghistory
[19:23] <slangasek> also, it's a bit odd that this is in yakkety-updates but not yakkety release, I'm wondering if this is partly my doing
[19:24] <gQuigs> slangasek: tjaalton.. interesting so it was deleted from the archive in yakkety, and then re-added in -updates?
[19:24] <slangasek> yes
[19:24] <slangasek> but then it didn't get forward-copied to zesty, so let me do that now
[19:24] <slangasek> (done)
[19:25] <gQuigs> slangasek: thanks!
[19:42] <lamont> should I be concerned that on zesty, when I ctl-alt-T, I get a new terminal in the current workspace, and generally get magically transported to another workspace?
[20:00] <mwhudson> morning
[20:07] <gQuigs> lamont: I'm not seeing anything out of the ordinary with Ctrl-alt-t on my zesty...
[20:11] <lamont> gQuigs: tbf, my workspace config is 4x4
[20:11] <gQuigs> ah.. yea, that's a difference..
[20:13] <sarnold> so finding your old workspace is just like playing hunt the wumpus
[20:14] <lamont> sarnold: I do have a good idea which one it is.. :p
[20:32] <mwhudson> slangasek: do you know what the story is with snapd vs ppc64el vs zesty?
[20:42] <slangasek> mwhudson: snapd vs. autopkgtest is currently a bit of a battle because of what looks like a spread regression; mvo's latest changes in 2.20.1 were thought to give us passing autopkgtests on ppc64el again otherwise
[20:46] <mwhudson> slangasek: but in fact do not?
[20:48] <slangasek> mwhudson: ok.  these test failures look different than anything I've seen before; are they new tests?
[20:48] <mwhudson> slangasek: i have no idea, it's just blocking the transition of go 1.7.4
[20:49] <slangasek> alright
[20:49] <mwhudson> i'm not averse to thinking about this if necessary, hadn't got that far yet though
[20:50] <mwhudson> inappropriate ioctl for device
[20:51] <mwhudson> i think they'll all that in fact?
[20:51] <mwhudson> ttyname fails or something obscure like that
[20:53] <slangasek> mwhudson: one fixed test vs. 2.16; one newly failing test; and one new test that fails
[20:53] <stgraber> mwhudson: inoappropriate ioctl for device on ppc64el only?
[20:53] <mwhudson> stgraber: seems so
[20:53] <slangasek> and yes those could be buggy ttyname-related assumptions
[20:54] <slangasek> could be test bug, or code bug - anyway, not anything we need to block on, I'll unblock it
[20:54] <stgraber> mwhudson: we had an issue similar to that in LXD with our exec code which needs to change the terminal mode and do some ioctls. The most common go library for this (kr/pty) assumes that the ioctls are the same on all architectures, which is wrong.
[20:54] <mwhudson> stgraber: hahaha ugh
[20:54] <stgraber> mwhudson: that's why I wrote: https://github.com/lxc/lxd/tree/master/shared/termios
[20:54] <stgraber> mwhudson: which uses cgo and the C library to do the right thing
[20:55] <mwhudson> can we get them added to x/sys/unix or something?
[20:55] <mwhudson> (apart from that not existing on powerpc, sigh)
[20:55] <slangasek> mwhudson: don't worry, powerpc shortly won't exist either
[20:55] <mwhudson> slangasek: NO MORE GCCGO!!
[20:56] <mwhudson> sounds pretty good to me
[20:56] <stgraber> mwhudson: we probably could and someone might have already done it. But we're not planning on moving LXD to sys/unix anytime soon since we do care about powerpc for xenial.
[20:56] <mwhudson> stgraber: hm, snapd does not appear to use kr/pty but it could be something similar
[20:59] <stgraber> mwhudson: oh, nevermind, the problem was the go-crypto terminal code
[21:00] <stgraber> mwhudson: so you may want to grep for that instead
[21:00] <stgraber> golang.org/x/crypto/ssh/terminal
[21:00] <mwhudson> stgraber: well snapd certainly does use x/crypto
[21:00] <stgraber> IIRC the most visible one was IsTerminal() returning false despite being attached to a tty
[21:01] <mwhudson> stgraber: yeah, that seems pretty likely to be the problem
[21:01] <stgraber> https://github.com/lxc/lxd/commit/3cd9adce8d3dafc679f5ef19a5cb3a4410e19208 is what we did to fix this
[21:02] <stgraber> in the go-crypto code, they have ioctlReadTermios which they define in _linux.go as:
[21:02] <stgraber> const ioctlReadTermios = 0x5401  // syscall.TCGETS
[21:04] <mwhudson> stgraber: someone should tell the snapd developers i guess!
[21:04] <mwhudson> (i'll file a bug after this call i'm on)
[21:05] <stgraber> though I'm confused because looking on ppc64el the ioctls for TCGETS and TCSETS match what I have on amd64, so not exactly sure what was the actual bit that deferred (maybe the termios struct, maybe one of the other arguments, ...)
[21:06] <stgraber> anyway, I'm pretty sure that if you run their testsuite again using my re-implementation (s/terminal/termios/g), it'll fix whatever failure they've got right now
[21:32] <stgraber> mwhudson: so if I'm parsing the britney output properly, the only thing which is holding lxd and probably most of the Go stack in proposed is that snapd autopkgtest failure on amd64 and i386
[21:33] <mwhudson> stgraber: oh, the "snapd/2.18+17.04ubuntu3" failure
[21:33] <stgraber> yup
[21:33] <mwhudson> stgraber: you could retry those (but not ppc64el!) against the snapd in proposed?
[21:33] <mwhudson> or i could
[21:34] <stgraber> not sure how to get autopkgtest to do that... looking at the history, we did get a succesful run 10 hours ago for snapd 2.20.1 in proposed, but I'm not sure if it was using the new x-net-dev or not
[21:34] <mwhudson> stgraber: url hacking, you add &trigger=$PKG/$VERSION to the retry url
[21:35] <mwhudson> as snapd doesn't use any dynamic linking stuff i really doubt a new/old x-net-dev matters
[21:36] <stgraber> ah, well, if it doesn't use shlibs, then it means we're good as the latest snapd was built after the new x-net-dev was uploaded and I see an autopkgtest pass for it from 10 hours ago
[21:36] <slangasek> you will shortly be able to retrigger the snapd tests without getting fancy at all, since I overrode the ppc64el failure and it's now on its way into zesty
[21:38] <stgraber> so I'm tempted to just hint snapd 2.18+17.04ubuntu3 as badtest which will clear that particular issue and probably let all of Go in. AFAICT the current snapd was built with the new x-net-dev and passed adt less than 10 hours ago, so we can just ignore the test failure from the old (currently in release pocket) snapd.
[21:38] <stgraber> especially as said snapd will be replaced by a new one from slangasek which should pass adt fine
[21:38] <mwhudson> oh heh i just requested the retries
[21:39] <mwhudson> but overriding makes sense to me i think
[21:40] <stgraber> the weird thing with those retries is that you don't actually tell autopkgtest what version of snapd you want to test against, you only tell it what triggered the test. So I don't see how retrying will now decide to take the snapd from proposed as opposed to the one from the release pocket which it's been testing against so far.
[21:40] <mwhudson> i don't understand it either but it works
[21:40] <slangasek> stgraber: the way you do it is by telling it the test is triggered by both the new snapd and the new $whatever
[21:41] <stgraber> slangasek: ah, how do you pass multiple triggers in the URL?
[21:41] <slangasek> &trigger=foo&trigger=bar, afaik
[21:41] <mwhudson> stgraber: trigger=a$2Fb&trigger=c%2Fd
[21:41] <stgraber> ah, cool, that's going to be useful :)
[21:42] <stgraber> mwhudson: I see your retries on autopkgtest.ubuntu.com now so will wait to see what happens
[23:00] <mwhudson> stgraber: looks like it worked
[23:17] <jgrimm> nacc, $ usd clone nspr
[23:17] <jgrimm> 12/21/2016 17:15:34 - ERROR:Unable to checkout ubuntu/devel, does lpusip/ubuntu/devel exist?
[23:18] <jgrimm> nacc, ^^ possibly needs a re-import?
[23:22] <nacc> jgrimm: running it now, to see