PR submitted: https://pagure.io/fedora-comps/pull-request/973

This is done for comps, now it just needs to be synced to Kinoite.

https://pagure.io/workstation-ostree-config/pull-request/516

pulling in krdp manually at the moment on Kinoite rawhide enables the KCM but we get an error that the system lacks h264 encode - does this require rpmfusion codecs to be pull in to actually function? Or is something else missing?

You need openh264 installed.

Hum, that's not going to be great experience on Kinoite then as there is no easy way to do that right now :/

I tried overriding the noopenh264 package and layering openh264. The KCM didn't detect the codec.

Replacing the mesa-va-drivers with the one from rpmfusion gets this running when openh264 has been added as well

rpm-ostree override remove mesa-va-drivers --install mesa-va-drivers-freeworld

Hum, that's not going to be great experience on Kinoite then as there is no easy way to do that right now :/

The issue is reproducible builds, right?

We can not include openh264 in Kinoite for legal reasons. It thus needs to be installed after the installation, potentially as an overlayed package, which has downsides.

Was the legal question around hardware encoding in mesa - which is why mesa-va-drivers-freeworld was split off?

Is there a reason Kinoite uses noopenh264 and not just the openh264 package that is in the fedora repo like previously suggested?

We could override pipewire to use the software encoder with - KPIPEWIRE_FORCE_ENCODER=libx264 as suggested in https://bugs.kde.org/show_bug.cgi?id=488858 (although I haven't yet tested if that actually works yet)

@siosm ,

We can not include openh264 in Kinoite for legal reasons. It thus needs to be installed after the installation, potentially as an overlayed package, which has downsides.

I'm wondering if the plan described for fedora-workstation issue "Automatically install the OpenH264 codecs" can cover Fedora Atomic users...

a simple plan to fix the issue: we package noopenh264 in Fedora, and modify the openh264 package distributed by Cisco to Obsoletes: noopenh264. Since the Cisco repo is enabled by default, that's really all we need to do.

The situation around openh264 is similar but not exactly the same as what happend with mesa.

See:
- https://www.openh264.org/faq.html
- https://docs.fedoraproject.org/en-US/quick-docs/openh264/

The short version is that we are not allowed to include this package in the base Fedora Kinoite image as it needs to be distributed by Cisco for the licensing clauses to apply. It must thus be installed either during the initial Anaconda installation or on first boot of the system for example.

Neal tried to make https://fedoraproject.org/wiki/Changes/AutoFirstBootServices (https://src.fedoraproject.org/rpms/fedora-autofirstboot) a while ago to improve the situation on package mode Fedora (non Atomic variants) but this does not work well with Atomic variants.

See:
- https://pagure.io/fedora-autofirstboot/issue/8
- https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YUHRDGEPHDCSEOTHCKPVMXEWU6KXWOIH/

One option to move forward is to create a systemd sysext with the content of those packages and fix the remaining sysext / (rpm-)ostree incompatibilities.

Another one is to teach Firefox and other applications to look at /usr/local/... and then manually download/update the openh264 RPM and unpack it there. This is a bit ugly and might create issues (incompatibles versions, etc).

Both versions are not ideal, but this is what we're stuck with.

I tried overriding the noopenh264 package and layering openh264. The KCM didn't detect the codec.

Just fyi, I started looking into this and it appears that kpipewire doesn't support openh264 so installing openh264 is insufficient for getting the banner to go away. There's already a bug report open for this https://bugs.kde.org/show_bug.cgi?id=476187 that was opened by Hector Martin. It's noted as confirmed but it doesn't look like there has been any progress on it.

@ngompa I'm not sure if there is anyone you can ping on the KDE side to get this resolved prior to F41? krdp otherwise will not be able to be enabled from the remote desktop settings kcm out of the box

Just an update that a merge request was started to resolve this issue:
https://invent.kde.org/plasma/kpipewire/-/merge_requests/152

I tried overriding the noopenh264 package and layering openh264. The KCM didn't detect the codec.

Just fyi, I started looking into this and it appears that kpipewire doesn't support openh264 so installing openh264 is insufficient for getting the banner to go away. There's already a bug report open for this https://bugs.kde.org/show_bug.cgi?id=476187 that was opened by Hector Martin. It's noted as confirmed but it doesn't look like there has been any progress on it.

@ngompa I'm not sure if there is anyone you can ping on the KDE side to get this resolved prior to F41? krdp otherwise will not be able to be enabled from the remote desktop settings kcm out of the box

This has been backported and shipped to current Fedora 40 KDE.

@siosm Another option is to have an openh264 subpackage that installs into a private subdirectory and installs an ldconfig config snippet to load it, similar to libavcodec-freeworld. Then it will cleanly layer on top of noopenh264.

We should avoid any solution that involves layering by default. I'm working on making systemd-sysext compatible with ostree based systems instead. That would let us auto-generate sysexts for the openh264 libraries.

So, there's bit of a weird state with this issue since it's technically completed (i.e. it's in comps and os-tree config) but the kinoite side is waiting on the work @siosm is handling in order for it to function OOTB (using openh264). It should function OOTB after the first update for the normal plasma spin.

Do we want to leave this issue open to track that change or proceed to close this and track that issue separately?

If this is completed for the KDE Spin then let's close it and we can track Kinoite specific issues independently.

Alright, closing as fixed