| === JanC_ is now known as JanC | ||
| cjwatson | slangasek: debconf 1.5.63 finally implements joeyh's compromise suggestion from Debian #501767, so hopefully we can sync that once it's available | 01:26 |
|---|---|---|
| ubottu | Debian bug 501767 in debconf "[patch] hide cancel and close in the gnome frontend" [Normal,Open] http://bugs.debian.org/501767 | 01:26 |
| blahdeblah | cpaelzer: When you get in, could you spare a few minutes for a chat about lp:1593907 & lp:1577596 ? | 03:22 |
| blahdeblah | cpaelzer: I'm in UTC+10, so the earlier in your day, the better for me; non-urgent, but would like to be confident of some near future changes I'm planning for the ntp juju charm. | 03:27 |
| cpaelzer | hi blahdeblah, reading ... | 05:46 |
| blahdeblah | thanks cpaelzer | 05:47 |
| cpaelzer | blahdeblah: ok I'm context switched in - how can I help | 05:49 |
| cpaelzer | blahdeblah: those bugs are in the SRU queue "just" need sponsoring for Trusty (as I can't up there) and SRU acceptance | 05:50 |
| cpaelzer | blahdeblah: but since I'm through the discussion with infinity already I think they are good for sponsoring&acceptance to proposed as soon as the RU team gets to it | 05:50 |
| blahdeblah | cpaelzer: So both bugs seem to be targeted at the same symptom, which is that installing ntpdate stops ntp from starting. Yet the one is won't fix and the other is just waiting for SRU. | 05:51 |
| cpaelzer | blahdeblah: the won't fix is "from another time" | 05:52 |
| cpaelzer | thanks for the note, probably right to retriage that one | 05:52 |
| blahdeblah | cpaelzer: So that fix should get included in the same/a similar SRU? | 05:52 |
| slangasek | cjwatson: nice! | 05:53 |
| blahdeblah | cpaelzer: I have a need in the ntp charm to do (on trusty & xenial) the one thing that ntpdate is still useful for, which is testing a remote NTP server without setting the local clock, and I'd like to be able to install ntpdate knowing that it won't break startup of ntpd. | 05:54 |
| blahdeblah | cpaelzer: So that's a long intro to the actual question: can I have that confidence once these SRUs are complete, and is there anything I can do to add my +1 to them being needed? | 05:55 |
| cpaelzer | blahdeblah: the SRU that is in queue should fix the other bug as well, as it was a side effect of the ntpdate ifup hook stop/starting the ntpd server | 05:55 |
| cpaelzer | blahdeblah: I say should because I didn't test explicitly | 05:56 |
| blahdeblah | cool | 05:56 |
| cpaelzer | One should retest 1577596 once 1593907 is fixed | 05:56 |
| blahdeblah | (obviously I won't release this charm change without testing that) | 05:57 |
| blahdeblah | cpaelzer: And for the 2nd part of the question? :-) | 05:57 |
| cpaelzer | blahdeblah: and for the help, once 1593907 goes into proposed help to verify it | 05:58 |
| cpaelzer | blahdeblah: let me test a few bit here, probably ~30 minutes and I'll come back | 06:00 |
| cpaelzer | blahdeblah: are you still there then? | 06:00 |
| blahdeblah | Yep - another couple hours | 06:00 |
| blahdeblah | cpaelzer: I'm not familiar with the processes around entry to -proposed; is it just a matter of someone getting the time to do it, or are there further approvals needed? | 06:02 |
| cpaelzer | blahdeblah: yes right now it is down to time of the SRU team, all other steps are passed | 06:02 |
| blahdeblah | OK - thanks | 06:03 |
| cpaelzer | blahdeblah: ha I knew there was something around the logs | 06:09 |
| cpaelzer | to bad I needed 7 minutes to re-find it | 06:10 |
| cpaelzer | # ll /var/lock | 06:10 |
| cpaelzer | lrwxrwxrwx 1 root root 9 Apr 25 09:51 /var/lock -> /run/lock/ | 06:10 |
| cpaelzer | so while ugly in the sense of not makeing sense :-) | 06:10 |
| cpaelzer | the difference in the locks is not the problem | 06:10 |
| blahdeblah | That's been there for quite a while, hasn't it? | 06:10 |
| blahdeblah | I wondered why anyone cared about that | 06:10 |
| cpaelzer | /run/lock/ntpdate vs /var/lock/ntpdate | 06:10 |
| cpaelzer | blahdeblah: because it is a rare case that needs to race on startup and I think it needs a very slow or even a backgrounding ntp task to block it | 06:11 |
| cpaelzer | while I can't prove that the disentanglement of service and the hook will fix it - it will surely close parts of that racing | 06:11 |
| cpaelzer | blahdeblah: so I stay at "please retest once the other SRUed" | 06:12 |
| cpaelzer | but I'll update the bug to make people aware | 06:12 |
| blahdeblah | cool - thanks very much | 06:12 |
| cpaelzer | I wonder thou, we can even dup it now (with a good comment) and undup it if needed still | 06:12 |
| cpaelzer | but that way people get updates accordingly on the SRU | 06:12 |
| blahdeblah | makes sense to me, but some people tend to get rather agitated in bugs about rather silly little things | 06:13 |
| cpaelzer | if you care about something, you care about it - and it is hard to understand why others don't (that much) - that is the source of the agitation | 06:13 |
| blahdeblah | Maybe just a comment saying: watch this other bug for SRU please? | 06:15 |
| cpaelzer | I'm rather open and talkative in bugs | 06:15 |
| cpaelzer | blahdeblah: were you able to reproduce 1577596 or do you just know abotu it via LP? | 06:21 |
| blahdeblah | cpaelzer: I don't know what the underlying cause is, but when my laptop was on xenial I definitely experienced the symptoms. | 06:22 |
| cpaelzer | this issue had way more symptoms | 06:22 |
| cpaelzer | what I like most was the HW switch for NTP on my old laptop | 06:23 |
| blahdeblah | wat? | 06:23 |
| cpaelzer | blahdeblah: stop ntp and disable the service - you'd think this stays off right? | 06:23 |
| cpaelzer | blahdeblah: unplug the network cable, replug it, hook runs and ntp gets started unconditionally | 06:24 |
| cpaelzer | I hate this so much .... | 06:24 |
| cpaelzer | better one step at a time | 06:24 |
| blahdeblah | nasty | 06:24 |
| cpaelzer | we are lucky that it is wednesday | 06:26 |
| cpaelzer | rbasak: if you could look at 1593907 (sponsor T, and check for SRU acceptance in T to Z) that would be great | 06:26 |
| cpaelzer | rbasak: and if there are any questions let me know - I thought I handled all with infinity, but you might have new ones | 06:27 |
| blahdeblah | Would it be worth submitting a patch to Debian to switch it from sysv to systemd? | 06:27 |
| cpaelzer | blahdeblah: did you read the comments why we set won't fix ? | 06:27 |
| blahdeblah | because of minimising diff with Debian, AIUI | 06:27 |
| cpaelzer | kind of but not all of it | 06:28 |
| cpaelzer | blahdeblah: I have like 7 open ntp bugs all of them idling without response | 06:28 |
| blahdeblah | cpaelzer: with Debian? | 06:28 |
| cpaelzer | blahdeblah: yes | 06:28 |
| blahdeblah | :-\ | 06:28 |
| cpaelzer | and they would fix issue like these - ability to disable conf, avoid races, ... | 06:28 |
| cpaelzer | merges got harder and harder as the Delta grew | 06:29 |
| cpaelzer | and OTOH ntpdate - which unfortunately is most often the reason - is actually deprecated | 06:29 |
| blahdeblah | yeah, but we also don't ship its replacement :-) | 06:29 |
| cpaelzer | blahdeblah: for which use case - asking the time without updating it? | 06:30 |
| cpaelzer | that is the case I understoo d you had | 06:30 |
| blahdeblah | yeah, but ntpdate is supposed to be a generic SNTP client, which sntp is supposed to replace | 06:30 |
| cpaelzer | and we ship sntp starting with artful if that helps | 06:31 |
| blahdeblah | yeah - I've been watching that bug too | 06:31 |
| blahdeblah | Doesn't really help with charms, which basically only target LTS | 06:31 |
| cpaelzer | I feel tracked :-) | 06:31 |
| cpaelzer | blahdeblah: I assume timedatectl doesn't give you what you need? | 06:32 |
| blahdeblah | cpaelzer: TBH, I haven't looked. | 06:33 |
| * blahdeblah makes a note to do that | 06:33 | |
| cpaelzer | that is the client ntp portion in the systemd age | 06:33 |
| blahdeblah | so timedatectl is to systemd.timesyncd as ntpdate/sntp is to ntpd? | 06:34 |
| cpaelzer | now matter how modern systemd is - it makes me feel mainframy again - one thing to do everything | 06:34 |
| * blahdeblah has never felt remotely mainframy | 06:34 | |
| cpaelzer | blahdeblah: timedatectl is the control entry to systemd.timesyncd the analogism to ntpdate<->ntpd doesn't hold true | 06:35 |
| blahdeblah | ah, right | 06:35 |
| cpaelzer | but the most general use case - sync my time - can be done with it | 06:35 |
| cpaelzer | and even the ntpd client side of - and keep it synce - it will do for you | 06:36 |
| blahdeblah | I'll have a read of it, but keep in mind this is all in support of controlling ntpd config within the charm, so we don't really want systemd.timesyncd doing anything. | 06:36 |
| cpaelzer | By default is disables itself once a real ntp is around | 06:36 |
| cpaelzer | but for that timedatectl is the tool to check | 06:36 |
| blahdeblah | yep | 06:37 |
| cpaelzer | so read about it | 06:37 |
| blahdeblah | will do | 06:37 |
| juliank | doko: I'm confused by apt's gcc 7 failure. It's essentially doing std::floor(0.9 * 10), and the result seems to be 8 rather than 9 | 07:59 |
| LocutusOfBorg | slangasek, can I steal erlang? | 08:02 |
| LocutusOfBorg | hello btw | 08:02 |
| LocutusOfBorg | juliank, seems a big value of eight :) | 08:03 |
| juliank | Smaller sample code: https://paste.debian.net/976058/ | 08:04 |
| * juliank extracted the tested function here, which only removes a __builtin_expect macro call | 08:04 | |
| juliank | I don't have an artful chroot, so I can't test there, but it works just fine in unstable | 08:05 |
| LocutusOfBorg | I'm testing both artful and sid | 08:06 |
| juliank | Hmm, is 0.9 representable in float? | 08:08 |
| * juliank just noticed it's float, not double | 08:08 | |
| cpaelzer | precision should be enough for one digit I'd hope | 08:09 |
| juliank | cpaelzer: Well, I think 0.9 is not accurately representable in binary floating point | 08:10 |
| juliank | It's something like 0.89999997615814208984375 | 08:11 |
| cpaelzer | yep | 08:11 |
| juliank | And then std::floor rounds that stuff to 0.8 now instead of 0.9 as it did before | 08:11 |
| juliank | But maybe only on i386 | 08:11 |
| cpaelzer | actually it could even avoid the inaccuracy since by moving the mantisse+1 and just store a 9 inestead of .9 | 08:12 |
| cpaelzer | isn't float/double just non fraction numbers plus mantisse | 08:12 |
| cpaelzer | so it could store it accruately | 08:12 |
| * cpaelzer needs to check his memory on ieee spec on floats | 08:12 | |
| LocutusOfBorg | juliank, can''t repro on amd64 | 08:13 |
| juliank | No, the exponent is 2^something | 08:13 |
| juliank | not 10^something | 08:13 |
| juliank | So 0.9 is stored as 1.7999999523162842 * 2^-1 | 08:13 |
| juliank | I guess we could just make it add 0.1 to the result before flooring it | 08:17 |
| juliank | But it's odd that this worked with gcc 6 | 08:17 |
| juliank | and that it works fine on amd64 | 08:18 |
| cpaelzer | juliank: the paste you linked gives me 9x# + . on artful gcc-7 and xenial gcc-5 | 08:19 |
| LocutusOfBorg | g++-7 asd.cpp && ./a.out | 08:19 |
| LocutusOfBorg | [#########.] | 08:19 |
| LocutusOfBorg | same here | 08:19 |
| cpaelzer | juliank: do you get 8# ? | 08:19 |
| cpaelzer | g++-7 test.cpp -o test; ./test | 08:20 |
| cpaelzer | [#########.] | 08:20 |
| juliank | cpaelzer: I don't, doko's gcc 7 test rebuild on i386 got it: https://launchpadlibrarian.net/327296659/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz | 08:20 |
| LocutusOfBorg | on sid i386 sid amd64, artful i386, artful amd64, and both gcc-6 and gcc-7 | 08:20 |
| cpaelzer | maybe some of the simplification of the test is too simple? | 08:20 |
| juliank | Maybe | 08:21 |
| juliank | Well, it's the same function, so if it does not happen here, it's the optimizer causing trouble | 08:21 |
| juliank | The only thing I changed is remove an unlikely() in the if() | 08:21 |
| juliank | and unlikely expands to __builtin_expect(...) | 08:21 |
| LocutusOfBorg | juliank, maybe we should use O3 or similar? | 08:22 |
| juliank | No, the test rebuild used -O2 | 08:22 |
| juliank | I'm going to do a full build of APT with gcc 7, let's see if that does something | 08:22 |
| juliank | It looks weird | 08:24 |
| Unit193 | mdeslaur: Have you prepped the Irssi fixes? | 08:25 |
| juliank | Tons of shit again, like this: | 08:25 |
| juliank | /home/jak/Projects/Debian/apt/apt-pkg/statechanges.cc:103:26: warning: missed loop optimization, the loop counter may overflow [-Wunsafe-loop-optimizations] for (auto const &V: makeDpkgAvailable) | 08:25 |
| juliank | I don't maintain any counter, gcc | 08:26 |
| juliank | gcc is hardly usable anymore, if it spits out one or two warnings per file about overflowing loop counters. | 08:26 |
| juliank | And that's getting worse with each gcc release | 08:27 |
| juliank | DonKult than usually rewrites them *somehow*, usually with std::find and friends to just shut the compiler up, but that's not really sustainable, nor does it make the code any clearer | 08:29 |
| juliank | I think we should just give up and pass -Wno-unsafe-loop-optimization | 08:30 |
| juliank | Look at that tiny loop in that tiny function: http://paste.ubuntu.com/25073979/ - it gets a loop counter may overflow function | 08:31 |
| juliank | There is *nothing* in there that could overflow | 08:31 |
| Unit193 | mdeslaur: Well, just in case you didn't: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8039406/+listing-archive-extra | 08:34 |
| juliank | Yay, that example causes the issue even when minimalized | 08:34 |
| juliank | This minimal example causes loop warnings with g++7, but not with g++6: http://paste.ubuntu.com/25073998/ | 08:36 |
| juliank | Compile with g++ -c -O2 -Wunsafe-loop-optimizations | 08:36 |
| cpaelzer | when doing that on an older compile you need -std=gnu++11 btw to allow the loop style | 08:40 |
| LocutusOfBorg | slangasek, I'm uploading it, it seems to make the whole erlang stuck | 08:41 |
| LocutusOfBorg | please forgive me | 08:43 |
| juliank | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 | 08:46 |
| ubottu | gcc.gnu.org bug 81408 in c++ "Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6" [Normal,Unconfirmed] | 08:46 |
| mwhudson | hmm new chromium is segfaulting for me | 08:47 |
| mwhudson | oSoMoN: hi | 08:47 |
| mwhudson | oh maybe that's fixed already | 08:48 |
| oSoMoN | mwhudson, yes, that’s fixed already (unless you’re on yakkety) | 08:57 |
| oSoMoN | hopefully you’re not | 08:57 |
| juliank | infinity: do the build chroots still work now that they run on apt's new https method (did you remove the apt-transport-https yet? It's not used anymore!) | 08:59 |
| juliank | Hmm, I should follow up on the email | 09:00 |
| juliank | Ah, I did | 09:00 |
| mwhudson | oSoMoN: nah xenial | 09:04 |
| rbasak | cpaelzer: I don't see anything in Z to reject - just one ubuntu1.2 in the queue. Is that expected? | 09:17 |
| juliank | The next round of APT SRUs will get proper tracking bugs again, I'm about to finalize 1.4.7 any time. It goes stretch->zesty, so it needs debian-release approval and they are a bit picky about the changelog :) | 09:19 |
| cpaelzer | rbasak: in regard to what are you asking about the reject? | 09:20 |
| rbasak | cpaelzer: right - I've rejected the burned versions from X and Y but I see nothing for Z except the unburned one. Thought I'd double check with you that I've got the right versions of everything before I start reviewing. | 09:21 |
| cpaelzer | rbasak: ntp_4.2.8p9+dfsg-2ubuntu1.2 is the new one that I hope you can accept | 09:22 |
| cpaelzer | rbasak: there was a ntp_4.2.8p9+dfsg-2ubuntu1.1 that got superseded by the security upload | 09:23 |
| cpaelzer | https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p9+dfsg-2ubuntu1.1 | 09:23 |
| cpaelzer | ok, the old one is no more in the queue | 09:23 |
| rbasak | I found it in the rejected queu | 09:23 |
| cpaelzer | please don't ask me why rbasak - it was there just as the others | 09:23 |
| rbasak | I guess someone else rejected it? | 09:23 |
| rbasak | Or else I missed it. | 09:24 |
| rbasak | Never mind, thanks. | 09:24 |
| cpaelzer | yw, good to clear before looking at the actual SRU review | 09:24 |
| cpaelzer | rbasak: please do realize that the trusty needs sponsoring on top of the SRU upload | 09:24 |
| cpaelzer | since trusty's ntp was not yet server-dev permissions | 09:24 |
| rbasak | cpaelzer: understood. I've done it already, wearing my DMB hat | 09:24 |
| cpaelzer | thanks a lot | 09:25 |
| rbasak | As it should be in ubuntu-server-dev. | 09:25 |
| rbasak | (and thus shouldn't need sponsorship) | 09:25 |
| cpaelzer | rbasak: ok, please ping me in case there is anything you need to know on this SRU | 09:26 |
| rbasak | ack | 09:26 |
| juliank | Hmm, does 30 hosts sound like a sensible upper limit for the usual number of hosts in sources.list.(d)? I'm thinking about the wait-online helper I want to write for APT, and the timing. | 09:34 |
| juliank | My idea now that systemd is stupid, is to allow it to exponentially back off attempts. | 09:34 |
| juliank | So, it would call connect() for a host, add it to the select() set, and then call select with a 500ms() timeout | 09:35 |
| juliank | for the final host() it would call select with a (TIMEOUT - passedtime) as a timeout | 09:35 |
| juliank | Where TIMEOUT is 15s, 30s, 1m, 2m, 4m, 8m, 16m | 09:36 |
| juliank | This means that optimally, on a reasonably fast network we only do one connect() + select(), as the first host responds in 500ms | 09:36 |
| juliank | on slower networks, it would eventually respond in a later select with more fds | 09:37 |
| juliank | And with a 15s initial overall time out, that means we can wait 500ms 30 times, so we can pack 30 hosts into that time frame. If you have more, it takes longer until we retry connect() again with the first host | 09:38 |
| juliank | I guess we'll loop for about 10 hours or so | 09:38 |
| juliank | after that we fail and the service is restarted by the "12 hours later" run | 09:39 |
| Zta77 | cjwatson: I forgot to say thank you for the help yesterday: Thank you =). It helped me finally finish this little project of mine which was really nice. | 09:39 |
| juliank | OK, maybe we wait for less, not sure how the timers get delayed | 09:40 |
| cjwatson | Zta77: ah good! | 09:43 |
| juliank | Hmm, I forgot about multiple IPs per host | 09:44 |
| juliank | Hmm, that's too annoying, I might just wait 10s per host | 09:49 |
| juliank | but not really sure | 09:50 |
| juliank | I'd have to extract the getaddrinfo() stuff from the methods/connect.cc stuff | 09:50 |
| juliank | Or copy it :D | 09:52 |
| rbasak | cpaelzer: ntpdate isn't installed by default >=Xenial, right? | 10:36 |
| rbasak | So for the broken cases you list, isn't "dpkg -P ntpdate" an option? | 10:36 |
| cpaelzer | rbasak: back from lunch | 11:07 |
| cpaelzer | rbasak: yes it can be removed | 11:07 |
| cpaelzer | rbasak: it isn't an option for those who want to use it | 11:07 |
| cpaelzer | like for example blahdeblah who talked with me this morning, he is using it to check external ntp servers | 11:08 |
| cpaelzer | for that he needs to install it | 11:08 |
| cpaelzer | at the same time he doesn#t want to affect ntpd | 11:08 |
| rbasak | cpaelzer: you're modifying a conffile though, right? So he could remove the conffile himself, and packaging will maintain his choice? | 11:11 |
| cpaelzer | rbasak: also there are other packages which depend or recommend ntpdate | 11:11 |
| cpaelzer | rbasak: yes the script is in /etc and therby autp-conffile | 11:12 |
| cpaelzer | rbasak: yet the issues are too nasty to let more people debug it to eventually find it there | 11:13 |
| cpaelzer | rbasak: I'd say I know about 5 people that went to modify it on the related bugs | 11:13 |
| cpaelzer | rbasak: but I'd expect at least 5 times that much (or way more) affected without ever realizing what their problem really is | 11:13 |
| rbasak | But ntpdate shouldn't appear on a system by default I don't think. | 11:13 |
| rbasak | Except for Trusty. | 11:13 |
| rbasak | How is it that these affected users ended up with ntpdate installed in the first place? | 11:14 |
| cpaelzer | given that those bugs have like 30+ affected users reported | 11:14 |
| cpaelzer | I can't tell you why, I can only say it seems to be more than the most cornerful-cornercase | 11:14 |
| rbasak | I appreciate that it's a trade-off between people affected and risking regression to people not affected. I'm just trying to decide where I sit on that balance. | 11:15 |
| rbasak | I suspect an upgrade from Trusty to Xenial might leave ntpdate in place. | 11:15 |
| cpaelzer | it will | 11:15 |
| cpaelzer | that is where most might come from indeed | 11:15 |
| * cpaelzer checking | 11:15 | |
| cpaelzer | one of the thre bugs explicitly states upgrading as the way to get there | 11:17 |
| cpaelzer | the other two didn't go into details on why they installed it initially | 11:17 |
| cpaelzer | rbasak: just came to my mind - the change is in ntpdate as well | 11:29 |
| cpaelzer | rbasak: so if your concern - and I appreciate that you try to tihnk of issues - is to regress the majroity because they don't have ntpdate | 11:29 |
| cpaelzer | that is not an issue | 11:29 |
| cpaelzer | as the change is in ntpdate as well | 11:29 |
| cpaelzer | so we don't know if many or few have ntpdate installed | 11:30 |
| rbasak | the change is in ntpdate as well as where? | 11:30 |
| cpaelzer | but those who have it installed are affected and get the fix | 11:30 |
| cpaelzer | and those who have not will not feel anything | 11:30 |
| cpaelzer | rbasak: yes the change is to the hook that is part of the ntpdate package | 11:30 |
| cpaelzer | so we "affect" just the right subset of users | 11:30 |
| rbasak | Right. So this bug affects only users with the ntpdate package installed, and the SRU cannot regress any user who does not have the ntpdate package installed. | 11:31 |
| cpaelzer | yes | 11:31 |
| cpaelzer | that was my point | 11:31 |
| cpaelzer | sorry to get to that "argument" so late but it just crossed my mind now - didn't prepare for it :-) | 11:31 |
| rbasak | What proportion of users have the ntpdate package installed and are relying (whether they realise it or not) on its functionality? | 11:31 |
| rbasak | ...who aren't affected by this bug? | 11:32 |
| cpaelzer | I have no idea, but with systemd timesync around probably not much - the "upgraders" are the interesting subset to consider | 11:32 |
| rbasak | Right | 11:32 |
| cpaelzer | but it is not that we would drop the syncing that ntpdate does, just the stop/start of the service around it | 11:33 |
| rbasak | That's a good point. | 11:34 |
| rbasak | If ntpdate bumps the time more than a few hours, doesn't that cause ntpd to exit (by default)? | 11:34 |
| rbasak | The service restart works around that I think. | 11:34 |
| cpaelzer | no it does not, but you are in good party with infinity with that theory | 11:35 |
| cpaelzer | I think I explained in the bug a few comments above | 11:35 |
| * rbasak reads again | 11:35 | |
| cpaelzer | the default config of ntp is to allow to time warp once on start - so if you warp via ntpdate before the service is up it can adjust and drift from there | 11:35 |
| cpaelzer | vice versa if ntp is running the ntpdate will fail to set anything | 11:36 |
| cpaelzer | both cases ok | 11:36 |
| cpaelzer | actually much more ok than before if you had differing ntpdate/ntpd configurations - there without the SRU you warped one way with ntpdate and then then the other way with ntpd restarting | 11:37 |
| rbasak | How about this sequence of events: system boots with dead RTC battery, ntpd starts; ppp0 goes up; ntpd stopped; ntpdate fixes the clock; ntpd starts and keeps the clock fixed. | 11:37 |
| rbasak | Wouldn't the proposed SRU leave the clock broken in that case, if there's a gap before ppp0 is brought up? | 11:37 |
| cpaelzer | could be - I'm not sure if the ntpd would realize it can now reach new places to sync from via the ppp0 | 11:39 |
| cpaelzer | we certainly fix more cases than might be affected - but I know SRU review is about the second half | 11:40 |
| cpaelzer | need to test something | 11:40 |
| rbasak | I think I'm holding a higher bar on this because a fix is available without the SRU. | 11:40 |
| cpaelzer | please say workaround - fix is too good to call it that way | 11:41 |
| rbasak | And it feels like the fix isn't even a workaround. Unless we consider there to be a bug "ntpdate is not removed on release upgrade". | 11:41 |
| cpaelzer | there is a bug just like that | 11:41 |
| cpaelzer | https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1649729 | 11:42 |
| ubottu | Launchpad bug 1593907 in ntp (Ubuntu Zesty) "duplicate for #1649729 ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version" [Undecided,In progress] | 11:42 |
| rbasak | Perhaps it is a workaround, but in that case I don't think this SRU would fix the bug that we're working around, IFSWIM. | 11:42 |
| cpaelzer | but he essentally complains about the issues caused by ntpdate/ntp not working well together | 11:42 |
| cpaelzer | so it is s dup to the SRU actually | 11:42 |
| sil2100 | abeato: hey! | 11:43 |
| rbasak | cpaelzer: I'm torn but I'll accept I think, if you're confident? | 11:45 |
| sil2100 | abeato: could you do snap remove ubuntu-image and then snap install it from the beta channel? | 11:45 |
| sil2100 | abeato: I fixed the issues with the snap, this time I expect no more problems | 11:45 |
| sil2100 | ogra___: ^ | 11:46 |
| ogra___ | sil2100: will do later today | 11:46 |
| abeato | sil2100, sure, will try | 11:50 |
| cpaelzer | rbasak: I'm rather confident on this, but to be clear - I really appreciate you concerns and want to overcome them with facts more than by convincing | 11:51 |
| cpaelzer | and I realized this is a higher bar sicne we wouldn't have any SRUs otherwise :-P | 11:52 |
| cpaelzer | rbasak: I think we are good because of http://paste.ubuntu.com/25074802/ | 11:52 |
| cpaelzer | rbasak: that is a log of the following sequence: stop ntp, disable network, start ntp (fails to connect at 11:43:35); start network later; it starts to contact the servers | 11:53 |
| cpaelzer | rbasak: it is not a perfect test, but I think that means it would re-pick-up synchronization in the case you outlined before | 11:53 |
| cpaelzer | the env I made this in was broken due to other tests, I'll redo this on a clean environment to be "more" sure | 11:54 |
| cpaelzer | rbasak: I'll ping you then in a bit | 11:55 |
| cpaelzer | snyc image and apt install is probably the longest part of this test - so not too long | 11:55 |
| rbasak | cpaelzer: I was about to accept! :) | 11:55 |
| cpaelzer | rbasak: yeah - but I want you to like to accept it when you hit enter :-) | 11:55 |
| rbasak | Accept the package into -proposed? [yN] | 11:56 |
| * rbasak waits :-) | 11:56 | |
| abeato | sil2100, now beta works fine in zesty for me. The only issue as that I see this warning when running it: "-o/--output is deprecated; use -O/--output-dir instead", not sure if the same happens in xenial | 12:00 |
| cpaelzer | rbasak: confirmed a ntp started without net will pick up once net is available (takea about 20 seconds) | 12:02 |
| cpaelzer | rbasak: so please press yes | 12:02 |
| cpaelzer | checking an error before it is one is always better | 12:02 |
| sil2100 | abeato: yes, it's normal | 12:05 |
| sil2100 | abeato: -o is deprecated, -O is the 'right way' ;) | 12:05 |
| abeato | sil2100, ok, besides that it works well :) | 12:05 |
| sil2100 | \o/ | 12:06 |
| sil2100 | Finally! | 12:06 |
| rbasak | cpaelzer: may I have your opinion on https://bugs.launchpad.net/ubuntu/+source/libzen/+bug/1693850 please? Specifically my large file ABI question. | 12:21 |
| ubottu | Launchpad bug 1693850 in libzen (Ubuntu Zesty) "libzen wasn't compiled with large file support" [Undecided,Triaged] | 12:21 |
| cpaelzer | rbasak: reading ... | 12:29 |
| cpaelzer | rbasak: it has a symbols file | 12:34 |
| cpaelzer | rbasak: if the ABI would be hit it would pop up at build time | 12:34 |
| cpaelzer | I compare Xenial to artful, there are updates to the symbols file - albeit not a lot | 12:35 |
| cpaelzer | but if the change of the options would affect symbols it should show up there | 12:35 |
| rbasak | cpaelzer: thanks! | 12:36 |
| cpaelzer | rbasak: the only thing left is behavioural change behind same symbols - but trusting the reports a bit I'd tihnk it is either a no-op or improving (for the reported issue) | 12:36 |
| cpaelzer | rbasak: do you want me to make an update to the bug statng about the symbols file? | 12:37 |
| rbasak | cpaelzer: that'd be useful. Thanks! | 12:39 |
| === setuid_ is now known as setuid | ||
| === mariogrip_ is now known as mariogrip | ||
| === tai271828__ is now known as tai271828_ | ||
| === didrocks1 is now known as didrocks | ||
| gQuigs | before I retest with the minor debian | 13:45 |
| gQuigs | update, is there anything else I should do to move this bug along - https://bugs.launchpad.net/ubuntu/+source/ldap-auth-client/+bug/1646954 ? | 13:45 |
| ubottu | Launchpad bug 1646954 in ldap-auth-client (Ubuntu) "Sync to Debian for -ldap, drop Ubuntu's -auth-client" [Wishlist,New] | 13:45 |
| gQuigs | might be an archive admin question ^ | 13:48 |
| jbicha | LocutusOfBorg: hi, when you do merges from Debian, could you try to remember to use the -v option (from dpkg-genchanges) | 13:53 |
| jbicha | so that those who read the Ubuntu changelogs know what changed in the Debian versions | 13:53 |
| LocutusOfBorg | jbicha, why can't we have a tool for that? :( | 13:54 |
| LocutusOfBorg | having to look at which version and pass the switch requires more time than the merge itself probably | 13:54 |
| jbicha | and writing a tool to do that may take more time than just passing -v when you do the merges ;) | 13:55 |
| LocutusOfBorg | but will last forever | 13:55 |
| jbicha | go ahead and write the tool then :) | 13:56 |
| LocutusOfBorg | I'm not able to write code, seriously | 13:58 |
| jbicha | then use -v like I (try to) do :) | 13:59 |
| rbasak | wolsen: around? You need a sponsor for bug 1683076 I think? | 14:07 |
| ubottu | bug 1683076 in swift (Ubuntu Xenial) "Swift-storage dies if rsyslog is stopped" [Critical,New] https://launchpad.net/bugs/1683076 | 14:07 |
| rbasak | wolsen: I suggest three minor changes to your trusty debdiff: https://git.launchpad.net/~racb/ubuntu/+source/swift/log/?h=lp1683076-trusty | 14:08 |
| rbasak | The dep3 changes apply to your xenial debdiff too I think. But I'll accept without if you wish. | 14:09 |
| wolsen | rbasak: ah so origin, bug, and white space? | 14:15 |
| rbasak | wolsen: yeah so just metadata, nothing functional. | 14:15 |
| wolsen | rbasak: I'm happy to make those changes | 14:16 |
| rbasak | wolsen: since you've rewritten the Trusty patch I don't feel that I can accept it myself as the SRU reviewer - it needs another sponsor +1. | 14:17 |
| wolsen | rbasak: appreciate the feedback! | 14:17 |
| rbasak | wolsen: but I'm online for the next couple of hours and am happy to work the SRU queue to get everything through as you want it if you can find a sponsor. I've already reviewed my end. | 14:18 |
| wolsen | rbasak: ok - I'm still having breakfast with the family so I'll get on that when I start the day (about an hour) | 14:19 |
| rbasak | No problem. Thanks! | 14:19 |
| wolsen | thank you! | 14:20 |
| rbasak | cyphermox: around? About bug 1646585. | 14:35 |
| ubottu | bug 1646585 in ubiquity (Ubuntu Xenial) "oem-config replaces /etc/resolv.conf symlink with a hard file" [Medium,Triaged] https://launchpad.net/bugs/1646585 | 14:35 |
| rbasak | AFAICT this is waiting on a stacked xenial update from unapproved. | 14:35 |
| rbasak | Is this what you're expecting? | 14:35 |
| rbasak | I suppose you uploaded it, so I'll assume that it is. | 14:40 |
| cyphermox | rbasak: yes? | 14:44 |
| wolsen | rbasak: I just updated the debdiff for the xenial patch for bug 1683076 with your feedback. Is it possible to get the xenial one going while I get an additional sponsor for the trusty patch? | 15:53 |
| ubottu | bug 1683076 in swift (Ubuntu Xenial) "Swift-storage dies if rsyslog is stopped" [Critical,New] https://launchpad.net/bugs/1683076 | 15:53 |
| === JanC is now known as Guest95169 | ||
| === JanC_ is now known as JanC | ||
| rbasak | wolsen: it'd be nice to do both at once. Saves SRU review time. | 20:04 |
| wolsen | rbasak: that works for me | 20:04 |
| rbasak | Thanks | 20:04 |
| rbasak | wolsen: ping me when you have it sponsored and I'll sort it. | 20:04 |
| wolsen | rbasak: coreycb was kind enough to review and sponsor/upload | 20:04 |
| rbasak | Ah, thanks! | 20:05 |
| seb128 | cyphermox, slangasek, xnox, hey, not sure if you saw my ping yesterday (I missed your reply if there was any, sorry if that's the case), is any of you going to manage to look at that nplan/n-m issue this week you think? | 21:09 |
| slangasek | seb128: per cyphermox, this is a confirmed regression in NM that he had flagged before he left on vacation. AIUI he is working on working around it from the nplan side, but I guess fixing the regression would also be welcome | 21:12 |
| seb128 | slangasek, cyphermox, could you file a bug about the regression with the info you have (ideally upstream but launchpad at least would be nice)? | 21:16 |
| seb128 | slangasek, cyphermox, telling us that you looked at it enough to figure out it's a regression but giving no detail on why you think so or what you tested/how/what you think the issue is forces us basically to restart from 0 | 21:21 |
| slangasek | seb128: I'm relaying what cyphermox said here yesterday already in response to your question | 21:22 |
| seb128 | ah ok, I didn't see the reply | 21:22 |
| seb128 | slangasek, thanks | 21:22 |
| slangasek | 11-07-2017 08:57:53 <cyphermox> yes, annoying is working on unblocking that | 21:23 |
| slangasek | 11-07-2017 08:58:09 <cyphermox> fwiw, I told jbicha two weeks ago that it was a NM regression | 21:23 |
| slangasek | seb128: I don't have the context of why he relayed this info to jbicha | 21:24 |
| seb128 | right, that info should be on the corresponding launchpad bug :p | 21:24 |
| seb128 | but thanks! | 21:24 |
| seb128 | let's wait for cyphermox to be around | 21:24 |
| jbicha | oh, he marked LP: #1699371 as fix committed a few minutes ago | 21:30 |
| ubottu | Launchpad bug 1699371 in nplan (Ubuntu) "nplan autopkgtests are failing in artful (NM 1.8?)" [High,Fix committed] https://launchpad.net/bugs/1699371 | 21:30 |
| jbicha | he told me because I did the NM update but I don't understand nplan or nm well enough to do much | 21:31 |
| seb128 | jbicha, https://git.launchpad.net/netplan/commit/?id=dfe290e6 it looks like | 21:32 |
| seb128 | that doesn't make it clear why it's a n-m bug though | 21:32 |
| seb128 | or why we workaround it there rather than upstreaming the n-m issue and getting that resolved if that's a regression | 21:33 |
| === JanC_ is now known as JanC | ||
| === PaulW2U_ is now known as PaulW2U | ||
| pdeee | rbasak, thanks for moving the SRU forward | 23:11 |
| pdeee | nacc let me know if there's any way we can help with the review | 23:12 |
| nacc | pdeee: ack, thanks -- sorry have been heads down on other stuff, will look at it now | 23:25 |
| cyphermox | seb128, jbicha: that is because NM used to not manage bridges it didn't create itself, and it seems it maybe regressed in that sense. that said, it is wrong for the test to not clean up after itself anyway; and that behavior in NM might in fact be wanted given that it *did* initially manage all bridges/bonds etc, and they changed the behavior after we chimed in to say it was a problem. They could have | 23:45 |
| cyphermox | gone back on their decision | 23:45 |
| cyphermox | I don't know, I'm not really involved in NM anymore | 23:46 |
| cyphermox | now, it doesn't take much work to see what happens though; just running the autopkgtest locally and loading a shell to see what's up with the test; when it's failing it's still trying to deal with a stray br0 device | 23:47 |
| cyphermox | jbicha: for next time, if this happens, you can run the autopkgtest locally and use the -s switch to get a shell in the test environment, then use that to rerun the tests and look at nmcli or whatever, get logs, etc. | 23:48 |
| slangasek | cyphermox: fwiw I could not reproduce this issue with the autopkgtests because I could not get a clean run of the tests; they kept trashing the host network and causing all following tests to fai | 23:52 |
| slangasek | l | 23:52 |
| cyphermox | slangasek: works for me fine with a vm as a test environment | 23:53 |
| cyphermox | you definitely should not run network tests like that directly on your system | 23:53 |
| slangasek | cyphermox: this was a VM | 23:54 |
| cyphermox | err | 23:54 |
| slangasek | it was a VM whose network was configured through netplan | 23:54 |
| cyphermox | it definitely worked here, I ran it a couple dozen times to figure it out and test the fix | 23:55 |
| slangasek | and contents of /etc/netplan were disappearing when the tests ran | 23:55 |
| cyphermox | ok, I suppse I mean a vm ran using qemu straight from autopkgtest | 23:55 |
| cyphermox | maybe this should be breaks-testbed | 23:55 |
| slangasek | ah | 23:55 |
| slangasek | yeah, that sounds likely | 23:55 |
| cyphermox | otherwise yeah, the tests wipe out /etc/netplan, etc. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!