[02:38] <stgraber> xnox: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1717404 FYI
[02:38] <stgraber> xnox: going to revert from nplan back to ifupdown in LXC upstream in a couple of days if we can't get this fixed quickly as that's breaking our tests and is inconsistent with all other Linux distros
[02:38] <stgraber> cyphermox: ^
[02:40] <mwhudson> stgraber: huh
[02:41] <mwhudson> that doesn't match my understanding of what networkd would do :/
[02:42] <mwhudson> presuming netplan doesn't write out any setting for IPv6AcceptRouterAdvertisements= anyway
[07:01] <stgraber> mwhudson: yeah, I'm kinda surprised by that behavior too
[07:02] <stgraber> mwhudson: netplan writes IPv6AcceptRA=no
[07:02] <stgraber> mwhudson: so that explains it and confirms it's netplan's fault
[07:03] <stgraber> mwhudson: commented in the bug with the generated networkd config
[07:49] <mwhudson> stgraber: only if configured as a bridge or a bond?
[07:50] <mwhudson> hm my checkout is probably stale
[07:52] <mwhudson> stgraber: oh heh https://bugs.launchpad.net/maas/+bug/1655440
[07:52] <mwhudson> you can't win...
[07:56] <doko> LocutusOfBorg, ginggs: looks like beignet julia pocl still use llvm-3.8. If we can't fix that, we have to look at the test hangs on armhf
[08:03] <Laney> pitti: phew!
[08:07] <pitti> Laney: good morning!
[08:08] <Laney> hey pitti, happy friday! how are you?
[08:08] <pitti> Laney: bon vendredi à toi aussi :) I'm great, thanks! yourself?
[08:08] <pitti> finally, some sun again \o/
[08:09] <Laney> pitti: very well also!
[08:10] <Laney> not much sun here though - autumn is coming...
[08:11] <Laney> pitti: oh, did you see that we think we found out why those meson hangs were happening?
[08:11] <pitti> Laney: ooh! no, I didn't
[08:11] <Laney> just noticed that your test still uses the branch with boot-smoke disabled
[08:11] <Laney> xnox fixed it in master I think
[08:11] <pitti> yes, it's been a while since I looked into that
[08:11] <pitti> xnox: yay you! what was it, OOI?
[08:12]  * Laney feeds hamsters to alioth
[08:12] <Laney> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?id=6bd0dab41e720a297068a0600b121deb86ec5d1f
[08:12] <pitti> Laney: I just threw ~ 10 test retries against the infra for cleaning up after the regression in master (what I pinged about yesterday); but once that dust settles, I'm happy to re-run a test on amd64 against master
[08:12] <pitti> Laney: oh wow, *that* causes tempfails?
[08:13] <Laney> some backgrounded process was being killed when we closed the SSH connection
[08:16] <Laney> so the failure would have been specific to the ssh runner
[08:16] <pitti> that explains why it was fine locally with qemu
[08:17] <pitti> in retrospect it probably would have been better to just always make autopkgtest use ssh, and write the various virt backends as ssh setup scripts
[08:17] <pitti> hm, doesn't work with null/chroot/schroot, though
[08:18] <ginggs> doko, LocutusOfBorg: julia 0.5 and 0.6 upstream are still on llvm-3.9
[08:21] <doko> ginggs: but we build using 3.8
[08:21] <Laney> ah yes, this bit: https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/lib/VirtSubproc.py#n340
[08:21] <ginggs> doko: yeah, we still have julia 0.4
[08:22] <doko> ahh, ok
[08:22] <ginggs> i mean i can't even quickly pull in a new upstream to jump to a new llvm
[08:22] <ginggs> and there's some licensing issue with libgit2
[08:22] <doko> ok, trying to build on a porter box
[08:45] <pitti> Laney: thanks for https://code.launchpad.net/~pitti/autopkgtest-cloud/+git/fixes/+merge/330743 ! FYI, this is something that you use locally, not on the infra
[08:45] <pitti> (wrt. "deployed")
[08:46] <Laney> pitti: oh, hah
[08:46] <Laney> I thought you were changing the error displayed on the web
[08:47]  * Laney has never retried a github test
[09:37] <LocutusOfBorg> doko, do you want to do ldc rebuilds? are you waiting for something else?
[09:38] <doko> LocutusOfBorg: please do if you want. looking at the blas/atlas multiarch fun currently
[09:40] <LocutusOfBorg> sure, thanks! I will do
[10:24] <LocutusOfBorg> doko, ldc is broken https://github.com/ldc-developers/ldc/issues/2300
[10:26] <doko> crap, why isn't tracked as a RC issue in Debian?
[10:29] <doko> LocutusOfBorg: did all of your no-change upload fail?
[10:39] <LocutusOfBorg> doko, that reason
[10:39] <LocutusOfBorg> the maintainer opened the upstream issue :/
[10:44] <LocutusOfBorg> why the hell a broken ldc migrated in the first place, with all the reverse-dependencies broken
[12:37] <ginggs> doko: shark and python-scipy now ok, python-numpy still has an issue
[12:37] <doko> ginggs: fixed in ubtunu4
[12:37] <ginggs> doko: ah nice, thanks :)
[12:39] <ginggs> i'll trigger the tests
[12:40] <ginggs> (once it is published)
[13:27] <linuxenko> Looking for maintainer >= xenial package of https://github.com/linuxenko/chkservice
[13:46] <ginggs> linuxenko: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages but it would be better to file an RFP bug in Debian https://www.debian.org/devel/wnpp/ and an ITP bug is even better
[14:18] <linuxenko> ginggs , thanks
[14:26] <doko> LocutusOfBorg: why does llvm test x86 codegen on armhf? \o/
[14:27] <ginggs> doko: python-numpy ok http://autopkgtest.ubuntu.com/packages/p/python-numpy/artful/ppc64el - tests are queued for the other arches
[14:29] <doko> ginggs: \o/
[14:54] <LocutusOfBorg> doko, I don't get what you mean :)
[14:56] <doko> LocutusOfBorg: the llvm testsuite runs the x86 codegen changes on the armhf build
[14:57] <LocutusOfBorg> don't really know...
[15:10] <doko> ginggs: oops, removed the block-proposed from astroml too early ...
[15:14] <cjwatson> slangasek: just out of interest have you folks started consuming ubuntu-image as a snap in livefs builds yet?  I know you wanted to
[15:15] <ginggs> doko: and it looks like a loss of precision in python-scipy on i386 :(
[15:16] <slangasek> cjwatson: not yet, no
[15:16] <cjwatson> ok
[16:39] <LocutusOfBorg> doko, FYI I'm fixing hhvm builds
[16:39] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13379719
[16:41] <doko> already had
[16:53] <cyphermox> stgraber: mwhudson: well, less damage in letting autoconf work alone, so I'm in favor of reverting
[16:53] <cyphermox> stgraber: is there a way to integrate a test for this to the netplan autopkgtests so it doesn't happen again?
[16:55] <stgraber> cyphermox: not sure how your autopkgtest works, but you should be able to fake an IPv6 router with radvd easily enough
[16:55] <cyphermox> we already do, I'm meaning specifically integrated with lxd
[16:56] <cyphermox> your use case in particular :)
[16:56] <LocutusOfBorg> ok
[16:58] <LocutusOfBorg> well, my patch was more upstreamable with one #ifndef LINUX or whatever
[16:58] <LocutusOfBorg> but meh :)
[17:17] <bmw> slangasek: it looks like there's one more Certbot related package that you said you approved waiting to be accepted
[17:17] <bmw> https://launchpad.net/ubuntu/xenial/+queue
[18:02] <ricotz> doko, hi, could gcc-mozilla in trusty moved to main? https://launchpad.net/ubuntu/+source/gcc-mozilla/4.9.4-0ubuntu1~14.04.1
[18:08] <doko> ricotz: please ask the owner of the package
[18:08] <doko> and the SRU team
[18:10] <ricotz> doko, I was hoping this is no-brainer
[18:10] <ricotz> chrisccoulson, hi, ^
[18:11] <chrisccoulson> what's it needed for?
[18:12] <ricotz> chrisccoulson, took me a while to notice this component mismatch, while building ff57 a "new" ppa
[18:14] <chrisccoulson> you'll have the same issue with rust, which also isn't in main (and that's not in main anywhere)
[18:15] <ricotz> hmm, right, while those still coming from ppas this issue doesnt present itself currently
[18:15] <ricotz> what is the status of the rustc/cargo updates?
[18:15] <chrisccoulson> it's not an issue in the archive after trusty either
[18:17] <jbicha> shouldn't the ppa be set to allow universe build-depends?
[18:17] <chrisccoulson> heh, rust
[18:17] <chrisccoulson> the status with rust/cargo is that the rust tests still fail on ppc64, but work everywhere else. I just need to update cargo
[18:18] <ricotz> jbicha, it was set to be restrictive on purpose, but yeah, I loosened it again
[18:18] <ricotz> chrisccoulson, ok, cargo 0.20 is really needed
[18:18] <chrisccoulson> yeah, I'm getting to it
[18:19] <chrisccoulson> I'd be happy to never do another rust update again
[18:19] <ricotz> chrisccoulson, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/firefox-aurora/+packages
[18:19] <ricotz> I guess those rust updates will be required on a monthly basis :(
[18:21] <doko> monthly rust releases?
[18:21] <chrisccoulson> doko, yes, a new rust version is required for every firefox release
[18:21] <chrisccoulson> it sucks
[18:21] <doko> better start learning ...
[18:22] <ricotz> fun: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox#Proposed_policy_update
[18:22] <doko> chrisccoulson: you should bring up this topic at the ralley
[18:22] <chrisccoulson> doko, yeah, I will ;)
[18:23] <jbicha> ricotz: could you look into shipping a firefox-symbolic icon for vanilla GNOME? this is how Debian does it:
[18:23] <jbicha> https://anonscm.debian.org/cgit/pkg-mozilla/iceweasel.git/tree/debian/rules?h=esr52/master#n365
[18:24] <chrisccoulson> errr,  please don't touch anything branding related without first discussing it with me
[18:24] <jbicha> and Fedora just ships its own .svg https://src.fedoraproject.org/rpms/firefox/tree/master
[18:24] <jbicha> although it would be nice if someone would commit that directly to Mozilla…
[18:26] <jbicha> chrisccoulson: it's for the app icon in the GNOME Shell top bar. In the "Ubuntu" session, we are using full-color icons but upstream GNOME uses symbolic icons there
[18:39] <ricotz> chrisccoulson, I guess I will leave that to you then?
[18:39] <chrisccoulson> yeah, sure
[18:41] <juliank> jbicha: In Debian, firefox seems to have no icon, or at least not a visible on (non-esr one)
[18:41] <ricotz> chrisccoulson, this looks pretty self-explanatory https://paste.debian.net/plain/986259
[18:42] <juliank> and all other apps have their normal colored icons
[18:42] <juliank> (non-gnome apps)
[18:44] <juliank> jbicha: Probably a bug, I see firefox-symbolic.svg but it is empty
[18:47] <juliank> http://bugs.debian.org/867729 it seems
[19:32] <jbicha> juliank: the firefox-esr icon looks fine to me in Debian Testing
[19:33] <juliank> jbicha: ok, but it's definitely not working in the non-esr variant :D