[00:17] Same failures at rakudo-moar-2021.05-14-g16eaa0693, trying 0de28ae72 [00:46] Same failures at rakudo-moar-2021.05-7-g0de28ae72 [01:10] Same failures at rakudo-moar-2021.05-5-gce943fca1. This isn't looking promising. [01:12] Alright, I'm going to go back to one I know I've built successfully before, rakudo-moar-2021.05-1-g1962e6744 -- if it fails there this time, it's most likely not Rakudo. [01:32] Nope, failed there too. I'm provisionally pointing back at cro again. [07:29] *** xinming_ joined [07:32] *** xinming left [09:07] Are you compiling successive rakudos just to test cro? No wonder your messages were so far apart :D [09:09] Ah, looks like it fails in CI too: https://github.com/croservices/cro/runs/2874431824 [09:10] I'd not noticed that [09:10] But..it started failing after a docs change [09:14] everything since the last version bump is a doc change! [09:28] Yes! [09:28] I think it's going to be a dep to blame. japhb++ for ruling out Rakudo as that dep. [18:11] *** xinming_ is now known as xinming [18:19] Altreus: Yeah, I have a script that pulls the repos, makes local disk clones into a new tree based on rakudo rev, then builds everything from MoarVM on up. It's the best method I've found for ruling out all the breakage every time someone makes a change to a submodule or force pushes or otherwise messes with the repo. It's kept me (slightly more) sane for a few years now. [18:21] It even breaks up the module installs into phases, so I can see what layer of the dependency stack is likely failing. However, cro is one I do at the very end, because I'm getting that one directly from github rather than zef. And therein lies the problem -- I haven't updated my zef install list for a while to account for changes in cro dependencies. [23:25] *** m6502 joined