xwayland security updates, to mesa- or core-updates or ?

xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

Hi Guix,

In light of (more) CVEs in xwayland, see
<https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
with already pending security updates, see
<https://issues.guix.gnu.org/67136>, I would like to prioritize
getting that fixed in master. The tricky thing is that, according to
67136, the xwayland update needs newer xorgproto, which corresponds to
many rebuilds. (The related CVEs in xorg-server have been pushed
already as effectively minor version bumps.)

Where is the most efficient branch for this, that could take these
rebuilds to be merged to master soon (whatever soon is for a scope of
something like 22k affected packages)?

I was thinking to put that update and mesa, since it had a new stable
release after the current one never got updates, on mesa-updates and
merge once builds are done assuming no issues. Again, the potential
sore spot is xorgproto I would say. I could see about any other
pending/urgent related changes, but I'm not aware of any off the top
of my head and want to let this move quickly. I also don't want to
jump the queue sending other branches to rebuild everything again.

I'll test things locally in the meantime, but please chime in. If I
don't hear anything too urgent I'll update the mesa-updates branch to
start builds at least. I've also cc'ed some names I think will be
knowledgeable about some current branches.

And thanks to Kaelyn (also cc'ed) for the pending xwayland patches!

Thanks!
John

Re: xwayland security updates, to mesa- or core-updates or ?

[Kaelyn]

On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias <john.kehayias@protonmail.com> wrote:

> 
> Hi Guix,
> 
> In light of (more) CVEs in xwayland, see
> https://lists.x.org/archives/xorg-announce/2023-December/003435.html,
> 
> with already pending security updates, see
> https://issues.guix.gnu.org/67136, I would like to prioritize
> 
> getting that fixed in master. The tricky thing is that, according to
> 67136, the xwayland update needs newer xorgproto, which corresponds to
> many rebuilds. (The related CVEs in xorg-server have been pushed
> already as effectively minor version bumps.)
> 
> Where is the most efficient branch for this, that could take these
> rebuilds to be merged to master soon (whatever soon is for a scope of
> something like 22k affected packages)?
> 
> I was thinking to put that update and mesa, since it had a new stable
> release after the current one never got updates, on mesa-updates and
> merge once builds are done assuming no issues. Again, the potential
> sore spot is xorgproto I would say. I could see about any other
> pending/urgent related changes, but I'm not aware of any off the top
> of my head and want to let this move quickly. I also don't want to
> jump the queue sending other branches to rebuild everything again.

This doesn't seem unreasonable to me, for picking up both the new mesa release and the latest xwayland security fixes.

> I'll test things locally in the meantime, but please chime in. If I
> don't hear anything too urgent I'll update the mesa-updates branch to
> start builds at least. I've also cc'ed some names I think will be
> knowledgeable about some current branches.
> 
> And thanks to Kaelyn (also cc'ed) for the pending xwayland patches!

You're welcome! I've been working on updating my patch set to xwayland 23.2.3, but it's been taking a while to build the update because most of the dependency stack on core-updates apparently needed rebuilding locally (presumably from a lack of recent substitutes unrelated to the xorgproto-triggered rebuilds, but that's based on my computer churning away at the build for the past day or so, and not having checked guix weather yet--I even ran into an issue with coreutils-minimal failing a test when /tmp was a btrfs partition, that I got past by mounting a tmpfs on /tmp).

Cheers,
Kaelyn


> 
> Thanks!
> John

Re: xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

Hi Kaelyn and everyone,

On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:

> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
> <john.kehayias@protonmail.com> wrote:
>
>>
>> Hi Guix,
>>
>> In light of (more) CVEs in xwayland, see
>> <https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
>>
>> with already pending security updates, see
>> <https://issues.guix.gnu.org/67136>, I would like to prioritize
>>
>> getting that fixed in master. The tricky thing is that, according to
>> 67136, the xwayland update needs newer xorgproto, which corresponds to
>> many rebuilds. (The related CVEs in xorg-server have been pushed
>> already as effectively minor version bumps.)
>>
>> Where is the most efficient branch for this, that could take these
>> rebuilds to be merged to master soon (whatever soon is for a scope of
>> something like 22k affected packages)?
>>
>> I was thinking to put that update and mesa, since it had a new stable
>> release after the current one never got updates, on mesa-updates and
>> merge once builds are done assuming no issues. Again, the potential
>> sore spot is xorgproto I would say. I could see about any other
>> pending/urgent related changes, but I'm not aware of any off the top
>> of my head and want to let this move quickly. I also don't want to
>> jump the queue sending other branches to rebuild everything again.
>
> This doesn't seem unreasonable to me, for picking up both the new mesa
> release and the latest xwayland security fixes.
>
>> I'll test things locally in the meantime, but please chime in. If I
>> don't hear anything too urgent I'll update the mesa-updates branch to
>> start builds at least. I've also cc'ed some names I think will be
>> knowledgeable about some current branches.
>>

I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
mesa-updates after merging in master. The farm is building away.

The request for merging is at <https://issues.guix.gnu.org/67875> with
some details. In short, running into some issues with builds "failing"
because they just die or "missing derivation" errors. I'm restarting
what I see that seems higher impact, but is there anyway to restart
all the failed builds or ones with missing dependencies?

Also, gtk for i686-linux is failing a test and I don't know why. With
a newer version incoming from the gnome team I would just go for
disabling that test if I knew how...

>> And thanks to Kaelyn (also cc'ed) for the pending xwayland patches!
>
> You're welcome! I've been working on updating my patch set to xwayland
> 23.2.3, but it's been taking a while to build the update because most
> of the dependency stack on core-updates apparently needed rebuilding
> locally (presumably from a lack of recent substitutes unrelated to the
> xorgproto-triggered rebuilds, but that's based on my computer churning
> away at the build for the past day or so, and not having checked guix
> weather yet--I even ran into an issue with coreutils-minimal failing a
> test when /tmp was a btrfs partition, that I got past by mounting a
> tmpfs on /tmp).
>
> Cheers,
> Kaelyn
>

Thanks! I saw you had posted the latest version and that's what I
included. On x86_64-linux at least everything has built fine for
those, but the larger world remains to be seen.

Would still like confirmation from other branches about what they want
to do, but we have some time while things build. And builds get
restarted.

Thanks!
John

Re: xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

Hi all,

On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote:

> Hi Kaelyn and everyone,
>
> On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
>
>> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
>> <john.kehayias@protonmail.com> wrote:
>>
>>>
>>> Hi Guix,
>>>
>>> In light of (more) CVEs in xwayland, see
>>> <https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
>>>
>>> with already pending security updates, see
>>> <https://issues.guix.gnu.org/67136>, I would like to prioritize
>>>
>>> getting that fixed in master. The tricky thing is that, according to
>>> 67136, the xwayland update needs newer xorgproto, which corresponds to
>>> many rebuilds. (The related CVEs in xorg-server have been pushed
>>> already as effectively minor version bumps.)
>>>

I also updated curl as it was going to be rebuilt and had a new
version out (with some security fixes). I hadn't grafted it on master
but we could do that if the mesa-updates branch isn't merged to master
first.

[snip]

>
> I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> mesa-updates after merging in master. The farm is building away.
>

I also had to skip a failing test (unknown reasons) of gtk with these
updates.

Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
Vulkan). I remember someone asking about it on #guix recently as well,
and we should have it enabled in general, to support devices which may
not be able to use OpenGL without it.

> The request for merging is at <https://issues.guix.gnu.org/67875> with
> some details. In short, running into some issues with builds "failing"
> because they just die or "missing derivation" errors. I'm restarting
> what I see that seems higher impact, but is there anyway to restart
> all the failed builds or ones with missing dependencies?
>

This is still true though I've tried to manually restart lots of
builds on x86_64 and i686, which has removed many of the failures. Any
idea what is happening to cause this more recently?

[snip]

> Thanks! I saw you had posted the latest version and that's what I
> included. On x86_64-linux at least everything has built fine for
> those, but the larger world remains to be seen.
>
> Would still like confirmation from other branches about what they want
> to do, but we have some time while things build. And builds get
> restarted.
>

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.

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

Re: xwayland security updates, to mesa- or core-updates or ?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3891 bytes --]

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:
> 
> > Hi Kaelyn and everyone,
> >
> > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
> >
> >> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
> >> <john.kehayias@protonmail.com> wrote:
> >>
> >>>
> >>> Hi Guix,
> >>>
> >>> In light of (more) CVEs in xwayland, see
> >>> <https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
> >>>
> >>> with already pending security updates, see
> >>> <https://issues.guix.gnu.org/67136>, I would like to prioritize
> >>>
> >>> getting that fixed in master. The tricky thing is that, according to
> >>> 67136, the xwayland update needs newer xorgproto, which corresponds to
> >>> many rebuilds. (The related CVEs in xorg-server have been pushed
> >>> already as effectively minor version bumps.)
> >>>
> 
> I also updated curl as it was going to be rebuilt and had a new
> version out (with some security fixes). I hadn't grafted it on master
> but we could do that if the mesa-updates branch isn't merged to master
> first.
> 
> [snip]
> 
> >
> > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> > mesa-updates after merging in master. The farm is building away.
> >
> 
> I also had to skip a failing test (unknown reasons) of gtk with these
> updates.
> 
> Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
> Vulkan). I remember someone asking about it on #guix recently as well,
> and we should have it enabled in general, to support devices which may
> not be able to use OpenGL without it.
> 
> > The request for merging is at <https://issues.guix.gnu.org/67875> with
> > some details. In short, running into some issues with builds "failing"
> > because they just die or "missing derivation" errors. I'm restarting
> > what I see that seems higher impact, but is there anyway to restart
> > all the failed builds or ones with missing dependencies?
> >
> 
> This is still true though I've tried to manually restart lots of
> builds on x86_64 and i686, which has removed many of the failures. Any
> idea what is happening to cause this more recently?
> 
> [snip]
> 
> > Thanks! I saw you had posted the latest version and that's what I
> > included. On x86_64-linux at least everything has built fine for
> > those, but the larger world remains to be seen.
> >
> > Would still like confirmation from other branches about what they want
> > to do, but we have some time while things build. And builds get
> > restarted.
> >
> 
> 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
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: xwayland security updates, to mesa- or core-updates or ?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 5333 bytes --]

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:
> > 
> > > Hi Kaelyn and everyone,
> > >
> > > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
> > >
> > >> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
> > >> <john.kehayias@protonmail.com> wrote:
> > >>
> > >>>
> > >>> Hi Guix,
> > >>>
> > >>> In light of (more) CVEs in xwayland, see
> > >>> <https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
> > >>>
> > >>> with already pending security updates, see
> > >>> <https://issues.guix.gnu.org/67136>, I would like to prioritize
> > >>>
> > >>> getting that fixed in master. The tricky thing is that, according to
> > >>> 67136, the xwayland update needs newer xorgproto, which corresponds to
> > >>> many rebuilds. (The related CVEs in xorg-server have been pushed
> > >>> already as effectively minor version bumps.)
> > >>>
> > 
> > I also updated curl as it was going to be rebuilt and had a new
> > version out (with some security fixes). I hadn't grafted it on master
> > but we could do that if the mesa-updates branch isn't merged to master
> > first.
> > 
> > [snip]
> > 
> > >
> > > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> > > mesa-updates after merging in master. The farm is building away.
> > >
> > 
> > I also had to skip a failing test (unknown reasons) of gtk with these
> > updates.
> > 
> > Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
> > Vulkan). I remember someone asking about it on #guix recently as well,
> > and we should have it enabled in general, to support devices which may
> > not be able to use OpenGL without it.
> > 
> > > The request for merging is at <https://issues.guix.gnu.org/67875> with
> > > some details. In short, running into some issues with builds "failing"
> > > because they just die or "missing derivation" errors. I'm restarting
> > > what I see that seems higher impact, but is there anyway to restart
> > > all the failed builds or ones with missing dependencies?
> > >
> > 
> > This is still true though I've tried to manually restart lots of
> > builds on x86_64 and i686, which has removed many of the failures. Any
> > idea what is happening to cause this more recently?
> > 
> > [snip]
> > 
> > > Thanks! I saw you had posted the latest version and that's what I
> > > included. On x86_64-linux at least everything has built fine for
> > > those, but the larger world remains to be seen.
> > >
> > > Would still like confirmation from other branches about what they want
> > > to do, but we have some time while things build. And builds get
> > > restarted.
> > >
> > 
> > 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

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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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

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

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 4159 bytes --]

