Hi,

I have an additional question/concern that's come up, but to address 
your comments first:

On 9/15/24 22:59, John Kehayias wrote:

>> Since last, I have managed to find a better solution to the issue with
>> substituting rust dependency sources.  Briefly on what I have so far: this
>> makes use of writing wrap files with just the "directory" property, having
>> meson fall back to using a local directory that sources are copied to.  Doing
>> this resulted in an odd behavior with the overlay directories (i.e. important
>> extra files in subprojects/packagefiles) where they don't seem to be
>> automatically copied as expected when falling back to local files; however, a
>> simple copy resolves it, although I thought it would still be good to note and
>> add a comment about.
>>
>> I initially made the wrap-file-writing a build utility procedure
>> 'patch-wrap-file' (which can be seen my personal config [1]) as it seemed like
>> it could be useful for other meson packages, but for this patch I've inlined
>> it since I'm not confident in its applicability across different projects.
>> I'd be happy to hear thoughts about it if it might be useful, though.
>>
>> [1]<https://github.com/aurtzy/guix-config/blob/5cf4c9e277f4ab3a8f1ef87ec5ac47a686da0ad2/my-guix/build/utils.scm#L27>
>>
> Very nice! Yes, more utilities to help with unbundling essentially
> will be helpful. I don't know if I ever wrote a wrap file or just
> patched the directory bit into the meson file directly. I would have
> to look this over, but a utility function (or via keyword argument in
> meson-build-system?) would be great.
Okay! I'll have a look at the keyword argument approach as well and see 
if I can make a proposal for changes and further comments sometime soon.
> As for the main patch: I've built locally and see nouveau as a vulkan
> driver on x86_64 but not i686. That's about all I can test though. The
> change to #:meson means other archs will rebuild too, but I don't know
> if they got far anyway (so we can cancel old derivations). Perhaps a
> new mesa point release will be out this week? Then I could bump the
> version, rebase, and rebuild with this patch. Thoughts?

I didn't consider this when writing the patch, but would it be a good 
idea to only use meson-1.5 for x86_64? We could avoid rebuilds that way.

Looks like a new mesa release is planned for the 18th [1].

> Other than that, I made a minor tweak to the changelog (remove first
> line, name the phase) locally, but have not done a rebase/push on
> mesa-updates. Let me give it a few days for other comments and if
> there are any other rebuilds to go with it.

Regarding my concern (unrelated to NVK): I've had issues with a nonfree 
application segfaulting which I narrowed down to a mesa commit from a 
few months ago [2] [3] and hit a dead end with (until today). It's only 
this single program which I had ever noticed the issue with so I pushed 
it aside, but it just occurred to me that this seems like a change that 
could affect other cases my daily driving has not covered.

Further investigation today has revealed that adding libglvnd as an 
input to mesa fixes this, although from what I can tell reading past 
discussions on adding it, it seems like a complicated issue [4]. 
Thoughts about this situation?

[1] https://docs.mesa3d.org/release-calendar.html#calendar

[2] https://gitlab.freedesktop.org/mesa/mesa/-/issues/11666

[3] 
https://gitlab.freedesktop.org/mesa/mesa/-/commit/50fc7cc290db49288b318c116c6fdc3daaf801e9

[4] https://issues.guix.gnu.org/49339#3

Cheers,

aurtzy