5900
Comment:
|
10345
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
## Please edit system and help pages ONLY in the master wiki! ## For more information, please see MoinMoin:MoinDev/Translation. ##master-page:Unknown-Page ##master-date:Unknown-Date |
|
Line 2: | Line 6: |
#format wiki #language en == Fedora 39 == === VLC Moved to Fedora === * Status: WONTFIX * Bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6816 With vlc been moved to fedora on f38+ and epel9, the build will lacks support for x264/x265/faad2 (mostly encoders) and VAAPI (as built with current ffmpeg instead of compat-ffmpeg4). Please not that this move was done without any coordination with our project and as such is totally unfriendly. === Chromium broken ABI fedora's FFmpeg === * Status: FIXED * Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2240127 * Upstream https://crbug.com/1306560 With Fedora's ffmpeg built with a non-upstream and ABI breaking patch, chromium in f39 was crashing. Workaround was to use firefox, brave or even google-chrome. An RPM Fusion update fixed the behaviour by including a non-upstream patch. === VLC without libplacebo-6 === * Status: WONTFIX * Bug: N/A While VLC still has the VAAPI support using compat-ffmpeg-4 whereas ffmpeg-6 is the default (that would prevent having VAAPI support in vlc), the support for libplacebo-6 won't be made available in the 3.0.x branch upstream. So VLC in Fedora 39 and later is built with libplacebo disabled. If really needed, it could be possible to have libplacebo-5 in Fedora, but none has volunteered for this yet. == Fedora 38 == === Chromium-freeworld discontinued === * Status: Fixed * Bug: N/A With the Fedora chromium package now using codecs from the system ffmpeg available at runtime, RPM Fusion counterpart package is now discontinued. Please use the Fedora chromium package. {{{ sudo dnf swap chromium-freeworld chromium }}} === Fedora mesa-va-drivers vs mesa-freeworld === * Status: In-progress * Bug: https://github.com/rpmfusion/mesa-freeworld/pull/1 With Fedora packaging enforcing mesa-va-drivers on upgrades, the user installed mesa-va-drivers-freeworld might produce a file clash. If you experience that, add the recommended "-x mesa-va-drivers" hook in your command, such as: {{{ sudo dnf update -x mesa-va-drivers }}} === NVIDIA legacy 390xx/340xx === * Status: Best-effort * Bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6655 The 340xx and 390xx legacy branches are not maintained anymore by NVIDIA and are provided as best effort basis. More likely that things will break with one or another kernel update, or other incompatible component. If that break occurs, you will have the pieces. One way to mitigate is to use the kernel-longterm-6.1 copr repository as advertised in the [[Howto/NVIDIA]] == Fedora 37 == === mesa-freeworld needs === * Status: Fixed * Bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426 With the removal of potentially patented codec removal for mesa hardware acceleration in Fedora side, there is a needed to provide a "complementary package" This is mentioned in the [[Howto/Multimedia]] section. === FFmpeg-free Complement === * Status: Fixed (to some extend) * Bug: https://github.com/rpmfusion/ffmpeg/pull/3 With the introduction of FFmpeg in Fedora, we had an initial solution to conflict with this lame version. But this isn't ideal as most users using graphical interface won't be able to use full featured version. As with Fedora 37, we are building a complement package (libavcodec-freeworld) that can be installed along the ffmpeg-free libraries. /!\ Note: It is still recommended to switch to the full featured ffmpeg version from RPM Fusion to avoid weird interaction issue: {{{ sudo dnf swap ffmpeg-free ffmpeg --allowerasing }}} |
|
Line 6: | Line 76: |
=== System-upgrade and kmod issue === | === System-upgrade and kmod(-nvidia) issue === |
Line 9: | Line 79: |
With dnf system-upgrade with installed kmod (so far often reproduced with nvidia), the upgraded system doesn't show the available kernel module (with modinfo nvidia) despite the kmod package been present for the updated kernel. The issue isn't reproducible so far with dnf update --releasever=36 and only saw with dnf system-upgrade. | |
Line 11: | Line 80: |
This can easily be fixed by using depmod -ae and rebooting the system. | With dnf system-upgrade with installed kmod (so far often reproduced with nvidia), the upgraded system doesn't show the available kernel module (with modinfo nvidia) despite the kmod package been present for the updated kernel. The issue isn't reproducible so far with dnf update --releasever=36 and only saw with dnf system-upgrade. This can easily be fixed by using "sudo depmod -ae" and rebooting the system. === NVIDIA driver and simpledrm conflicts === * Status: Fixed with fedora kernel 5.17.10-300.fc36 and akmod-nvidia-510.68.02-2.fc36 * Bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6303 Since the fedora 36 feature related to [[https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers|simpledrm]] , there were an early conflict with simpledrm and the nvidia driver early initialisation routine. Since the fedora kernel is now preventing to enable simpledrm if nvidia is detected, the patches provided in our RPM Fusion package have been dropped with the newer packages. |
Line 16: | Line 94: |
With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduced an un-backed (by most RPM Fusion packager involved) package with uncertain feature enablement, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process. | With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduce an un-backed (by most RPM Fusion packagers involved) package with uncertain features enabled, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process. |
Line 18: | Line 98: |
* Fedora Workaround: dnf swap ffmpeg-free ffmpeg --allowerasing * Silverblue/Kinoite/Ostree workaround: TBD |
* Fedora Workaround: sudo dnf swap ffmpeg-free ffmpeg --allowerasing * Silverblue/Kinoite/Ostree workaround: Not relevant as ffmpeg is not installed by default there. |
Line 23: | Line 109: |
* Status: Unfixed | * Status: Fixed |
Line 26: | Line 112: |
Fedora 39
VLC Moved to Fedora
- Status: WONTFIX
With vlc been moved to fedora on f38+ and epel9, the build will lacks support for x264/x265/faad2 (mostly encoders) and VAAPI (as built with current ffmpeg instead of compat-ffmpeg4). Please not that this move was done without any coordination with our project and as such is totally unfriendly.
Chromium broken ABI fedora's FFmpeg
- Status: FIXED
Upstream https://crbug.com/1306560
With Fedora's ffmpeg built with a non-upstream and ABI breaking patch, chromium in f39 was crashing. Workaround was to use firefox, brave or even google-chrome. An RPM Fusion update fixed the behaviour by including a non-upstream patch.
VLC without libplacebo-6
- Status: WONTFIX
- Bug: N/A
While VLC still has the VAAPI support using compat-ffmpeg-4 whereas ffmpeg-6 is the default (that would prevent having VAAPI support in vlc), the support for libplacebo-6 won't be made available in the 3.0.x branch upstream. So VLC in Fedora 39 and later is built with libplacebo disabled. If really needed, it could be possible to have libplacebo-5 in Fedora, but none has volunteered for this yet.
Fedora 38
Chromium-freeworld discontinued
- Status: Fixed
- Bug: N/A
With the Fedora chromium package now using codecs from the system ffmpeg available at runtime, RPM Fusion counterpart package is now discontinued. Please use the Fedora chromium package.
sudo dnf swap chromium-freeworld chromium
Fedora mesa-va-drivers vs mesa-freeworld
- Status: In-progress
With Fedora packaging enforcing mesa-va-drivers on upgrades, the user installed mesa-va-drivers-freeworld might produce a file clash. If you experience that, add the recommended "-x mesa-va-drivers" hook in your command, such as:
sudo dnf update -x mesa-va-drivers
NVIDIA legacy 390xx/340xx
- Status: Best-effort
The 340xx and 390xx legacy branches are not maintained anymore by NVIDIA and are provided as best effort basis. More likely that things will break with one or another kernel update, or other incompatible component. If that break occurs, you will have the pieces. One way to mitigate is to use the kernel-longterm-6.1 copr repository as advertised in the Howto/NVIDIA
Fedora 37
mesa-freeworld needs
- Status: Fixed
With the removal of potentially patented codec removal for mesa hardware acceleration in Fedora side, there is a needed to provide a "complementary package" This is mentioned in the Howto/Multimedia section.
FFmpeg-free Complement
- Status: Fixed (to some extend)
With the introduction of FFmpeg in Fedora, we had an initial solution to conflict with this lame version. But this isn't ideal as most users using graphical interface won't be able to use full featured version. As with Fedora 37, we are building a complement package (libavcodec-freeworld) that can be installed along the ffmpeg-free libraries.
Note: It is still recommended to switch to the full featured ffmpeg version from RPM Fusion to avoid weird interaction issue:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
Fedora 36
See also https://ask.fedoraproject.org/tags/c/common-issues/141/none/f36/l/latest
System-upgrade and kmod(-nvidia) issue
- Status: Unfixed
With dnf system-upgrade with installed kmod (so far often reproduced with nvidia), the upgraded system doesn't show the available kernel module (with modinfo nvidia) despite the kmod package been present for the updated kernel. The issue isn't reproducible so far with dnf update --releasever=36 and only saw with dnf system-upgrade.
This can easily be fixed by using "sudo depmod -ae" and rebooting the system.
NVIDIA driver and simpledrm conflicts
- Status: Fixed with fedora kernel 5.17.10-300.fc36 and akmod-nvidia-510.68.02-2.fc36
Since the fedora 36 feature related to simpledrm , there were an early conflict with simpledrm and the nvidia driver early initialisation routine. Since the fedora kernel is now preventing to enable simpledrm if nvidia is detected, the patches provided in our RPM Fusion package have been dropped with the newer packages.
FFmpeg-free conflicts
- Status: WONTFIX
With a single maintainer introducing a ffmpeg-free binary packages into Fedora, competing with our fully featured ffmpeg build, this leads to various conflicts and interactions issues. While one could admittedly rejoice from the ffmpeg introduction intro Fedora (enabling ffmpeg support for some fedora package lacking it), the method used to forcibly introduce an un-backed (by most RPM Fusion packagers involved) package with uncertain features enabled, was perceived as unfriendly for the least. A determining argument for any "new eyes" is the very short time the Fedora review took compared with a fully backed 6 months Fedora feature review process.
Having non-competing packages in fedora+rpmfusion repositories is not a side thing, this is the reason why the RPM Fusion projects was created in the first place. Because of that we cannot afford support for ffmpeg-free at all and will recommend to migrate to our fully featured version.
- Fedora Workaround:
sudo dnf swap ffmpeg-free ffmpeg --allowerasing
- Silverblue/Kinoite/Ostree workaround:
Not relevant as ffmpeg is not installed by default there.
VLC dropped support for VA-API hw acceleration
- Status: Fixed
Upstream report: https://code.videolan.org/videolan/vlc/-/issues/26772
The VLC video player is built with system "ffmpeg" package which was updated to 5.0x branch in fc36. This update have seen a big change in how the "ffmpeg" library handle VA-API support and this has leaded to big changes in the vlc 4.x code base. While some changes have been made into the vlc 3.x branch to support ffmpeg-5 this isn't the case so far for the VA-API changes.
Long term fix will be to move to vlc-4.x (no estimated release date yet). or backport the fix for VA-API and ffmpeg5 (someone needs to do the port). or switch to VDPAU (using the libvdpau-va-gl package might only work under Xorg).
Fedora 35
See also https://fedoraproject.org/wiki/Common_F35_bugs
NVIDIA driver / Kepler GPU
- Status: Solved
- Bug: NA
The NVIDIA driver from the 495 series has dropped support for some older cards (Kepler generation), users upgrading from earlier Fedora are advised to verify which driver best fit their needs (and remember nouveau exists). The new 470xx legacy series has been introduced in older Fedora. Users will migrate by default to this series. See also Howto/NVIDIA
CUDA 11.5 / GLIBC 2.34
- Status: Unsolved as of 20211103
The CUDA compiler have some interaction issue with the newer glibc in Fedora and others distributions. This will be addressed by NVIDIA CUDA team within a forthcoming CUDA 11.5 minor release.
Fedora 34
See also https://fedoraproject.org/wiki/Common_F34_bugs
Fedora 33
See also https://fedoraproject.org/wiki/Common_F33_bugs
vlc
- Status: Not an issue
From time to time, VideoLAN vlc upstream team issue an update where the version miss-matches between the RPM package and the "about dialog". This is an upstream issue that isn't fixed downstream. Please consider the package version as the only source of true, specially when reporting to upstream bug tracker. (ex: rpm -q vlc vlc-3.0.12.1-1.fc34.x86_64 whereas the about dialog reports 3.0.11.1).
Fedora 32
Steam/gnome
- Status: Fixed - May 2020
With a default update of the package, gnome-shell might be triggered even on non Fedora Workstation Spin.
- sudo dnf update --setopt=install_weak_deps=False
Kodi 18/python3
- Status: Fixed - May 2020
- Bug: N/A
Fixed with kodi-18.6-4.fc32. The maintainer has reverted the change to python3 and built with python2. One can experience sides effects with configurations, so one might have to clear settings...
Original issue:
With python2 been deprecated in early 2020, it become unreliable to maintain a python2 on newer Fedora releases. Because of that, kodi will only be provided with python3 support on RPM Fusion for Fedora 32 and later (backporting patches when needed). If you rely on some non-packaged extension, please verify that python3 support is available for them and try to forward the question to the upstream maintainer of the extension.
This backported python3 support is ahead of the upstream target to support python3 by kodi v19 (not yet scheduled).
In the end, if you are affected any extension still not ported to python3. You may delay the update of Fedora to 32 or later for any Kodi usage. And wait for Kodi 19 before to update to a newer Fedora.
NVIDIA/340xx/kernel-5.6
- Status: Fixed - May 2020
Original issue:
The nvidia 340xx driver isn't yet compatible with the kernel provided by default for fedora. Please remind that 340xx driver will be provided on best effort basis as it's not supported anymore by NVIDIA.