GNU bug report logs - #69637
[PATCH mesa-updates 0/6] gnu: mesa: Update to 24.0.2.

Previous Next

Full log

Message #62 received at 69637 <at> debbugs.gnu.org (full text, mbox):

From: aurtzy <aurtzy <at> gmail.com>
To: John Kehayias <john.kehayias <at> protonmail.com>
Cc: 69637 <at> debbugs.gnu.org, efraim <at> flashner.co.il
Subject: Re: [bug#69637] [PATCH mesa-updates v2 0/5] gnu: mesa: Update to
 24.0.3.
Date: Tue, 26 Mar 2024 22:14:50 -0400

[Message part 1 (text/plain, inline)]

On 3/24/24 21:29, John Kehayias wrote:
> Hi aurtzy and Efraim,
>
> On Fri, Mar 22, 2024 at 03:24 AM, aurtzy wrote:
>
>> New patchset coming in.  Mesa has been updated to 24.0.3, and I've added TODO
>> comments for future work as suggested.
>>
> Thanks!
Happy to help!
>>> I would like to get the build farm cranking on the updates I have
>>> queued for mesa-updates (cairo, libdrm, mesa, vulkan). We could also
>>> do just the version update of mesa to start, or just NVK on x86_64,
>>> leaving future changes for the next round. I don't have a preference
>>> myself, other than wanting to get this branch moving with these
>>> updates.
>> NVK on 24.0.3 is also still considered experimental, so if that's a concern we
>> could save this work for 24.1 when it's planned to move out of this stage.
>>
> Right, I forgot about that. I also remember that it depends (or is
> helped by) some changes in recent kernels, 6.7 and/or 6.8 if I remember.

6.6 appears to be the minimum required according to mesa docs, if that 
changes anything: 
https://docs.mesa3d.org/drivers/nvk.html#kernel-requirements

> So, maybe we can take this approach:
>
> 1. Make the update just to 24.0.3 for mesa (does that require newer
> meson?)
The meson 1.3 requirement is only for NVK; mesa 24.0.3 without NVK can 
build with the current meson.
> 2. Add any rust packages as needed to master
>
> 3. Either add a mesa-next (to master?) or followup on mesa-updates after
> it gets merged to master with a mesa based on 24.1 (as soon as it is
> tagged) with NVK enabled. This will let us at least get mesa built and
> make for a headstart come 24.0.1.
>
> With 24.1 soon ("this quarter"?) and how long it can take us to build on
> non-x86 architectures, it would be nice to have that go quickly. Since
> I'll be including cairo, libdrm, and vulkan updates (at least) this
> round, I anticipate it taking a bit.
>
> Does that sound okay? It'll give some time to test things and clean
> up/find alternatives as Efraim suggested.
>
> I'm also not opposed to just enabling NVK now. In that case, we should
> have one commit to just update mesa and another to enable NVK.

Looks like 24.1 stable should be releasing May-June: 
https://docs.mesa3d.org/release-calendar.html

This approach sounds fine to me. I don't mind holding back the 
NVK-related changes for more testing and improvement.

>>> I also tried a couple of different options. The one that I most want
>>> involved using with-output-to-file to rewrite the wrap file and
>>> replacing all the fields. I borrowed the file-sha256 function from
>>> guix/build/cargo-utils.scm to get the source_hash.  In the end I wasn't
>>> able to get the gexp and un-gexp bits working to actually get the file
>>> written.
>>>
>>> When I kept a failed build I saw that the 'directory' field is the
>>> directory into which meson writes the meson.build file, which is why
>>> using a different version of the rust crate caused problems with
>>> src/lib.rs not existing.  I suppose we could start from your patch and
>>> then, after running substitute, extract the tarball into either a
>>> hardcoded path (determined after manually reading the sources) or we can
>>> extract the 'directory' field by reading the sources and then untar the
>>> source there.
>> Noted, thanks Efraim!  I'll keep looking into this.
>>
> Thanks both of you! I would like to start pushing patches and building
> everything in the next few days, especially as some have sat for a while
> and it will take time to build.
>
> John

Cheers,

aurtzy

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.