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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

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

I meant that I believed there was enough capacity to process the 4K
rebuilds (per architecture) in a way that wouldn't negatively affect
users too much.

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

Hm, sorry about that.  Cuirass seems to have mostly caught up already
(was 64% before, 62% now for the master specification).

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

Yes, the branch would be in the Guix repository, but I meant regarding
the Cuirass specifications affecting which branches it builds; sorry for
being unclear.

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

For this case I think so yes, since it's a patch-level update that
should be safe.

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

One of the things that has been bothered me has been the lack of
documentation/tooling to recreate TLS user certificates for Cuirass so
that I can configure branches via its web interface again, or retry
failed builds.  I'm currently working on documenting (in Cuirass's
manual) a script Ricardo's made for that task.

But building lots of packages will still require a lot of processing
power, probably more so when it happens in focused team branches
compared to grouped together as it used to be the case for
e.g. core-updates.

-- 
Thanks,
Maxim