| sarnold | bdmurray: 1701491 has a DpkgTerminalLog.txt that shows the openssl upgrade dying; again no actual error messages from dpkg :( | 00:51 |
|---|---|---|
| === maclin1 is now known as maclin | ||
| juliank | Hmm, there seem to be issues installing udev on armhf, causing the autopkgtests postgresql-debversion/unknown and ubiquity/unknown to fail. | 12:25 |
| juliank | Or maybe the machine was shutting down while running the tests? | 12:27 |
| juliank | Main PID: 2311 (systemd-udevd) - Status: "Shutting down..." | 12:27 |
| juliank | Well, let's try again and see if it works this time | 12:34 |
| juliank | In the apport test suite, Failed to fetch https://launchpad.net/ubuntu/+archive/primary/+files/coreutils-dbgsym_8.26-3ubuntu3_amd64.ddeb Error reading from server. Remote end closed connection [IP: 91.189.89.222 443] | 13:40 |
| juliank | It worked yesterday with apt 1.5~alpha3, so it's either the "Improve closing the TLS connection" change in 1.5~alpha4 - https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=8f5db6b513b90b6ee5b625131a25b146fa912e0d - or the server side | 13:43 |
| juliank | Maybe Launchpad is angry with apt because apt just closed the fd with an incomplete TLS closure ;) | 13:47 |
| thewillo | Hi, I noticed the daily snapshot I got yersterday isn't triggering any of the compiler segfaults previous versions were on my Ryzen 7 1700x. But right before I did that, I overclocked my ram. Now there is 2 explanations, the ram clock fixes the SMP bug I was having, or you guys are compiling with gcc-7.1.0 and/or using some workarounds | 14:01 |
| thewillo | so did you upgrade compilers for the new builds? | 14:02 |
| juliank | thewillo: It's still 6.3, but newer SVN revision | 14:08 |
| juliank | (AFAICT) | 14:08 |
| thewillo | either it's fixed with SOMETHING done different in the daily snapshot, or me overclocking my ram fixed it. I don't know which | 14:09 |
| thewillo | knowing what I do about computers I could see how overclocking the ram could possibly be a fix | 14:09 |
| thewillo | but I don't know enough to say that for sure | 14:09 |
| thewillo | i could just see how it might be something | 14:10 |
| thewillo | but I also know that compiling everything with gcc7.1 fixes it | 14:10 |
| thewillo | but first you have to compile gcc 7.1, then you have to compile it with itself, then you have to compiler your whole system | 14:11 |
| juliank | I can assure you that nobody recompiled everything | 14:12 |
| thewillo | I did... then my SSD failed | 14:13 |
| thewillo | so I had to start fresh, and I got the daily snapshot... Damn installer didn't work at all. I had to do everything manually with the live usb and chroot | 14:14 |
| juliank | And it's unlikely that's every going to happen. | 14:14 |
| thewillo | which I only kept doing because I thought it would be good to know how | 14:14 |
| thewillo | juliank, why is it unlikely? | 14:16 |
| juliank | Because recompiling an entire distribution is not usually done. It'd have to be fixed in microcode or worked around in the kernel or something | 14:17 |
| thewillo | doesn't every updated package involve compiling the updated version? | 14:19 |
| juliank | Sure | 14:19 |
| juliank | But do you want to update every package, there are like 20000 of them | 14:20 |
| * thewillo shrugs | 14:21 | |
| juliank | thewillo: Isn't AMD working on microcode fixes or something? | 14:22 |
| juliank | I don't completely keep track of the situation | 14:22 |
| thewillo | they did fix it | 14:22 |
| thewillo | they distributed the fix on the 20th | 14:23 |
| thewillo | but it's not patched in my bios | 14:23 |
| juliank | Ah good | 14:23 |
| thewillo | the fix went out, but it's not available in my uefi firmware yet | 14:23 |
| thewillo | but they've been updating it almost weekly | 14:23 |
| thewillo | lots of stability fixes and better support for higher ram clocks | 14:24 |
| juliank | That's good to hear, let's hope things are stable when I'll have money and time to get some Ryzen (2?) :) | 14:24 |
| thewillo | but the SMP segfaults were still happening with the firmware from 5 days ago | 14:24 |
| thewillo | juliank, want my e-mail in PM, when time comes you can e-mail me and ask how it's going, since my project involves a lot of toolchains and a ton of source and I use linux | 14:25 |
| thewillo | ? | 14:25 |
| juliank | Nah, I think it might take a long time | 14:26 |
| thewillo | oh | 14:26 |
| thewillo | ok | 14:26 |
| juliank | thewillo: Let's put it like this: When I'm ready to buy, it will probably be the second generation already :) | 14:27 |
| thewillo | ahh | 14:27 |
| thewillo | I wonder if the microcode patch is in the 17.10 repo's version of amd64-microcode | 14:35 |
| juliank | thewillo: No. Apparently Ryzen microcode can't even be updated at runtime | 14:44 |
| juliank | Because it contains memory and sata controller firmware needed for early boot or something | 14:45 |
| thewillo | oh | 14:57 |
| thewillo | well, to be fair, patching microcode from software is something that you don't want software to be capable of | 14:58 |
| thewillo | unless you enable it for a specific need | 14:59 |
| thewillo | like it should be disabled by default but an option in firmware | 14:59 |
| juliank | It seems that apt 1.5 breaks the Launchpad recipes with "E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed." | 15:49 |
| cjwatson | juliank: Hm, do we possibly need to make launchpad-buildd do "deb-src [trusted=yes] file://..." there? I'm surprised that that's new though. | 16:18 |
| cjwatson | juliank: Did apt use to consider file: as automatically trusted or something? | 16:18 |
| juliank | cjwatson: Hmm, not sure what happened precisely, just saw it in the build logs for the ~deity/sid PPA | 16:19 |
| juliank | cjwatson: There was a warning before, and now it's an error | 16:20 |
| cjwatson | juliank: Could you file a launchpad-buildd bug and I'll get it fixed? | 16:20 |
| juliank | cjwatson: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826 | 16:21 |
| ubottu | Launchpad bug 1701826 in launchpad-buildd "APT 1.5: E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. " [Undecided,New] | 16:21 |
| cjwatson | ta | 16:22 |
| === girish946 is now known as Guest40664 | ||
| cjwatson | MP sent | 16:24 |
| juliank | cjwatson: Any idea about 'Failed to fetch https://launchpad.net/ubuntu/+archive/primary/+files/coreutils-dbgsym_8.26-3ubuntu3_amd64.ddeb Error reading from server. Remote end closed connection [IP: 91.189.89.222 443]' - it could be that I did something wrong in the new https handling between apt 1.5~alpha3 and 1.5~alpha4, but I don't really see what. So, could it be a Launchpad <-> autopkgtest issue? | 16:27 |
| juliank | Ah no, ~alpha3 did not run the new https method on autopkgtest, so it really could be anything | 16:29 |
| juliank | But just downloading from launchpad works for me | 16:30 |
| juliank | I wish I had more details | 16:32 |
| juliank | I guess someone with access needs to run the autopkgtest and then enter that environment and check manually with apt-helper and debugging options | 16:38 |
| cjwatson | juliank: Have you tried just retriggering the test? It might have been transient | 16:41 |
| juliank | cjwatson: Yeah, but I guess I'll try it again | 16:48 |
| juliank | Queues are empty now anyway | 16:48 |
| juliank | From what I understand either gnutls_record_recv() or gnutls_record_send() must have returned 0 at some point | 16:50 |
| cjwatson | It's not just getting confused by the 303 response or something? | 16:51 |
| juliank | cjwatson: Well it works locally with apt-helper | 16:52 |
| juliank | I guess I'd want to rerun the tests with debug::acquire::https=1 and debug::pkgacquire::worker=1 | 16:53 |
| juliank | set in the apt config | 16:53 |
| juliank | That'd be really noisy but tell us more | 16:53 |
| juliank | Hmm, the new tls support is much slower for this file than the curl one | 16:55 |
| juliank | 3.4 vs 5.4 seconds | 16:56 |
| juliank | Mostly handshake/header waiting AFAICT | 16:56 |
| juliank | Hmm, no it waits 2 seconds between receiving the 303 and returning it to apt. odd. | 16:59 |
| juliank | Ah, because it tries to read a body and that takes some time. | 17:06 |
| juliank | So maybe that's where we're failing - trying to read a body | 17:08 |
| juliank | I'm not sure why we try that anyway - Content-Length is 0 | 17:08 |
| juliank | cjwatson: APT assumed that if Content-Length is available that there is content. Launchpad responded Content-Length 0, I think that might be causing it (not sure why it works for me, though) | 17:10 |
| cjwatson | LP is per spec | 17:12 |
| cjwatson | "[stuff about HEAD, then:] All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it MAY be of zero length." | 17:13 |
| cjwatson | RFC 2616 4.3 | 17:13 |
| juliank | Yeah | 17:15 |
| juliank | Minor nitpick: Current RFC is 7230, though | 17:15 |
| juliank | ;) | 17:15 |
| juliank | cjwatson: It's incredible what kind of issues I detect in that old code now that I added TLS support to it... | 17:16 |
| juliank | With that fixed, http redirects should be faster now. | 17:17 |
| juliank | I'll upload that to artful and see what it thinks | 17:17 |
| juliank | cjwatson: I think most servers just close the connection after a redirect, and that's why nobody noticed that | 17:18 |
| juliank | (or well, send Connection: close) | 17:18 |
| juliank | cjwatson: Seems treating Content-Length: 0 correctly as no content solved the issue : | 19:06 |
| juliank | :) | 19:06 |
| juliank | That bug must have been lurking there like forever | 19:07 |
| cjwatson | juliank: Nice find | 19:08 |
| cjwatson | juliank: Some RFCs I remember by number and it's tough to update my mental model; 2616 has been in my head for 17 years :P | 19:08 |
| juliank | cjwatson: Next week the launchpad build chroots for artful can drop apt-transport-https then :) | 19:15 |
| juliank | Going to be epic :) | 19:15 |
| cjwatson | I will leave that to infinity ... | 19:25 |
| juliank | He's going to be very happy :) | 19:32 |
| === BrAsS_mOnKeY is now known as g2 | ||
| juliank | cjwatson: the fix working also means that apt just migrated, so I fear things are broken everywhere now | 21:17 |
| juliank | I wonder if we could somehow make interactions with launchpad an autopkgtest. Like a fake package that launches builds on launchpad and waits for them | 21:19 |
| cjwatson | juliank: Recipes on artful fortunately mostly aren't too critical | 23:57 |
| juliank | cjwatson: Yeah, I feared other sutff might be broken too | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!