Re: 04/09: gnu: mesa: Update to 23.0.3.

[Christopher Baines <mail@cbaines.net>]

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


Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> guix-commits@gnu.org writes:
>>
>>> apteryx pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 0be7838105806819f4586ec9130382a66a22880e
>>> Author: Kaelyn Takata <kaelyn.alexi@protonmail.com>
>>> AuthorDate: Thu May 4 20:12:46 2023 +0000
>>>
>>>     gnu: mesa: Update to 23.0.3.
>>>
>>>     * gnu/packages/gl.scm (mesa): Update to 23.0.3.
>>>     [source]: Remove obsolete patch and update HTTPS url.
>>>     [arguments]: Enable the crocus gallium driver.
>>>     * gnu/packages/patches/mesa-fix-sporadic-test-failures.patch: Delete file.
>>>     * gnu/local.mk (dist_patch_DATA): Remove it.
>>> ---
>>>  gnu/local.mk                                       |  1 -
>>>  gnu/packages/gl.scm                                | 14 ++++-------
>>>  .../patches/mesa-fix-sporadic-test-failures.patch  | 27 ----------------------
>>>  3 files changed, 5 insertions(+), 37 deletions(-)
>>
>> → guix refresh -l mesa
>> Building the following 1954 packages would ensure 4257 dependent
>> packages are rebuilt ...
>>
>>
>> I know there's been some discussion about changing processes regarding
>> changes like this that impact lots of packages, but as far as I'm aware,
>> the documented process hasn't changed yet. So should this have gone to
>> core-updates, and not been directly pushed to master?
>
> There isn't currently a core-updates branch, and I need to spend some
> time documenting the authorization process for how to create short lived
> Cuirass branches.  I think ideally we would have created a
> 'graphics-team' or similar branch (even the team has yet to be formed)
> and let it build.
>
> Seeing the build machines were idling in the European night, I figured I
> could get away with it for this time.

Some build machines may have been idle, but I'm not sure what you mean
by "get away with it"?

While the berlin bulid farm has managed to catch back up for
x86_64-linux and i686-linux within 24 hours, I think these changes
impact other systems as well.

Also, the bordeaux build farm has a lot fewer machines to do these
builds, so while the substitute availability had caught up (and
surpassed ci.guix.gnu.org for x86_64-linux) prior to these changes, it's
going to be several days at least I think before substitute availability
is looking good again.

I was watching the substitute availability recover after the
core-updates merge as I'd like to re-enable testing patches on the
qa-frontpage, but now that'll have to wait some more for all these new
builds to complete.

> But the situation will repeat; I'd like to push some xorg updates that
> fix a CVE; we'll nead a 'xorg-team' branch or similar.  Should we create
> these branches from the maintenance repository (permanent branches) ?

I don't really understand the question, surely the branches would be in
the guix Git repository?

Anyway, package replacements+grafts can be used for security issues so
that shouldn't need to be on a branch as it won't involve lots of
rebuilds.

When it comes to handling changes involving lots of rebuilds though, I
think that this has been and continues to be difficult, but in my mind
that's a reason to slow down and try and work on tooling and processes
to help.

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