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