On Thu, Jan 04, 2024 at 05:13:46AM +0000, John Kehayias wrote:
> 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 massaging the aarch64 builds to try to build out to rust,
currently I'm still around cmake.  Last time we relied on bayfront for
substitutes, which I'd be okay with again, as long as we can tell that
it's doing alright.

> > 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?

Looks like I got it working on whichever systems I tested it on and I
today saw it build correctly on Berlin.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

Hi all,

Forgive the top post and please see below/previous messages for
previous updates.

TL;DR: I plan to merge mesa-updates into master today-ish (well,
tomorrow for me at this point).

I've been checking in with Efraim who's been very helpful at trying to
nudge along substitute coverage on non-x86_64 platforms. Unfortunately
looks like we have plateaued a bit on, e.g., aarch64. We haven't been
getting stats from QA for this round, and Berlin looks good for what
it covers (x86) but other architectures are down from what we can
tell.

I don't think there are any fundamental failures at this point but
just lots of "missing derivation" errors (I've restarted so many
manually for x86_64/i686) and builds not completing without restarts.
Or unknown reasons. Given the few weeks I've given this and the risk
of just perpetually doing rebuilds to keep catching up (with then more
updates to push) I think it would be best to merge to master. Mesa and
other bits will continue to move forward as well, so I think it is
time so we can be somewhat timely.

