2024-05-02 16:00:16 <@james:fedora.im> !startmeeting fpc

2024-05-02 16:00:19 <@meetbot:fedora.im> Meeting started at 2024-05-02 16:00:16 UTC
2024-05-02 16:00:20 <@meetbot:fedora.im> The Meeting name is 'fpc'
2024-05-02 16:00:22 <@james:fedora.im> !topic Roll Call

2024-05-02 16:00:48 <@tibbs:fedora.im> Hey.
2024-05-02 16:01:00 <@james:fedora.im> !hi

2024-05-02 16:01:00 <@conan_kudo:matrix.org> !hi
2024-05-02 16:01:06 <@zodbot:fedora.im> James Antill (james)
2024-05-02 16:01:08 <@jsteffan:fedora.im> !hi
2024-05-02 16:01:09 <@limb:fedora.im> !hi
2024-05-02 16:01:10 <@zodbot:fedora.im> Neal Gompa (ngompa) - he / him / his
2024-05-02 16:01:13 <@zodbot:fedora.im> Jonathan Steffan (jsteffan)
2024-05-02 16:01:13 <@zodbot:fedora.im> Gwyn Ciesla (limb) - she / her / hers
2024-05-02 16:01:57 <@ignatenkobrain:matrix.org> !hi
2024-05-02 16:02:05 <@zodbot:fedora.im> No Fedora Accounts users have the @ignatenkobrain:matrix.org Matrix Account defined
2024-05-02 16:02:17 <@ignatenkobrain:matrix.org> heh, will need to figure out how to get this fixed
2024-05-02 16:02:20 <@nhanlon:beeper.com> !hi
2024-05-02 16:02:25 <@zodbot:fedora.im> Neil Hanlon (neil) - he / him / his
2024-05-02 16:02:40 <@nhanlon:beeper.com> you have to add the linkage in accounts.fedoraproject.org
2024-05-02 16:03:23 <@ignatenkobrain:matrix.org> !hi
2024-05-02 16:03:30 <@zodbot:fedora.im> Igor Raits (ignatenkobrain)
2024-05-02 16:05:47 <@james:fedora.im> !topic Open Floor
2024-05-02 16:06:18 <@james:fedora.im> 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
2024-05-02 16:06:33 <@jsteffan:fedora.im> i have an item for the XR SIG but will wait until other business is attended to
2024-05-02 16:07:47 <@conan_kudo:matrix.org> uhhh no
2024-05-02 16:08:08 <@limb:fedora.im> same.
2024-05-02 16:08:53 <@conan_kudo:matrix.org> I do think it's in our remit, but I also don't think we should allow it
2024-05-02 16:09:09 <@decathorpe:fedora.im> !hi
2024-05-02 16:09:15 <@zodbot:fedora.im> Fabio Valentini (decathorpe) - he / him / his
2024-05-02 16:09:24 <@ignatenkobrain:matrix.org> Agree this sounds more for FESCo
2024-05-02 16:10:00 <@limb:fedora.im> I think if it's us, we should say no. If it's FESCo, they should say no.
2024-05-02 16:10:01 <@tibbs:fedora.im> I mean, if they want us to vote, we can just vote no.
2024-05-02 16:10:42 <@tibbs:fedora.im> But this isn't about a guideline exception; it's about an exception to a rather fundamental Fedora policy.
2024-05-02 16:11:32 <@limb:fedora.im> Agreed. This way lie Winmodems.
2024-05-02 16:12:02 <@james:fedora.im> 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.
2024-05-02 16:13:11 <@james:fedora.im> Do you want to bring your thing up?
2024-05-02 16:13:22 <@jsteffan:fedora.im> sure. 
2024-05-02 16:13:50 <@jsteffan:fedora.im> 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
2024-05-02 16:13:55 <@jsteffan:fedora.im> so this will be a brain dump
2024-05-02 16:14:22 <@jsteffan:fedora.im> the new XR SIG https://fedoraproject.org/wiki/SIGs/XR is working to package up XR hardware enablement and runtime support for fedora
2024-05-02 16:14:37 <@jsteffan:fedora.im> one of the largest outstanding questions is "where do vulkan layers go"
2024-05-02 16:14:49 <@jsteffan:fedora.im> https://bugzilla.redhat.com/show_bug.cgi?id=2274947 is a perfect example of the situation
2024-05-02 16:15:12 <@jsteffan:fedora.im> right now, upstreams are putting the vulkan layers in `/usr/lib[64]` 
2024-05-02 16:15:29 <@jsteffan:fedora.im> 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
2024-05-02 16:16:00 <@jsteffan:fedora.im> 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
2024-05-02 16:16:17 <@tibbs:fedora.im> I would naively think that the graphics stack people would have something to say about it.
2024-05-02 16:16:20 <@jsteffan:fedora.im> this will also affect wivrn (based on monado) https://github.com/Meumeu/WiVRn/issues/49
2024-05-02 16:16:43 <@jsteffan:fedora.im> and i have been working with upstream on this for a bit now https://gitlab.freedesktop.org/monado/monado/-/issues/335
2024-05-02 16:17:06 <@tibbs:fedora.im> 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.
2024-05-02 16:17:16 <@tibbs:fedora.im> Does RPM generate any dependencies for these things?
2024-05-02 16:17:27 <@ignatenkobrain:matrix.org> 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
2024-05-02 16:17:28 <@jsteffan:fedora.im> 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
2024-05-02 16:17:50 <@ignatenkobrain:matrix.org> we already have `mesa-vulkan-drivers` that puts some files there
2024-05-02 16:18:13 <@jsteffan:fedora.im> so, that's a good point. vulkan doesn't explicitly define where things should go, but it does define the loader behaviour
2024-05-02 16:18:18 <@decathorpe:fedora.im> to me this sounds like a bug in the OpenXR loader
2024-05-02 16:18:23 <@decathorpe:fedora.im> but what do I know
2024-05-02 16:18:37 <@ignatenkobrain:matrix.org> however, there are unowned directories based on the review.. this is something we may want to actually fix.
2024-05-02 16:19:02 <@jsteffan:fedora.im> https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderInterfaceArchitecture.md#vkconfig
2024-05-02 16:19:37 <@jsteffan:fedora.im> this does have larger implications outside just XR focused software, yes
2024-05-02 16:19:42 <@salimma:fedora.im> !hi
2024-05-02 16:19:46 <@zodbot:fedora.im> Michel Lind (salimma) - he / him / his
2024-05-02 16:20:21 <@jsteffan:fedora.im> 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
2024-05-02 16:20:34 <@james:fedora.im> Just read their reasoning ... and it looks like what Fabio said, and they know it. And maybe will fix it soon?
2024-05-02 16:20:50 <@jsteffan:fedora.im> from a functionality perspective, both approaches work with recent vulkan loaders
2024-05-02 16:21:26 <@jsteffan:fedora.im> but it's important to consider the operating environment of monado, it might not be possible to use an updated vulkan-load or openxr
2024-05-02 16:21:39 <@james:fedora.im> Subdir works already with the latest loaders? I'd be heavily inclined to say it should do that then
2024-05-02 16:22:18 <@jsteffan:fedora.im> 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
2024-05-02 16:23:44 <@jsteffan:fedora.im> 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.
2024-05-02 16:25:44 <@jsteffan:fedora.im> 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
2024-05-02 16:26:34 <@jsteffan:fedora.im> 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
2024-05-02 16:29:24 <@james:fedora.im> Have you spoken to the desktop people who own mesa vulkan drivers?
2024-05-02 16:30:19 <@jsteffan:fedora.im> 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
2024-05-02 16:30:47 <@jsteffan:fedora.im> we would for sure need to bring them in for any policy definition for the distro
2024-05-02 16:33:32 <@james:fedora.im> 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.
2024-05-02 16:33:35 <@jsteffan:fedora.im> yes, as an unversioned soname (i think is the correct answer here)
2024-05-02 16:34:51 <@jsteffan:fedora.im> this is already possible. it's just explicitly documented to not.
2024-05-02 16:36:27 <@james:fedora.im> Ahh, interesting
2024-05-02 16:36:41 <@jsteffan:fedora.im> 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?
2024-05-02 16:37:03 <@jsteffan:fedora.im> 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?
2024-05-02 16:41:22 <@jsteffan:fedora.im> 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"
2024-05-02 16:42:31 <@decathorpe:fedora.im> 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
2024-05-02 16:42:44 <@jsteffan:fedora.im> that is correct
2024-05-02 16:43:11 <@decathorpe:fedora.im> 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 
2024-05-02 16:43:22 <@decathorpe:fedora.im> (i.e. not put them into the linker's default search path)
2024-05-02 16:43:56 <@jsteffan:fedora.im> they are marked as MODULEs ... (and forgive me i'm still learning all of this in depth) and that should prevent that from happening?
2024-05-02 16:44:13 <@jsteffan:fedora.im> yeah, i think that's the technical reason to move them out of the default linker path
2024-05-02 16:44:50 <@decathorpe:fedora.im> other than that, I don't know if there are other reasons
2024-05-02 16:45:06 <@decathorpe:fedora.im> but it would certainly be "cleaner" to put loadable .so files like them into subdirectories.
2024-05-02 16:45:07 <@jsteffan:fedora.im> 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
2024-05-02 16:46:00 <@jsteffan:fedora.im> 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
2024-05-02 16:46:23 <@jsteffan:fedora.im> but i'm not yet well versed on the overall technical implications of that decision
2024-05-02 16:46:44 <@jsteffan:fedora.im> see previous example of mesa vulkan drivers. there has to be a good reason they are not in a subdir....
2024-05-02 16:47:09 <@jsteffan:fedora.im> additionally, as vulkan continues to gain momentum, i don't think this issue is going away
2024-05-02 16:47:27 <@decathorpe:fedora.im> I wouldn't necessarily expect a good reason :) maybe it's just "mesa installs them there, so we leave them there" ...
2024-05-02 16:47:34 <@jsteffan:fedora.im> vulkan will be very useful for AI/ML stuff as a backend, and i'm sure other things too
2024-05-02 16:48:16 <@jsteffan:fedora.im> 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
2024-05-02 16:48:27 <@decathorpe:fedora.im> yeah. starting a conversation with the mesa maintainers might be a good next step?
2024-05-02 16:48:38 <@jsteffan:fedora.im> again, *both* solutions work from the perspective of the XR SIG
2024-05-02 16:50:59 <@jsteffan:fedora.im> i'm not immediately finding it. does anyone know where the current policy is documented for this?
2024-05-02 16:51:46 <@jsteffan:fedora.im> 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.
2024-05-02 16:52:09 <@jsteffan:fedora.im> 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
2024-05-02 16:55:15 <@james:fedora.im> Yeh, the guidelines arent written for your specific situation
2024-05-02 16:56:08 <@james:fedora.im> 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.
2024-05-02 16:56:21 <@james:fedora.im> Yeh, the guidelines aren't written for your specific situation
2024-05-02 17:00:20 <@jsteffan:fedora.im> 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)
2024-05-02 17:01:04 <@limb:fedora.im> Sounds right to me.
2024-05-02 17:02:02 <@jsteffan:fedora.im> 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)
2024-05-02 17:04:29 <@james:fedora.im> Sounds good ... and on that note, I'll close the meeting unless anyone has anything they really need to bring up right now.
2024-05-02 17:05:05 <@limb:fedora.im> Nope.
2024-05-02 17:05:48 <@james:fedora.im> !endmeeting