[00:51] bdmurray: 1701491 has a DpkgTerminalLog.txt that shows the openssl upgrade dying; again no actual error messages from dpkg :( === maclin1 is now known as maclin [12:25] Hmm, there seem to be issues installing udev on armhf, causing the autopkgtests postgresql-debversion/unknown and ubiquity/unknown to fail. [12:27] Or maybe the machine was shutting down while running the tests? [12:27] Main PID: 2311 (systemd-udevd) - Status: "Shutting down..." [12:34] Well, let's try again and see if it works this time [13:40] 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:43] 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:47] Maybe Launchpad is angry with apt because apt just closed the fd with an incomplete TLS closure ;) [14:01] 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:02] so did you upgrade compilers for the new builds? [14:08] thewillo: It's still 6.3, but newer SVN revision [14:08] (AFAICT) [14:09] 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] knowing what I do about computers I could see how overclocking the ram could possibly be a fix [14:09] but I don't know enough to say that for sure [14:10] i could just see how it might be something [14:10] but I also know that compiling everything with gcc7.1 fixes it [14:11] 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:12] I can assure you that nobody recompiled everything [14:13] I did... then my SSD failed [14:14] 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] And it's unlikely that's every going to happen. [14:14] which I only kept doing because I thought it would be good to know how [14:16] juliank, why is it unlikely? [14:17] 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:19] doesn't every updated package involve compiling the updated version? [14:19] Sure [14:20] But do you want to update every package, there are like 20000 of them [14:21] * thewillo shrugs [14:22] thewillo: Isn't AMD working on microcode fixes or something? [14:22] I don't completely keep track of the situation [14:22] they did fix it [14:23] they distributed the fix on the 20th [14:23] but it's not patched in my bios [14:23] Ah good [14:23] the fix went out, but it's not available in my uefi firmware yet [14:23] but they've been updating it almost weekly [14:24] lots of stability fixes and better support for higher ram clocks [14:24] 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] but the SMP segfaults were still happening with the firmware from 5 days ago [14:25] 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] ? [14:26] Nah, I think it might take a long time [14:26] oh [14:26] ok [14:27] thewillo: Let's put it like this: When I'm ready to buy, it will probably be the second generation already :) [14:27] ahh [14:35] I wonder if the microcode patch is in the 17.10 repo's version of amd64-microcode [14:44] thewillo: No. Apparently Ryzen microcode can't even be updated at runtime [14:45] Because it contains memory and sata controller firmware needed for early boot or something [14:57] oh [14:58] well, to be fair, patching microcode from software is something that you don't want software to be capable of [14:59] unless you enable it for a specific need [14:59] like it should be disabled by default but an option in firmware [15:49] It seems that apt 1.5 breaks the Launchpad recipes with "E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed." [16:18] 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] juliank: Did apt use to consider file: as automatically trusted or something? [16:19] cjwatson: Hmm, not sure what happened precisely, just saw it in the build logs for the ~deity/sid PPA [16:20] cjwatson: There was a warning before, and now it's an error [16:20] juliank: Could you file a launchpad-buildd bug and I'll get it fixed? [16:21] cjwatson: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826 [16:21] Launchpad bug 1701826 in launchpad-buildd "APT 1.5: E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. " [Undecided,New] [16:22] ta === girish946 is now known as Guest40664 [16:24] MP sent [16:27] 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:29] Ah no, ~alpha3 did not run the new https method on autopkgtest, so it really could be anything [16:30] But just downloading from launchpad works for me [16:32] I wish I had more details [16:38] 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:41] juliank: Have you tried just retriggering the test? It might have been transient [16:48] cjwatson: Yeah, but I guess I'll try it again [16:48] Queues are empty now anyway [16:50] From what I understand either gnutls_record_recv() or gnutls_record_send() must have returned 0 at some point [16:51] It's not just getting confused by the 303 response or something? [16:52] cjwatson: Well it works locally with apt-helper [16:53] I guess I'd want to rerun the tests with debug::acquire::https=1 and debug::pkgacquire::worker=1 [16:53] set in the apt config [16:53] That'd be really noisy but tell us more [16:55] Hmm, the new tls support is much slower for this file than the curl one [16:56] 3.4 vs 5.4 seconds [16:56] Mostly handshake/header waiting AFAICT [16:59] Hmm, no it waits 2 seconds between receiving the 303 and returning it to apt. odd. [17:06] Ah, because it tries to read a body and that takes some time. [17:08] So maybe that's where we're failing - trying to read a body [17:08] I'm not sure why we try that anyway - Content-Length is 0 [17:10] 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:12] LP is per spec [17:13] "[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] RFC 2616 4.3 [17:15] Yeah [17:15] Minor nitpick: Current RFC is 7230, though [17:15] ;) [17:16] cjwatson: It's incredible what kind of issues I detect in that old code now that I added TLS support to it... [17:17] With that fixed, http redirects should be faster now. [17:17] I'll upload that to artful and see what it thinks [17:18] cjwatson: I think most servers just close the connection after a redirect, and that's why nobody noticed that [17:18] (or well, send Connection: close) [19:06] cjwatson: Seems treating Content-Length: 0 correctly as no content solved the issue : [19:06] :) [19:07] That bug must have been lurking there like forever [19:08] juliank: Nice find [19:08] 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:15] cjwatson: Next week the launchpad build chroots for artful can drop apt-transport-https then :) [19:15] Going to be epic :) [19:25] I will leave that to infinity ... [19:32] He's going to be very happy :) === BrAsS_mOnKeY is now known as g2 [21:17] cjwatson: the fix working also means that apt just migrated, so I fear things are broken everywhere now [21:19] 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 [23:57] juliank: Recipes on artful fortunately mostly aren't too critical [23:58] cjwatson: Yeah, I feared other sutff might be broken too