I'd rather not without complete substitute coverage, but given recent
build farm difficulties, and the tools we do have for users (pinning,
weather checks, etc.) I think it is best to call this branch so we can
move on. Gnome has some updates that will need (re)building as well as
trying to move forward with core-updates now too.

This is a case where having some better sense of our users and actual
substitute needs/wants would be helpful (yes, Guix survey!) as well as
recognizing our current infrastructure limits. Here's another vote for
prioritizing infrastructure and making sure QA lives and expands.

Feel free to object to this merge timing, though with the relative
silence in each previous message I take it I can make a call here.

Thanks everyone and hope 2024 is off to a good start! Enjoy the new
mesa with curl and xwayland security updates (no new grafts!).

John

On Thu, Jan 04, 2024 at 12:09 AM, John Kehayias wrote:

> 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

Re: xwayland security updates, to mesa- or core-updates or ?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

On Mon, Jan 08, 2024 at 05:43:40AM +0000, John Kehayias wrote:
> Hi all,
> 
> Forgive the top post and please see below/previous messages for
> previous updates.
> 
> TL;DR: I plan to merge mesa-updates into master today-ish (well,
> tomorrow for me at this point).
> 
> I've been checking in with Efraim who's been very helpful at trying to
> nudge along substitute coverage on non-x86_64 platforms. Unfortunately
> looks like we have plateaued a bit on, e.g., aarch64. We haven't been
> getting stats from QA for this round, and Berlin looks good for what
> it covers (x86) but other architectures are down from what we can
> tell.
> 
> I don't think there are any fundamental failures at this point but
> just lots of "missing derivation" errors (I've restarted so many
> manually for x86_64/i686) and builds not completing without restarts.
> Or unknown reasons. Given the few weeks I've given this and the risk
> of just perpetually doing rebuilds to keep catching up (with then more
> updates to push) I think it would be best to merge to master. Mesa and
> other bits will continue to move forward as well, so I think it is
> time so we can be somewhat timely.
> 
> I'd rather not without complete substitute coverage, but given recent
> build farm difficulties, and the tools we do have for users (pinning,
> weather checks, etc.) I think it is best to call this branch so we can
> move on. Gnome has some updates that will need (re)building as well as
> trying to move forward with core-updates now too.
> 
> This is a case where having some better sense of our users and actual
> substitute needs/wants would be helpful (yes, Guix survey!) as well as
> recognizing our current infrastructure limits. Here's another vote for
> prioritizing infrastructure and making sure QA lives and expands.
> 
> Feel free to object to this merge timing, though with the relative
> silence in each previous message I take it I can make a call here.
> 
> Thanks everyone and hope 2024 is off to a good start! Enjoy the new
> mesa with curl and xwayland security updates (no new grafts!).

