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