| pitti | doko: hey, wie gehts? | 05:58 |
|---|---|---|
| LocutusOfBorg | maxb, #ubuntu-release seems more appropriate | 06:10 |
| zyga-ubuntu | cyphermox: hey, remember my network-manager/modem-manager issue? I updated this bug report with some more details: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034 | 07:58 |
| ubottu | Launchpad bug 1716034 in network-manager (Ubuntu) "Network manager stops managing Ethernet links after upgrade" [Undecided,Confirmed] | 07:58 |
| zyga-ubuntu | pitti: hey, since you wrote netplan initially, can you perhaps have a look as well? | 07:59 |
| zyga-ubuntu | pitti: tl;dr; version is that xenial -> zesty breaks networking because of a debian patch you made there | 08:00 |
| zyga-ubuntu | pitti: and perhaps you know how this was supposed to be changed on updates | 08:00 |
| juliank | xnox: Not sure if you noticed, but apt-helper wait-online (a dumb version just running nm-online/systemd-networkd-wait-online when their services are active) landed in artful. Catching up with automatic updates should be more reliable at resume now. SRUs will come in a few weeks if that works out well :) | 08:10 |
| juliank | the timeout is 30 seconds right now, we can still change that if we want to wait longer for network | 08:11 |
| juliank | (if you use multiple network management services, the time outs add up, though) | 08:11 |
| juliank | We might want to patch network manager or docker.io to make this reliable on systems with docker, as described in https://bugzilla.gnome.org/show_bug.cgi?id=787487 | 08:14 |
| ubottu | Gnome bug 787487 in general "Please add "docker[0-9]*" to 85-nm-unmanaged.rules" [Normal,New] | 08:14 |
| juliank | * more reliable | 08:14 |
| xnox | juliank, do you really need multiple wait onlines? as the networked-wait-online currently waits for any one interface to become routable. | 08:58 |
| xnox | juliank, however i think that this thus may be buggy | 08:58 |
| xnox | juliank, and there are bug reports in artful now that wait-online stuff causes boot hangs and delays as if it is not working correctly. | 08:58 |
| juliank | xnox: need is a strong word, I just figured it's the best choice. I also moved the network-online dep from the timer to the target, that might improve boot performance. | 08:59 |
| juliank | * to the service | 08:59 |
| juliank | this way basic.target does not pull it in anymore | 08:59 |
| juliank | And we only run systemd-networkd-wait-online if networkd is running; or nm-online if NetworkManager is running | 09:00 |
| juliank | because it just hung before | 09:00 |
| juliank | s/before/without the service running/ | 09:02 |
| juliank | in theory it should already not be impacting boot performance, as basic.target has a mere Wants on timers.target, and no After= | 09:03 |
| juliank | But if it did for some reason, it should be better now | 09:03 |
| pitti | zyga-ubuntu: so that's different to bug 1690992 ? I thought that already avoided the disabling on all upgrades | 09:44 |
| ubottu | bug 1690992 in network-manager (Ubuntu Zesty) "fix for bug #1569649 left NetworkManager-wait-online disabled on some systems" [Undecided,Fix released] https://launchpad.net/bugs/1690992 | 09:45 |
| zyga-ubuntu | pitti: that feels different | 09:47 |
| zyga-ubuntu | pitti: essentially N-M was igoring all but wifi | 09:47 |
| zyga-ubuntu | pitti: ethernet was disabled | 09:48 |
| zyga-ubuntu | pitti: as was my wwan (called "gsm" here) connection | 09:48 |
| zyga-ubuntu | pitti: this also affects my desktop running artful | 09:48 |
| zyga-ubuntu | pitti: (both are upgrades from xenial) | 09:48 |
| pitti | zyga-ubuntu: right, sorry, mistyped the bug #; I followed up with the right one in your's | 09:57 |
| pitti | zyga-ubuntu: I mean bug 1676547 | 09:58 |
| ubottu | bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547 | 09:58 |
| zyga-ubuntu | pitti: aha | 10:00 |
| zyga-ubuntu | pitti: how was it supposed to work? | 10:01 |
| zyga-ubuntu | pitti: the crippling file is in /usr/lib by default | 10:01 |
| zyga-ubuntu | pitti: what was to ensure that the counterweight is in /etc on non-server systems? | 10:01 |
| pitti | zyga-ubuntu: NM should continue to work as-is on updates, and not manage eth on new installs | 10:01 |
| pitti | zyga-ubuntu: the empty conf file (shadowing the one in /usr) was supposed to be created by the postinst | 10:01 |
| pitti | but apparently there was some logic error | 10:01 |
| zyga-ubuntu | pitti: why should NM not manage ethernet? | 10:02 |
| zyga-ubuntu | pitti: note *on desktops* | 10:02 |
| zyga-ubuntu | pitti: I don't mind servers | 10:02 |
| pitti | zyga-ubuntu: because on new installs netplan will do that | 10:02 |
| pitti | oh, on desktops it should manage everything, yes | 10:02 |
| pitti | but that's done by a netplan conf snippet which (re-)enables eth for NM | 10:03 |
| Unit193 | But amusingly, to remove nplan which is unused, you remove ubuntu-standard too. :P | 10:03 |
| zyga-ubuntu | pitti: but on desktop netplan is not doing anything for me | 10:03 |
| zyga-ubuntu | pitti: no default config or anything, how was it supposed to be triggered? | 10:03 |
| pitti | there should be a default config | 10:04 |
| zyga-ubuntu | where? | 10:04 |
| zyga-ubuntu | I don't see one in the package | 10:04 |
| pitti | the installer should plant an /etc/netplan/ snippet which assingns all ethernets to NM | 10:04 |
| zyga-ubuntu | /etc/netplan | 10:04 |
| zyga-ubuntu | pitti: that's on new installs, what about updates? | 10:04 |
| pitti | mind you, if that is an upgrade, none of this will/should happen | 10:04 |
| zyga-ubuntu | pitti: is this just a lot of people doing dist-upgrade the old way? | 10:04 |
| zyga-ubuntu | and then running into a problem? | 10:04 |
| pitti | on upgrades, NM is simply meant to create the empty "shadowing" of the /usr/lib/ NM config file via postinst | 10:05 |
| pitti | dist-upgrade should be fine, the logic is in postinst, not update-manager | 10:05 |
| pitti | the postinst logic was simply not sufficient | 10:05 |
| zyga-ubuntu | aha | 10:05 |
| zyga-ubuntu | I see, thank you | 10:05 |
| zyga-ubuntu | are you still interested in fixing this or ENOTIME anymore? | 10:05 |
| juliank | I thought netplan was just generating NM config files? | 10:06 |
| pitti | zyga-ubuntu: cyphermox has already fixed this, or is at it | 10:06 |
| pitti | juliank: yes, that or networkd config files, depending on the config | 10:06 |
| zyga-ubuntu | pitti: I see, thank you! | 10:06 |
| zyga-ubuntu | if dpkg --compare-versions "$2" le-nl "1.2.2-0ubuntu4"; then | 10:06 |
| zyga-ubuntu | mkdir -p /etc/NetworkManager/conf.d || true | 10:06 |
| zyga-ubuntu | # for old versions, override the global config with a null config | 10:06 |
| zyga-ubuntu | touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf | 10:06 |
| zyga-ubuntu | fi | 10:06 |
| Unit193 | juliank: It's kind of backwards though, network-manager ships the config file that disables nm by default, whereas that snippet really should be in nplan package. :P | 10:06 |
| pitti | yeah, that would work, too - feel free to toss it around :) | 10:07 |
| Unit193 | I did, the bug was closed. | 10:07 |
| zyga-ubuntu | pitti: that's in the postins file, for whatever reason it didn't run | 10:07 |
| zyga-ubuntu | pitti: thank you again! | 10:07 |
| pitti | zyga-ubuntu: the reason is that 1.2.6 was uploaded to xenial-updates | 10:08 |
| pitti | zyga-ubuntu: so the version comparison did not match any more | 10:08 |
| pitti | so I think it should just be bumped to the version that introduces the file | 10:09 |
| juliank | xnox: I think boot speed might have improved with apt 1.5~rc2 indeed. The past time it always spent 10s in userspace now it's at 5 seconds | 10:45 |
| juliank | curiously, total time went from 35s down to 20s | 10:46 |
| juliank | despite the other times being the same | 10:46 |
| juliank | A: Startup finished in 1.138s (kernel) + 9.957s (initrd) + 10.063s (userspace) = 35.269s | 10:46 |
| juliank | B: Startup finished in 1.156s (kernel) + 8.399s (initrd) + 4.632s (userspace) = 20.473s. | 10:46 |
| juliank | Although I must say that the timer or the service never was in the critical chain | 10:47 |
| juliank | Let's downgrade and reboot | 10:48 |
| juliank | and yup, it's back at 10s | 10:50 |
| juliank | But that's mostly a reporting problem I guess | 10:51 |
| juliank | If the timer depends on network-online, the boot is not considered complete. | 10:52 |
| juliank | If you move the dep to the service, the boot is considered complete earlier | 10:52 |
| juliank | But well, perception matters to | 10:52 |
| juliank | o | 10:52 |
| juliank | boot plots: https://people.debian.org/~jak/boot-rc1.svg https://people.debian.org/~jak/boot-rc2.svg | 10:52 |
| juliank | I mean, unless the timer has elapsed we don't even pull in wait-online stuff during boot anymore | 10:55 |
| === freyes__ is now known as freyes | ||
| === mnepton is now known as mneptok | ||
| sil2100 | jbicha: hey! I see | 14:55 |
| sil2100 | Argh, copy-paste error | 14:55 |
| sil2100 | jbicha: hey! I see the evolution-data-server you recently uploaded enables the installed-tests autopkgtests, but those seem to be horribly flaky | 14:56 |
| sil2100 | jbicha: they were disabled with the previous versions, now they seem to be failing in artful-proposed for some archs | 14:56 |
| sil2100 | When running on my chroot I see they're indeed very unreliable, getting different failures with every run | 14:57 |
| sil2100 | jbicha: maybe we should disable them again? | 15:05 |
| LocutusOfBorg | doko, I tried to debug potemkin-clojure failure, and I failed, do you have some debug/progress to share? | 15:13 |
| doko | no | 15:14 |
| LocutusOfBorg | maybe I'll ask to debian-java if you didn't already | 15:15 |
| LocutusOfBorg | doko, could you please include https://launchpad.net/ubuntu/+source/automake-1.15/1:1.15.1-2.1ubuntu1 if you have chances to do a new test rebuild? | 15:29 |
| juliank | So, how do the servers boot with networking? I'm currently dropping the Wants=network-online.target from apt as that has weird implications (and we have our own wait-online helper for network-manager, systemd-networkd, and connman). We still have an After=network.target, so stuff like ifupdown will still run before the service. | 15:31 |
| juliank | The question is if that's enough, or if there is something else to look out for | 15:31 |
| juliank | xenial, zesty, and artful | 15:31 |
| juliank | Well I guess it seems fine | 15:35 |
| juliank | I'm currently waiting 30s per service, so if someone has connman, NM, and systemd-networkd active, but no connection, it would wait 90s. | 15:41 |
| juliank | kind of weird | 15:41 |
| juliank | (but easy) | 15:42 |
| doko | LocutusOfBorg: the next test rebuild will be the one once glibc migrates | 15:42 |
| LocutusOfBorg | so will you include that upload? | 15:43 |
| seb128 | juliank, that might be a question for xnox | 15:43 |
| LocutusOfBorg | it is not part of artful | 15:43 |
| LocutusOfBorg | jbicha, are you located in florida? | 15:44 |
| xnox | juliank, servers default to networkd in artful and up | 15:45 |
| xnox | juliank, prior to that they defaulted to ifupdown | 15:46 |
| juliank | Right | 15:46 |
| juliank | The question was mostly solved anyway because ifupdown's wait-online helper did not exist back then | 15:46 |
| doko | cyphermox: ping nplan failures | 15:47 |
| doko | jamespage: please could you have a look at http://autopkgtest.ubuntu.com/packages/o/openvswitch/artful/i386 ? | 15:57 |
| doko | or is this temporary? | 15:57 |
| xnox | doko, unping cyphermox | 15:58 |
| xnox | doko, nplan fails due to bad base cloud-image | 15:58 |
| doko | ahh, ok | 15:58 |
| xnox | doko, and we need to get a new cloud-image which is currently broken due to multiple reasons, all of which are in various stages of being fixed. | 15:59 |
| jamespage | doko: that looks like the transient issues with had some some architectures when I did some previous uploads - the tests just timeout | 15:59 |
| doko | ok, retrying | 15:59 |
| Laney | doko: Earlier today I retried everything; openvswitch is currently running | 16:01 |
| doko | ohh, ok. so better continue tomorrow with the analysis | 16:02 |
| Laney | as you wish - some results will be in already - but I wouldn't retry things again | 16:02 |
| slangasek | colord looks crazy | 16:02 |
| slangasek | valgrind in an autopkgtest? | 16:03 |
| slangasek | ... which fails because of stderr output | 16:03 |
| nacc | heh | 16:03 |
| doko | fitspng is caused by https://sourceware.org/bugzilla/show_bug.cgi?id=16640 | 16:05 |
| ubottu | sourceware.org bug 16640 in string "string/strtok.c: undefined behaviour inconsistent between x86 and other generic code" [Minor,Resolved: fixed] | 16:05 |
| powersj | cyphermox: https://paste.ubuntu.com/25515376/ looks like the ISO tests are still getting asked for the keyboard-config, can you take another look? | 16:20 |
| === JanC_ is now known as JanC | ||
| doko | tyhicks: please could you have a look at the autopkg test failures triggered by file? | 17:09 |
| tyhicks | doko: I saw the emails come in over the weekend but haven't had a chance to look yet this morning | 17:12 |
| tyhicks | sbeattie: ^ | 17:12 |
| tyhicks | sbeattie: fyi, I restarted a test that was preventing bzr from migrating and now it looks to be ready to migrate | 17:14 |
| doko | chrisccoulson: what is our firefox story? I noticed that there were no artful uploads at all | 17:15 |
| doko | ricotz: ^^^ | 17:15 |
| sbeattie | doko, tyhicks: yeah, I was looking at the file one, debian has a newer version of diffoscope, but I haven't confirmed it addresses the failure. | 17:18 |
| sarnold | doko: I understand that artful firefox is blocked behind N different rustc update failures, a different one for each arch | 17:19 |
| doko | sarnold: https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4ubuntu1 looks fine | 17:19 |
| === nacc_ is now known as nacc | ||
| sarnold | it kinda sucks that we care about firefox on more platforms than are tier1 platforms for the rustc team | 17:19 |
| sarnold | doko: that's two releases too old | 17:20 |
| doko | ahh, ok | 17:20 |
| ricotz | sarnold, no, it is enough | 17:20 |
| ricotz | doko, hi | 17:20 |
| sarnold | ricotz: oh? I understood 1.19 was needed for the newest firefox, and 1.20 will be needed right quick.. | 17:20 |
| doko | anyway, you need to fix the glibc-2.26 triggered build failures | 17:20 |
| ricotz | sarnold, ff57 is a long way to go | 17:21 |
| chrisccoulson | doko, I just need to upload it, but it doesn't work at all on arm at the moment | 17:21 |
| ricotz | ff56 is good with 1.17.0 | 17:21 |
| ricotz | doko, yeah, confince infinity to let is pass from proposed despite the failure | 17:22 |
| doko | ? | 17:22 |
| doko | it ftbfs | 17:22 |
| ricotz | because upstream only care about tier1 archs | 17:23 |
| ricotz | e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1391126 | 17:23 |
| ubottu | Mozilla bug 1391126 in General "toolkit/components/backgroundhangmonitor/HangStack.cpp:2:10: fatal error: shared-libraries.h: No such file or directory" [Normal,New] | 17:23 |
| chrisccoulson | that's not even the main problem. If you get it to build it doesn't run, because of what looks like a miscompilation | 17:25 |
| ricotz | chrisccoulson, did you forward the rustc fix for llvm4.0 to artful? | 17:28 |
| chrisccoulson | which fix? | 17:28 |
| ricotz | add debian/patches/fix-computeKnownBits-for-ARMISD::CMOV.patch | 17:28 |
| chrisccoulson | is that not there already? | 17:29 |
| ricotz | I am asking you | 17:29 |
| ricotz | doko, ^? | 17:29 |
| chrisccoulson | oh, it's probably not. It's not in debian either | 17:30 |
| doko | I just saw that it builds on debian s390x, but not on Ubuntu | 17:30 |
| ricotz | chrisccoulson, same for llvm3.9, I guess | 17:31 |
| ricotz | chrisccoulson, doko, also, could be that ff55 is not happy with gcc7 | 17:32 |
| chrisccoulson | doko, can I get https://github.com/llvm-mirror/llvm/commit/cdc303e5ed4d3110e6f70931775a70bb1de44ed6 in llvm-toolchain-4.0 in artful please? (it's required for rust) | 17:33 |
| chrisccoulson | well, it's required for a future version of rust, that I'm in the process of preparing | 17:33 |
| chrisccoulson | it's already in the 3.9 package | 17:33 |
| xnox | doko, what package is that specifically that builds in debian, but not in ubuntu? i'm failing to get context from above | 17:34 |
| doko | xnox: firefox | 17:37 |
| xnox | phh | 17:37 |
| ricotz | chrisccoulson, I don't think it is in llvm3.9/artful | 17:37 |
| chrisccoulson | ricotz, it is | 17:38 |
| doko | chrisccoulson: if you want to use 3.9, please fix the build. or use 4.0 / 5.0 | 17:38 |
| ricotz | chrisccoulson, ah ok, missed it | 17:38 |
| xnox | doko, but debian/fedora/etc do not use piles of embedded libraries to do builds like we do. Hence it builds :-( | 17:38 |
| ricotz | especialy nss/nspr | 17:39 |
| doko | xnox: so maybe it's time to change that, at least for the architectures we are not interested in? | 17:39 |
| xnox | doko, i'm not sure anybody cares though =/ cause firefox is out of scope on s390x | 17:40 |
| doko | ohh, but then you can't build libreoffice | 17:41 |
| * doko hides | 17:41 | |
| doko | can't you run libreoffice in server mode these days? | 17:41 |
| xnox | doko, i'm sure you can boot to libreoffice, cause it embeds systemd =) | 17:43 |
| cyphermox | powersj: I think that will be fixed in a couple of hours? | 17:46 |
| powersj | cyphermox: ok thx, I'll sit tight and check results tomorrow morning | 17:46 |
| cyphermox | powersj: or it could be that I never uploaded the fix, I got distracted, oops | 17:47 |
| cyphermox | powersj: ok, the fix is in | 17:48 |
| cyphermox | it's just waiting for the d-i build to finish | 17:48 |
| powersj | ok thanks for checking! | 17:48 |
| cyphermox | once it's done building I'll take the mini.iso to make sure things are good :) | 17:48 |
| jbicha | LocutusOfBorg: yes (in FL) but I'm ok | 18:13 |
| jbicha | sil2100: yes I intend to disable them again since they're still flaky even with a few changes | 18:18 |
| === led_ir23 is now known as led_ir22 | ||
| sil2100 | jbicha: thanks! | 18:42 |
| === ubott2 is now known as ubottu | ||
| === tdaitx_ is now known as tdaitx | ||
| === dkessel_ is now known as dkessel | ||
| === andyrock_ is now known as andyrock | ||
| === stokachu_ is now known as stokachu | ||
| === LocutusO- is now known as LocutusOfBorg | ||
| xnox | cjwatson, yeah i couldn't get start-stop-daemon to do something sensible under systemd either. i think stuff interferes because there is init.d and systemd unit but i gave up. It should just work, but i'm not sure how wide spread the problem is. And I'm sure the real answer here is to do use "systemd-run" which is equivalent of "run a one-off managed service" | 23:25 |
| xnox | hm, i wonder if start-stop-daemon should really actually use systemd-run on systemd machines. | 23:26 |
| sarnold | oh god the abstractions upon abstractions .. | 23:28 |
| xnox | sarnold, it's not over until one embeds src:linux src:systemd src:network-manager! | 23:28 |
| * sarnold cries quietly in the corner | 23:29 | |
| xnox | sarnold, at least one no longer needs to embed openssl, as src:linux does that now. | 23:31 |
| sarnold | hahahaha | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
