[bug#67875] xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

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