To record here more or less what I said on IRC, we're currently at
rust-1.56 or 1.57 on the mesa-teams branch, and we're looking at
probably more than a week to build out to rust itself, and then the
packages which depend on it.  Currently, on master, Berlin already is
running behind on building rust, and it wasn't until after the previous
mesa-updates merge that it caught up with building rust.


-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: xwayland security updates, to mesa- or core-updates or ?

[John Kehayias]

On Mon, Jan 08, 2024 at 10:32 AM, Efraim Flashner wrote:

> On Mon, Jan 08, 2024 at 05:43:40AM +0000, John Kehayias wrote:
>> Hi all,
>>
>> Forgive the top post and please see below/previous messages for
>> previous updates.
>>
>> TL;DR: I plan to merge mesa-updates into master today-ish (well,
>> tomorrow for me at this point).
>>
>> I've been checking in with Efraim who's been very helpful at trying to
>> nudge along substitute coverage on non-x86_64 platforms. Unfortunately
>> looks like we have plateaued a bit on, e.g., aarch64. We haven't been
>> getting stats from QA for this round, and Berlin looks good for what
>> it covers (x86) but other architectures are down from what we can
>> tell.
>>
>> I don't think there are any fundamental failures at this point but
>> just lots of "missing derivation" errors (I've restarted so many
>> manually for x86_64/i686) and builds not completing without restarts.
>> Or unknown reasons. Given the few weeks I've given this and the risk
>> of just perpetually doing rebuilds to keep catching up (with then more
>> updates to push) I think it would be best to merge to master. Mesa and
>> other bits will continue to move forward as well, so I think it is
>> time so we can be somewhat timely.
>>
>> I'd rather not without complete substitute coverage, but given recent
>> build farm difficulties, and the tools we do have for users (pinning,
>> weather checks, etc.) I think it is best to call this branch so we can
>> move on. Gnome has some updates that will need (re)building as well as
>> trying to move forward with core-updates now too.
>>
>> This is a case where having some better sense of our users and actual
>> substitute needs/wants would be helpful (yes, Guix survey!) as well as
>> recognizing our current infrastructure limits. Here's another vote for
>> prioritizing infrastructure and making sure QA lives and expands.
>>
>> Feel free to object to this merge timing, though with the relative
>> silence in each previous message I take it I can make a call here.
>>
>> Thanks everyone and hope 2024 is off to a good start! Enjoy the new
>> mesa with curl and xwayland security updates (no new grafts!).
>
> To record here more or less what I said on IRC, we're currently at
> rust-1.56 or 1.57 on the mesa-teams branch, and we're looking at
> probably more than a week to build out to rust itself, and then the
> packages which depend on it.  Currently, on master, Berlin already is
> running behind on building rust, and it wasn't until after the previous
> mesa-updates merge that it caught up with building rust.

Thanks again for your help and watchful eye on this Efraim!

Merged in 7a7c8920aeddaf9ab8d68c572780bc34b404711b.

Thanks everyone, apologies for anyone that needs to wait for
substitutes. Feel free to CC me directly on any breakages due to this
merge but hopefully I didn't miss anything major.

John