[bug#73288] Request for merging "mesa-updates" branch

[John Kehayias via Guix-patches via <guix-patches@gnu.org>]

On Tue, Nov 05, 2024 at 12:50 AM, Z572 wrote:

> John Kehayias via Guix-patches via <guix-patches@gnu.org> writes:
>
>> Hi all,
>>
>> On Sun, Nov 03, 2024 at 03:02 PM, Efraim Flashner wrote:
>>
>>> On Sun, Nov 03, 2024 at 06:04:08PM +0800, Z572 wrote:
>>>> John Kehayias via Guix-patches via <guix-patches@gnu.org> writes:
>>>>
>>>> > Hello Guix,
>>>> >
>>>> > The mesa-updates branch I think is just almost ready for
>>>> > merging. Besides some other fixes and updates, the main series is
>>>> > tracked at <https://issues.guix.gnu.org/73071>. There is an update to
>>>> > add NVK support to mesa for x86_64-linux which I need to review and
>>>> > push (and rebase to get more fixes from master).
>>>> >
>>>> > Coverage looks good for x86_64 and i686 on QA, with powerpc64le as
>>>> > well on Berlin. I worry that aarch64 and others may have stalled out
>>>> > on Bordeaux. Perhaps Efraim can chime in there.
>>>> >
>>>> > With an update for NVK for x86_64, that will take maybe a day to catch
>>>> > up again in builds but tends to be pretty quick. I'm not aware of
>>>> > other blockers.
>>>> >
>>>> > Thanks!
>>>> > John
>>>>
>>>> maybe is time to merge?
>>>>
>>>> see <https://qa.guix.gnu.org/branch/mesa-updates>
>>>> ci       have x86_64-linux 96.3%, i686-linux 87.7%, powerpc64le-linux 85.5%
>>>> bordeaux have x86_64-linux 91.5%, i686-linux 77.8%, armhf-linux
>>>> 79.4%, aarch64-linux 89.0%.
>>>>
>>>> Is there anything else in the way?
>>>
>>> Comparing them against master and against each other:
>>> x86_64: comparable on ci, slight regression on bordeaux
>>> i686:   comparable on ci, regression on bordeaux (91.8 -> 77.8)
>>> aarch64: comparable on ci, regression on bordeaux (97.0 -> 89.0)
>>> armhf:  slight regression on bordeaux
>>> ppc64le: comparable on ci and bordeaux
>>> riscv64: regression on bordeaux (62.0 -> 28.2)
>>>
>>> I feel like bordeaux will catch-up fairly quickly post merge.  However,
>>> we do now have the regression page for bordeaux of master vs
>>> mesa-updates:
>>> <https://qa.guix.gnu.org/branch/mesa-updates/package-changes?x86_64-linux-change=blocked&x86_64-linux-change=still-blocked&x86_64-linux-change=unknown-to-blocked&x86_64-linux-change=new-blocked>
>>>
>>> However, after spot-checking a few of them to see if there are
>>> substitutes (including gnome and openjdk) it looks like it probably just
>>> needs to be sent through again.
>>>
>>> It looks okay to me
>>
>> I had been keeping a close eye some weeks ago during the initial batch
>> of patches I pushed and I also think everything looks good. I was just
>> waiting for non-x86 substitute coverage which seems to finally be
>> there as noted above after waiting for other branches and recent
>> Berlin issues. I have been running my system on this branch for a
>> couple weeks as well.
>>
>> However, the other day on IRC there was a comment about (if I
>> remember) Sway hardware acceleration needing newer libva...? I think
>> it was Josselin (cc'ed); apologies if I misremembered as I was
>> traveling.
>>
>> Is that a blocker? If so, it would be good to have that update (plus
>> likely yet another mesa version bump) so substitutes can be
>> rebuilt. But I also don't want to hold up any other branches longer
>> than necessary as this has already been waiting for some weeks.
>
> i think we can merge this branch first, and setup a new branch to fix/update
> libva and mesa, people can use inferior to get have hardware
> acceleration package on new branch. WDYT?
>

Yes, sounds good. I did a rebase and deleted/pushed to mesa-updates. I'll check in about 12 hours and will do the merge assuming it still looks good and no sudden issues.

Ah, did find the log I missed about Sway, seems it will be for the new version <https://logs.guix.gnu.org/guix/2024-10-31.log#120948>. So, I will do the merge and then we can do a new branch for libva, sway, etc. (and keep up with mesa). Probably will just put it in the queue once build slots open up as I would like to (every time) keep it small and quick to keep it from becoming harder to manage.

Thanks all!
John