[bug#69637] [PATCH mesa-updates v2 0/5] gnu: mesa: Update to 24.0.3.

[John Kehayias]

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!

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

So, maybe we can take this approach:

1. Make the update just to 24.0.3 for mesa (does that require newer
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.

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