[00:08] <kyrofa> cjwatson, my builds are still behaving weird. These two appear done but are frozen: https://launchpad.net/~kyrofa/+snap/nextcloud-test/+build/986978 and https://launchpad.net/~kyrofa/+snap/nextcloud-test/+build/987065 . This one appears frozen in the middle: https://launchpad.net/~kyrofa/+snap/nextcloud-test/+build/987064 . I still haven't gotten a successful build from moving to core18
[00:08] <kyrofa> Not sure what's going on
[00:09] <kyrofa> The builds took forever to start, too, so maybe it's a load issue?
[00:09] <cjwatson> Yeah I noticed, something a bit odd
[00:09] <cjwatson> We just restarted buildd-manager, evidently not as fixed as I'd hoped :(
[00:09] <cjwatson> Giving it another ten minutes or so to catch up
[00:10] <cjwatson> But then I'll try switching back to the double-manager mode and see if that helps
[00:11] <cjwatson> Such a frustrating situation
[00:39] <cjwatson> kyrofa: Clearing again I think
[00:40] <cjwatson> I don't know about https://launchpad.net/~kyrofa/+snap/nextcloud-test/+build/987064, that one doesn't seem to be related to buildd-manager
[00:40] <cjwatson> But the others have made progress
[03:27] <FourDollars> SpecialK|Canon: Could you help https://bugs.launchpad.net/launchpad/+bug/1882169?
[03:28] <FourDollars> cjwatson: Could you help https://bugs.launchpad.net/launchpad/+bug/1882169?
[04:49] <wgrant> FourDollars: Huh, it seems very strange that something like that would mutate the payload, and making LP match its payload mutilation doesn't sound like the right solution.
[05:16] <FourDollars> wgrant: Yes, I agree. That is a wishlist. However making the delivery bodies compact to save some network usage doesn't sound bad, right?
[05:18] <wgrant> FourDollars: It's a tradeoff between negligibly reducing a trivial amount of network traffic and significantly improved readability, so I'm not sure it's a clear win.
[05:19] <FourDollars> wgrant: I see.
[05:20] <wgrant> It's worth discussion, but I don't see a massive win in minifying it, and reliably minifying it in the same way as smee.io seems doubtful.
[05:28] <FourDollars> wgrant: I was trying to recover the delivery body from smee.io to the one from Launchpad and then to check HMAC-SHA1 but I found there is no trivial way to do it. What I found is the way to compact it.
[05:32] <FourDollars> wgrant: If you know the way to recover the compact json body to the json body that Launchpad webhook sent. Please let me know.
[05:34] <wgrant> >>> orig == json.dumps(json.loads(minified))
[05:34] <wgrant> True
[05:34] <wgrant> python2.7 roundtrips it properly
[05:34] <wgrant> However, I really wouldn't rely on that
[05:34] <wgrant> Launchpad's webhook signature mechanism doesn't support intermediaries that mutilate the payload, and I'm not sure we'd want to support that.
[05:35] <wgrant> python3.8 does too
[05:35] <wgrant> But I'd suggest finding a service that behaves a bit less strangely.
[05:40] <FourDollars> wgrant: smee.io is the most convenient free service I found so far and there's also a convenient  https://pypi.org/project/pysmee/ I can use.
[05:50] <FourDollars> wgrant: I confirmed that `orig == json.dumps(json.loads(minified))` can workaround the problem. Thx for the information.
[09:59] <LocutusOfBorg> cjwatson, next time we blame kernel and firefox for slow uploading, we should also add nvidia-cuda-toolkit to the list :P https://launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/10.1.243-5ubuntu2/+build/19411443
[09:59] <LocutusOfBorg> damn, few GB of "sources", even dpkg-sourcing it takes minutes
[10:00] <cjwatson> LocutusOfBorg: When I "blame" it it's because I've specifically seen it in logs.
[10:01] <LocutusOfBorg> sure, I was joking :)
[17:38] <kyrofa> cjwatson, builders seem way snappier today, I'll let you know if I see any weirdness. Ended up cancelling that one hung build