Hi Efraim and guix-devel On Mon, Dec 25, 2023 at 08:44 AM, Efraim Flashner wrote:
> On Fri, Dec 22, 2023 at 09:19:27AM +0200, Efraim Flashner wrote: >> On Thu, Dec 21, 2023 at 09:18:50PM +0000, John Kehayias wrote: >> > Hi all, >> > >> > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote: >> > [snip] >> > >> > I haven't seen QA process this branch, so I'm just going with what I >> > see on Berlin. From the branches overview it shows about 61% last I >> > saw, compared to 72% for master. Unfortunately, non x86 architectures >> > are usually better covered by Bordeaux, but I don't know where to get >> > a sense of that coverage. For what it is worth, Efraim has manually >> > built xorgproto and mesa at least on powerpc64le, riscv64, without >> > issues. >> >> I had berlin build for powerpc64le and that went without any problems. >> Locally I built for riscv64 and powerpc and those both built fine. I >> ran into an issue locally with curl on aarch64 and test 1477(?) which is >> weird since it's supposed to be skipped but I'm sending it through >> again. Haven't started armhf yet. >> >> > Coverage on x86_64 and i686 seems good from what I can tell. I also >> > don't think there are any other branches ready to merge, and would >> > like to give them time to rebuild once these changes hit. >> > >> > Any thoughts on when to merge? >> > >> > Thanks everyone! >> > John > Coming back to this point, seems Berlin is doing better with building but I don't see mesa-updates on QA so I'm not sure about non x86_64/i686-linux coverage. Anyone have any thoughts? I don't know that I've seen real new failures, as still lots of "missing derivation" or other transient issues that resolve on forcing a rebuild. I don't want to merge to master and have issues with substitute coverage, but do have to call it at some point or will end up keep scheduling/waiting for rebuilds to happen anyway. Thoughts? > I've been having trouble with curl on aarch64 again. Looking at this > snippet from the build log: > > test 1477...[Verify that error codes in headers and libcurl-errors.3 are in > sync] > > 1477: stdout FAILED: > --- log/1/check-expected 2023-12-22 10:53:51.658667071 +0000 > +++ log/1/check-generated 2023-12-22 10:53:51.658667071 +0000 > @@ -1 +0,0 @@ > -Result[LF] > > - abort tests > test 1475...[-f and 416 with Content-Range: */size] > --pd---e--- OK (1247 out of 1472, remaining: 00:45, took 5.310s, duration: > 04:11) > test 1474...[HTTP PUT with Expect: 100-continue and 417 response during > upload] > --pd---e--- OK (1246 out of 1472, remaining: 00:48, took 22.794s, duration: > 04:29) > Warning: test1474 result is ignored, but passed! > ... > TESTFAIL: These test cases failed: 1477 > > It looks like 1474 is passing locally and the ~1474 is telling the test > suite to ignore the result. If that's how ~<number> is interpreted then > I'd suggest that 1477 is failing hard enough that it's taking the test > suite with it, not merely ignoring the result. I'll continue poking it > but right now I'm starting to like the hurd plan of disabling the test > instead of merely ignoring the result. Thanks for looking at this Efraim. Looks like a good chunk of the curl rebuilds did get through, did it look okay on aarch64 and anywhere else you checked? John
