Fedora 24 repositories have been available for quite some time now, but here is the official statement that everything should be supported out of the box.
As part of the repository availability, I would like to say that starting from Fedora 24, the repositories are self-sustained and do not require RPMFusion to be enabled. I try to preserve compatibility between the two, so if you step into any problem just open an issue to the specific package on Github, send me an email or drop a message in the comment section of the various pages. Please note that “compatible” means that actually you shouldn’t get any conflict when installing packages, and not that I will not overwrite/obsolete the packages provided in the other repositories.
CentOS/RHEL 7 repositories have been available stand alone since the beginning and do not require external repositories to be enabled. Again, if an RPMFusion (or whatever will be mainstream at the moment) CentOS/RHEL 7 repository will appear, I will try to be compatible with it.
Table of Contents
Scope of support
My basic idea is to have what I’m using normally everyday as a package in Fedora, enabling software combinations that would be otherwise impossible to distribute in official repositories due to license/patent issues. This for example includes NVENC (Nvidia Encoder) FFMPeg enabled builds that I use almost everyday.
Being a daily CentOS/RHEL 7 user I also want to support the latest and gretest of the same software on that platform, which also means rebuilding some official CentOS/RHEL 7 packages like VP8/9, VDPAU and VA-API libraries.
Due to the various package builds being different (or simply containing newer software releases) from what the other repositories offer, I also try to be completely independent, you can basically install the operating system and just use my repositories.
Build system changes
The (internal at the moment) build system uses Github as its primary system for storing the package information. There is a Negativo17.org public organization where all the work goes, so if you want to look at the development or the SPEC files, just browse to Github. If you have an issue or proposed change as well, you’re welcome to open an issue or create a merge request in the specific package Git page.
Skype Web Pidgin plugin
The Skype repository used to contain purple-skype for Fedora and CentOS/RHEL distributions which at the time required an installed Skype to work. Now, I helped a new Fedora contributor into integrating the newly developed Skype web plugin, which is based on the Skype web client. The package in Fedora obsoletes and provides correctly the skype4pidgin plugin and as such I don’t need to provide anything else in the repository.
The installation instructions have been updated to reflect this.
Skype is available only in 32 bit format, so on a 64 bit a 32 bit client will always be installed. Since the merging with MSN, the HTML welcome screen requires a 32 bit WebKit GTK build to start. This is not included in the 64 bit only CentOS/RHEL 7 repositories; so for this reason, if you are running CentOS/RHEL 7, it requires the multimedia repository to be enabled and have the dependency solved. This used to be self-contained in the Skype repository, but this is no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.
Spotify Client
The Spotify repository used to contain FFMpeg for CentOS/RHEL distributions and a requirement on FFMpeg’s RPMFusion as a Fedora dependency. FFMpeg is no longer included in the CentOS/RHEL 7 repositories so the multimedia repository has to be enabled to have the dependency solved. As for Skype, this no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.
Here as well the installation instructions have been updated to reflect the change.
aKMOD kernel module packages
The kernel binary module packages generated by aKMOD are now compressed with XZ, like in the original Fedora kernel packages that contain kernel modules. I’ve become a DKMS contributor, so, as time permits, I will add the same functionality to DKMS for Fedora distributions.
At the moment, this applies to Nvidia and X-Pad kernel modules.
Gstreamer plugins and multimedia libraries
The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled. This is split into the following GStreamer runtime packages:
gstreamer1-plugins-badgstreamer1-plugins-uglygstreamer1-vaapigstreamer1-libavgstreamer1-plugins-bad-fluidsynth(pulls in the whole FluidSynth distribution)gstreamer1-plugins-bad-nvenc(x86_64 only, pulls in the Nvidia binary driver; and at the moment it does not work properly)
They all have an Epoch of “1”, due to the various reasons explained at the top. They are not yet available for CentOS/RHEL 7 due to time constraints; I will try to prepare them in the next weeks.
Fedora 24 OpenH264 repository
A note on the Fedora 24 OpenH264 repository. As described in its wiki page, there is an extra repository that can be enabled directly in Fedora 24 that allows you to install OpenH264, its relevant Gstreamer 1.0 plugin and a Mozilla plugin for Firefox. Following the same logic, at the moment the same Gstreamer 1.0 plugin is provided/obsoleted (in newer form) by the gstreamer1-pluings-bad package. There is a conflict for the OpenH264 binaries which I will address soon.
The yum repo has been working beautifyllt for a good while now, thanks a bunch!
But, … now I get dependency issues on RHEL 7.6 x84_64:
~$ sudo yum update
…
Resolving Dependencies
–> Running transaction check
—> Package spotify-client.x86_64 1:1.0.94.262.g3d5c231c-1.el7 will be updated
—> Package spotify-client.x86_64 1:1.0.96.181.gf6bc1b6b-1.el7 will be an update
–> Processing Dependency: libc.so.6(GLIBC_2.18)(64bit) for package: 1:spotify-client-1.0.96.181.gf6bc1b6b-1.el7.x86_64
–> Finished Dependency Resolution
Error: Package: 1:spotify-client-1.0.96.181.gf6bc1b6b-1.el7.x86_64 (spotify)
Requires: libc.so.6(GLIBC_2.18)(64bit)
…
Any chance of a fix? Pretty please 😀
Cleaning the yum cache should be fine, version 1.0.96.181 is no longer in there, it has been briefly: https://negativo17.org/repos/spotify/epel-7/x86_64/
Version 1.0.94.262 will be the last one for RHEL 7, as new ones require newer Glibcs, sorry.
Ah, too bad, but RHEL8 is in Beta! 🙂
Anyway, thanks for the clarification.
mpg123-1.23.3-2.fc24.x86_64 does not work:
$ mpg123 .
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.23.3; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
[src/libout123/module.c:141] error: Failed to open module alsa: file not found
[src/libout123/module.c:141] error: Failed to open module oss: file not found
[src/libout123/module.c:141] error: Failed to open module jack: file not found
[src/libout123/module.c:141] error: Failed to open module portaudio: file not found
[src/libout123/module.c:141] error: Failed to open module pulse: file not found
[src/libout123/module.c:141] error: Failed to open module sdl: file not found
[src/libout123/module.c:141] error: Failed to open module nas: file not found
[src/libout123/module.c:141] error: Failed to open module openal: file not found
[src/libout123/libout123.c:431] error: Found no driver out of [alsa,oss,jack,portaudio,pulse,sdl,nas,openal] working with device .
main: [src/mpg123.c:332] error: out123 error 3: failure loading driver module
Looking at it.
This has been fixed, new build being uploaded now.
Any ETA on the CentOS 7 plugins?
Ugly, VAAPI, and libav ready. I’m finishing the bad one now, I hope to have the build and announcement ready for today.
I like to add one more package to Fedora this repo.
I have a copr repo, and i sucessfully compilled dolphin-emu master branch.
Its hard to find newer dolphin version for Fedora, so, if you like, this is my copr link:
https://copr.fedorainfracloud.org/coprs/victoroliveira/Dolphin-emu/
I’ve added a git snapshot build of the emulator, as I need DolphinBar support. The SPEC file is pretty different.
After upgrading to gstreamer1-libav.x86_64 1:1.8.2-2.fc24 it works, thanks!
I cannot open VM console with virt-manager when ffmpeg 3.1.1-1.fc24 is installed, it crashes:
Core was generated by `/usr/bin/python2 /usr/share/virt-manager/virt-manager’.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f08108b26f5 in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f0811b1f700 (LWP 5666))]
(gdb) bt
#0 0x00007f08108b26f5 in raise () at /lib64/libc.so.6
#1 0x00007f08108b42fa in abort () at /lib64/libc.so.6
#2 0x00007f07b0adaacb in () at /lib64/libavcodec.so.57
#3 0x00007f07b0adab26 in avcodec_alloc_context3 () at /lib64/libavcodec.so.57
#4 0x00007f07b22ad080 in gst_ffmpeg_cfg_install_property () at /usr/lib64/gstreamer-1.0/libgstlibav.so
#5 0x00007f07b22a338e in gst_ffmpegvidenc_class_init () at /usr/lib64/gstreamer-1.0/libgstlibav.so
It works again if I downgrade ffmpeg-libs ffmpeg-devel ffmpeg libavdevice to 3.0.2-1.fc24 (from rpmfusion-free)
That’s weird, does not happen here. I’m double checking for any ABI/API breakage, but I’m not sure.
Are you getting the packge
gstreamer1-libav-1.8.2-1.fc24.x86_64also from my repository?Btw, are you on an Intel video card? So are you using VA-API video acceleration? Maybe that’s the cause. I’m rebuilding
gstreamer1-libavnow.Yes, I have gstreamer1-libav-1.8.2-1.fc24.x86_64
But it happens on 2 different PCs – one with Intel and another with nvidia.
It works after I downgraded gstreamer1-libav from fedora-HandBrake to a version from rpmfusion-free-updates.
Is it possible to use this repository on rawhide? I upgraded to rawhide and handbrake still functions however the repo reports that it cannot synchronise the cache.
Not yet, I normally rebuild everything and introduce repository syncing a couple of months prior to the release. I’m planning to enable builds for unreleased versions soon.
Currently getting this while trying to upgrade from Fedora 23:
[MIRROR] x265-libs-1.9-1.fc24.x86_64.rpm: Downloading successful, but checksum doesn’t match. Calculated: 492e03c989e9385d6253780c952a11b80aaad63620e3075e0f351d470f3f1335(sha256) Expected: 4687156ab1528587977f8a9bd9a5b3a176b7adf978b60af4b116f7d5d6f72fdd(sha256)
Doesn’t happen here… cache problem? Have you tried erasing your dnf cache?
Thanks a lot. You have a typo, it is gstreamer1-libav/gstreamer1-vaapi, not gstreamer1-plugins-libav/gstreamer1-plugins-vaapi.
Fixed, thanks.