stgraber | xnox: https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1717404 FYI | 02:38 |
---|---|---|
ubottu | Launchpad bug 1717404 in nplan (Ubuntu) "IPv6 support regresses with nplan transition" [High,New] | 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:38 |
mwhudson | stgraber: huh | 02:40 |
mwhudson | that doesn't match my understanding of what networkd would do :/ | 02:41 |
mwhudson | presuming netplan doesn't write out any setting for IPv6AcceptRouterAdvertisements= anyway | 02:42 |
stgraber | mwhudson: yeah, I'm kinda surprised by that behavior too | 07:01 |
stgraber | mwhudson: netplan writes IPv6AcceptRA=no | 07:02 |
stgraber | mwhudson: so that explains it and confirms it's netplan's fault | 07:02 |
stgraber | mwhudson: commented in the bug with the generated networkd config | 07:03 |
mwhudson | stgraber: only if configured as a bridge or a bond? | 07:49 |
mwhudson | hm my checkout is probably stale | 07:50 |
mwhudson | stgraber: oh heh https://bugs.launchpad.net/maas/+bug/1655440 | 07:52 |
ubottu | Launchpad bug 1655440 in nplan (Ubuntu Xenial) ""unconfigured" NIC can still get IPv6 addresses via RA" [High,In progress] | 07:52 |
mwhudson | you can't win... | 07:52 |
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 | 07:56 |
Laney | pitti: phew! | 08:03 |
pitti | Laney: good morning! | 08:07 |
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:08 |
Laney | pitti: very well also! | 08:09 |
Laney | not much sun here though - autumn is coming... | 08:10 |
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:11 |
* 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:12 |
Laney | some backgrounded process was being killed when we closed the SSH connection | 08:13 |
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:16 |
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:17 |
ginggs | doko, LocutusOfBorg: julia 0.5 and 0.6 upstream are still on llvm-3.9 | 08:18 |
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:21 |
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:22 |
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:45 |
Laney | pitti: oh, hah | 08:46 |
Laney | I thought you were changing the error displayed on the web | 08:46 |
* Laney has never retried a github test | 08:47 | |
LocutusOfBorg | doko, do you want to do ldc rebuilds? are you waiting for something else? | 09:37 |
doko | LocutusOfBorg: please do if you want. looking at the blas/atlas multiarch fun currently | 09:38 |
LocutusOfBorg | sure, thanks! I will do | 09:40 |
LocutusOfBorg | doko, ldc is broken https://github.com/ldc-developers/ldc/issues/2300 | 10:24 |
doko | crap, why isn't tracked as a RC issue in Debian? | 10:26 |
doko | LocutusOfBorg: did all of your no-change upload fail? | 10:29 |
LocutusOfBorg | doko, that reason | 10:39 |
LocutusOfBorg | the maintainer opened the upstream issue :/ | 10:39 |
LocutusOfBorg | why the hell a broken ldc migrated in the first place, with all the reverse-dependencies broken | 10:44 |
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:37 |
ginggs | i'll trigger the tests | 12:39 |
ginggs | (once it is published) | 12:40 |
linuxenko | Looking for maintainer >= xenial package of https://github.com/linuxenko/chkservice | 13:27 |
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 | 13:46 |
linuxenko | ginggs , thanks | 14:18 |
doko | LocutusOfBorg: why does llvm test x86 codegen on armhf? \o/ | 14:26 |
ginggs | doko: python-numpy ok http://autopkgtest.ubuntu.com/packages/p/python-numpy/artful/ppc64el - tests are queued for the other arches | 14:27 |
doko | ginggs: \o/ | 14:29 |
=== santa is now known as Guest98110 | ||
LocutusOfBorg | doko, I don't get what you mean :) | 14:54 |
doko | LocutusOfBorg: the llvm testsuite runs the x86 codegen changes on the armhf build | 14:56 |
LocutusOfBorg | don't really know... | 14:57 |
doko | ginggs: oops, removed the block-proposed from astroml too early ... | 15:10 |
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:14 |
ginggs | doko: and it looks like a loss of precision in python-scipy on i386 :( | 15:15 |
slangasek | cjwatson: not yet, no | 15:16 |
cjwatson | ok | 15:16 |
=== JanC_ is now known as JanC | ||
LocutusOfBorg | doko, FYI I'm fixing hhvm builds | 16:39 |
LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/13379719 | 16:39 |
doko | already had | 16:41 |
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:53 |
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:55 |
cyphermox | your use case in particular :) | 16:56 |
LocutusOfBorg | ok | 16:56 |
LocutusOfBorg | well, my patch was more upstreamable with one #ifndef LINUX or whatever | 16:58 |
LocutusOfBorg | but meh :) | 16:58 |
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 | 17:17 |
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:02 |
doko | ricotz: please ask the owner of the package | 18:08 |
doko | and the SRU team | 18:08 |
ricotz | doko, I was hoping this is no-brainer | 18:10 |
ricotz | chrisccoulson, hi, ^ | 18:10 |
chrisccoulson | what's it needed for? | 18:11 |
ricotz | chrisccoulson, took me a while to notice this component mismatch, while building ff57 a "new" ppa | 18:12 |
chrisccoulson | you'll have the same issue with rust, which also isn't in main (and that's not in main anywhere) | 18:14 |
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:15 |
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:17 |
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:18 |
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:19 |
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:21 |
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:22 |
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:23 |
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:24 |
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:26 |
ricotz | chrisccoulson, I guess I will leave that to you then? | 18:39 |
chrisccoulson | yeah, sure | 18:39 |
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:41 |
juliank | and all other apps have their normal colored icons | 18:42 |
juliank | (non-gnome apps) | 18:42 |
juliank | jbicha: Probably a bug, I see firefox-symbolic.svg but it is empty | 18:44 |
juliank | http://bugs.debian.org/867729 it seems | 18:47 |
ubottu | Debian bug 867729 in firefox "/usr/share/icons/hicolor/symbolic/apps/firefox-symbolic.svg: Symbolic icon file empty" [Normal,Open] | 18:47 |
jbicha | juliank: the firefox-esr icon looks fine to me in Debian Testing | 19:32 |
juliank | jbicha: ok, but it's definitely not working in the non-esr variant :D | 19:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!