Meeting started at 2024-05-02 16:00:16 UTC

The Meeting name is 'fpc'

Hey.

!hi

!hi

James Antill (james)

!hi

!hi

Neal Gompa (ngompa) - he / him / his

Jonathan Steffan (jsteffan)

Gwyn Ciesla (limb) - she / her / hers

!hi

No Fedora Accounts users have the @ignatenkobrain:matrix.org Matrix Account defined

heh, will need to figure out how to get this fixed

!hi

Neil Hanlon (neil) - he / him / his

you have to add the linkage in accounts.fedoraproject.org

!hi

Igor Raits (ignatenkobrain)

We don't really have any new tickets this week ... unless anybody wants to argue we should sign off on https://pagure.io/packaging-committee/issue/1364

i have an item for the XR SIG but will wait until other business is attended to

uhhh no

same.

I do think it's in our remit, but I also don't think we should allow it

!hi

Fabio Valentini (decathorpe) - he / him / his

Agree this sounds more for FESCo

I think if it's us, we should say no. If it's FESCo, they should say no.

I mean, if they want us to vote, we can just vote no.

But this isn't about a guideline exception; it's about an exception to a rather fundamental Fedora policy.

Agreed. This way lie Winmodems.

Yeh, I feel like we probably aren't allowed to say yes ... but maybe it's fine to vote anyway because we'd all vote no.

Do you want to bring your thing up?

sure.

okay, so i apologize for not having a ticket ready with all this, but i wanted to get the process started to resolve some pending packaging things we have slated for the XR SIG

so this will be a brain dump

the new XR SIG https://fedoraproject.org/wiki/SIGs/XR is working to package up XR hardware enablement and runtime support for fedora

one of the largest outstanding questions is "where do vulkan layers go"

https://bugzilla.redhat.com/show_bug.cgi?id=2274947 is a perfect example of the situation

right now, upstreams are putting the vulkan layers in `/usr/lib[64]`

the justification for this has recently been documented in upstream monado https://gitlab.freedesktop.org/monado/monado/-/blob/main/doc/packaging-notes.md?ref_type=heads

a PR to move the layer, which is an unversioned soname that should not be linked against, to a subdir was rejected https://gitlab.freedesktop.org/monado/monado/-/merge_requests/2193

I would naively think that the graphics stack people would have something to say about it.

this will also affect wivrn (based on monado) https://github.com/Meumeu/WiVRn/issues/49

and i have been working with upstream on this for a bit now https://gitlab.freedesktop.org/monado/monado/-/issues/335

But generally, yeah, it sounds like some sort of provate library that's supposed to be dlopen'ed and not linked against, so sitting with the regular libraries seems bad.

Does RPM generate any dependencies for these things?

I don't have much knowledge but simply looking into the what vulkan stuff I have here… /usr/share/vulkan/… is where definition go and /usr/lib(64)? is where goes the actual library

so with the express written request from upstream to NOT move the library... i want to get to a point where fedora's stance is well documented with justification for the policy and then we can have an expanded discussion with upstream

we already have `mesa-vulkan-drivers` that puts some files there

so, that's a good point. vulkan doesn't explicitly define where things should go, but it does define the loader behaviour

to me this sounds like a bug in the OpenXR loader

but what do I know

however, there are unowned directories based on the review.. this is something we may want to actually fix.

https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md#vkconfig

this does have larger implications outside just XR focused software, yes

!hi

Michel Lind (salimma) - he / him / his

i've been researching and testing this for a while, and now need additional help deciding on what to do and getting everyone on the same path

Just read their reasoning ... and it looks like what Fabio said, and they know it. And maybe will fix it soon?

from a functionality perspective, both approaches work with recent vulkan loaders

but it's important to consider the operating environment of monado, it might not be possible to use an updated vulkan-load or openxr

Subdir works already with the latest loaders? I'd be heavily inclined to say it should do that then

in my current testing with https://bugzilla.redhat.com/show_bug.cgi?id=2274947 it works on fedora. there were odd things on opensuse, and i'm sure other environments too

i strongly prefer a non-downstream-only resolution here. this is based on the fact that it's not just the XR ecosystem that will be impacted. the mesa vulkan drivers is a good example of what i mean.

so my ask is 1) what should we do that covers all cases for vulkan layers? 2) updating any public policy to explicitly outline the policy and provide guidance 3) any additional support working with upstream(s) to get to the best possible outcome

the XR SIG *could* move forward just moving the layers and guarding against old loaders that wont do the right thing with Requires, but i'm not certain that is the best path forward

