[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 04/09: gnu: mesa: Update to 23.0.3.
From: |
Maxim Cournoyer |
Subject: |
Re: 04/09: gnu: mesa: Update to 23.0.3. |
Date: |
Mon, 08 May 2023 11:01:21 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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
- Re: 04/09: gnu: mesa: Update to 23.0.3., Christopher Baines, 2023/05/07
- Re: 04/09: gnu: mesa: Update to 23.0.3., Maxim Cournoyer, 2023/05/08
- Re: 04/09: gnu: mesa: Update to 23.0.3., Christopher Baines, 2023/05/08
- Re: 04/09: gnu: mesa: Update to 23.0.3.,
Maxim Cournoyer <=
- Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3), Andreas Enge, 2023/05/08
- Re: Feature branches, Maxim Cournoyer, 2023/05/08
- Re: Feature branches, Andreas Enge, 2023/05/10
- Re: Feature branches, Maxim Cournoyer, 2023/05/10
- Re: Feature branches, Andreas Enge, 2023/05/10
- Re: Feature branches, Andreas Enge, 2023/05/10
- Re: Feature branches, Maxim Cournoyer, 2023/05/11
- Re: Feature branches, Felix Lechner, 2023/05/08
- Re: Feature branches, Andreas Enge, 2023/05/10
- Re: Feature branches, Christopher Baines, 2023/05/10