[00:08] 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] Not sure what's going on [00:09] The builds took forever to start, too, so maybe it's a load issue? [00:09] Yeah I noticed, something a bit odd [00:09] We just restarted buildd-manager, evidently not as fixed as I'd hoped :( [00:09] Giving it another ten minutes or so to catch up [00:10] But then I'll try switching back to the double-manager mode and see if that helps [00:11] Such a frustrating situation [00:39] kyrofa: Clearing again I think [00:40] 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] But the others have made progress [03:27] SpecialK|Canon: Could you help https://bugs.launchpad.net/launchpad/+bug/1882169? [03:27] Ubuntu bug 1882169 in Launchpad itself "Compact delivery bodies for webhook" [Undecided,New] [03:28] cjwatson: Could you help https://bugs.launchpad.net/launchpad/+bug/1882169? [03:28] Ubuntu bug 1882169 in Launchpad itself "Compact delivery bodies for webhook" [Undecided,New] [04:49] 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] 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] 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] wgrant: I see. [05:20] 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] 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] 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] >>> orig == json.dumps(json.loads(minified)) [05:34] True [05:34] python2.7 roundtrips it properly [05:34] However, I really wouldn't rely on that [05:34] 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] python3.8 does too [05:35] But I'd suggest finding a service that behaves a bit less strangely. [05:40] 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] wgrant: I confirmed that `orig == json.dumps(json.loads(minified))` can workaround the problem. Thx for the information. === diddledan0 is now known as diddledan [09:59] 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] damn, few GB of "sources", even dpkg-sourcing it takes minutes [10:00] LocutusOfBorg: When I "blame" it it's because I've specifically seen it in logs. [10:01] sure, I was joking :) === hggdh is now known as hggdh-msft [17:38] cjwatson, builders seem way snappier today, I'll let you know if I see any weirdness. Ended up cancelling that one hung build === hggdh-msft is now known as hggdh