[00:51] <sarnold> bdmurray: 1701491 has a DpkgTerminalLog.txt that shows the openssl upgrade dying; again no actual error messages from dpkg :(
[12:25] <juliank> Hmm, there seem to be issues installing udev on armhf, causing the autopkgtests postgresql-debversion/unknown and ubiquity/unknown to fail.
[12:27] <juliank> Or maybe the machine was shutting down while running the tests?
[12:27] <juliank>  Main PID: 2311 (systemd-udevd) -  Status: "Shutting down..."
[12:34] <juliank> Well, let's try again and see if it works this time
[13:40] <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:43] <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:47] <juliank> Maybe Launchpad is angry with apt because apt just closed the fd with an incomplete TLS closure ;)
[14:01] <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:02] <thewillo> so did you upgrade compilers for the new builds?
[14:08] <juliank> thewillo: It's still 6.3, but newer SVN revision
[14:08] <juliank> (AFAICT)
[14:09] <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:10] <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:11] <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:12] <juliank> I can assure you that nobody recompiled everything
[14:13] <thewillo> I did... then my SSD failed
[14:14] <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:16] <thewillo> juliank, why is it unlikely?
[14:17] <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:19] <thewillo> doesn't every updated package involve compiling the updated version?
[14:19] <juliank> Sure
[14:20] <juliank> But do you want to update every package, there are like 20000 of them
[14:21]  * thewillo shrugs
[14:22] <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:23] <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:24] <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:25] <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:26] <juliank> Nah, I think it might take a long time
[14:26] <thewillo> oh
[14:26] <thewillo> ok
[14:27] <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:35] <thewillo> I wonder if the microcode patch is in the 17.10 repo's version of amd64-microcode
[14:44] <juliank> thewillo: No. Apparently Ryzen microcode can't even be updated at runtime
[14:45] <juliank> Because it contains memory and sata controller firmware needed for early boot or something
[14:57] <thewillo> oh
[14:58] <thewillo> well, to be fair, patching microcode from software is something that you don't want software to be capable of
[14:59] <thewillo> unless you enable it for a specific need
[14:59] <thewillo> like it should be disabled by default but an option in firmware
[15:49] <juliank> 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] <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:19] <juliank> cjwatson: Hmm, not sure what happened precisely, just saw it in the build logs for the ~deity/sid PPA
[16:20] <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:21] <juliank> cjwatson: https://bugs.launchpad.net/launchpad-buildd/+bug/1701826
[16:22] <cjwatson> ta
[16:24] <cjwatson> MP sent
[16:27] <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:29] <juliank> Ah no, ~alpha3 did not run the new https method on autopkgtest, so it really could be anything
[16:30] <juliank> But just downloading from launchpad works for me
[16:32] <juliank> I wish I had more details
[16:38] <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:41] <cjwatson> juliank: Have you tried just retriggering the test?  It might have been transient
[16:48] <juliank> cjwatson: Yeah, but I guess I'll try it again
[16:48] <juliank> Queues are empty now anyway
[16:50] <juliank> From what I understand either gnutls_record_recv() or gnutls_record_send() must have returned 0 at some point
[16:51] <cjwatson> It's not just getting confused by the 303 response or something?
[16:52] <juliank> cjwatson: Well it works locally with apt-helper
[16:53] <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:55] <juliank> Hmm, the new tls support is much slower for this file than the curl one
[16:56] <juliank> 3.4 vs 5.4 seconds
[16:56] <juliank> Mostly handshake/header waiting AFAICT
[16:59] <juliank> Hmm, no it waits 2 seconds between receiving the 303 and returning it to apt. odd.
[17:06] <juliank> Ah, because it tries to read a body and that takes some time.
[17:08] <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:10] <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:12] <cjwatson> LP is per spec
[17:13] <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:15] <juliank> Yeah
[17:15] <juliank> Minor nitpick: Current RFC is 7230, though
[17:15] <juliank> ;)
[17:16] <juliank> cjwatson: It's incredible what kind of issues I detect in that old code now that I added TLS support to it...
[17:17] <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:18] <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)
[19:06] <juliank> cjwatson: Seems treating Content-Length: 0 correctly as no content solved the issue :
[19:06] <juliank> :)
[19:07] <juliank> That bug must have been lurking there like forever
[19:08] <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:15] <juliank> cjwatson: Next week the launchpad build chroots for artful can drop apt-transport-https then :)
[19:15] <juliank> Going to be epic :)
[19:25] <cjwatson> I will leave that to infinity ...
[19:32] <juliank> He's going to be very happy :)
[21:17] <juliank> cjwatson: the fix working also means that apt just migrated, so I fear things are broken everywhere now
[21:19] <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
[23:57] <cjwatson> juliank: Recipes on artful fortunately mostly aren't too critical
[23:58] <juliank> cjwatson: Yeah, I feared other sutff might be broken too