Have you spoken to the desktop people who own mesa vulkan drivers?

no. so far i've only been working with upstreams and within the XR SIG. since i'm making this change due to fedora policy, this was the next step to ask for clarification of the policy

we would for sure need to bring them in for any policy definition for the distro

Yeh, I guess I'd speak to upstream about adding a compile time option to install into a subdir now that the loader supports it ... and use that if they'll take it. Also speak to the current mesa owners, and if they are like "it is what it is" then maybe just give up.

yes, as an unversioned soname (i think is the correct answer here)

this is already possible. it's just explicitly documented to not.

Ahh, interesting

my ideal outcome is that we get to a policy that will be adopted ecosystem wide. i suspect other distros will follow what we are able to get defined and accepted. i'd really like all distros to use the same thing, and that means if we do all of this downstream-only we've not created a fissure ... but for what reason?

my ideal outcome is that we get to a policy that will be adopted ecosystem wide. i suspect other distros will follow what we are able to get defined and accepted. i'd really like all distros to use the same thing, and that means if we do all of this downstream-only we've created a fissure ... but for what reason?

i was hoping someone would say "oh.. if you put that in /usr/lib[64] *this is how the world will end* ;-) and we should put it in a subdir for reason XYZ"

so, if I understand correctly, those unversioned .so files are supposed to **only** be loaded via something like dlopen (i.e. they act like loadable plugins), but never linked by other binaries directly

that is correct

I guess the reason why plugin-like .so files like that were preferred to live in a subdirectory is that you *don't* want stuff to link them

(i.e. not put them into the linker's default search path)

they are marked as MODULEs ... (and forgive me i'm still learning all of this in depth) and that should prevent that from happening?

yeah, i think that's the technical reason to move them out of the default linker path

other than that, I don't know if there are other reasons

but it would certainly be "cleaner" to put loadable .so files like them into subdirectories.

i have not tested this is true yet. i just know with it moved to a subdir it's not in the default linker path

yeah, if there was no existing use of this code and we started from a "what should we do", it'd be in a subdir. at least that would be my preference

but i'm not yet well versed on the overall technical implications of that decision

see previous example of mesa vulkan drivers. there has to be a good reason they are not in a subdir....

additionally, as vulkan continues to gain momentum, i don't think this issue is going away

I wouldn't necessarily expect a good reason :) maybe it's just "mesa installs them there, so we leave them there" ...

vulkan will be very useful for AI/ML stuff as a backend, and i'm sure other things too

i'm okay with any outcome that is standardized and accepted in the ecosystem in general. it's just a good moment to step up and define it

yeah. starting a conversation with the mesa maintainers might be a good next step?

again, *both* solutions work from the perspective of the XR SIG

i'm not immediately finding it. does anyone know where the current policy is documented for this?

https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ only documents SONAME versioning. in the case we are discussing, it's generally accepted these are not to be versioned.

https://docs.fedoraproject.org/en-US/packaging-guidelines/C\_and\_C++/ only documents SONAME versioning. in the case we are discussing, it's generally accepted these are not to be versioned because they should not be linked against

Yeh, the guidelines arent written for your specific situation

Speak to others, and maybe poke upstream about changing their opinion now things work ... otherwise shrug and do it so it works is probably fine.

Yeh, the guidelines aren't written for your specific situation

okay, so if i'm interpreting things correctly these are our next steps: 1) document this discussion as a ticket for the FPC to document the policy (whatever that ends up being) 2) work with the workstation SIG to develop the policy that will work for all currently-know cases of vulkan layers (e.g. mesa-vulkan-layers monado-vulkan-layers) 3) submit the recommendation to the FPC for approval 4) work with upstream(s) on whatever the outcome (not excluding upstreams in the development of the recommendation, work with them to implement what is agreed upon)

Sounds right to me.

okay, so if i'm interpreting things correctly these are our next steps: 1. document this discussion as a ticket for the FPC to document the policy (whatever that ends up being) 2. work with the workstation SIG to develop the policy that will work for all currently-know cases of vulkan layers (e.g. mesa-vulkan-layers monado-vulkan-layers and the respective upstream(s)) 3. submit the recommendation to the FPC for approval 4. work with upstream(s) on whatever the outcome (not excluding upstreams in the development of the recommendation, work with them to implement what is agreed upon)

Sounds good ... and on that note, I'll close the meeting unless anyone has anything they really need to bring up right now.

Nope.