I have fedora-cisco-openh264 repo from dnf install fedora-repos
it is enabled:
sudo dnf config-manager --set-enabled fedora-cisco-openh264
However, no package in that repo resolves.
dnf list *openh264*
Last metadata expiration check: 0:15:42 ago on Sat 30 Dec 2023 22:08:55.
Error: No matching Packages to list
Is this a known issue or a bug? I am trying to install ffmpeg from a src.rpm and it requires openh264. How do I get the repository to behave?
The package openh264 should be available in fedora-cisco-openh264. However, I don’t remember if that repo is enabled by default (although I guess it is). Anyway, can you check the output of cat /etc/yum.repos.d/fedora-cisco-openh264.repo ? The [fedora-cisco-openh264] section should contain enabled=1 and not enabled=0. The [fedora-cisco-openh264-debuginfo] section shall remain enabled=0.
Once this is enabled, try dnf install openh264 → if this doesn’t work, please provide the full output of both the above cat and the dnf command. Also, in this case, provide the output of uname -r.
However, be aware that ffmpeg is not in the repositories that are shipped with Fedora because (as many audio/video codec packages) it causes issues with patents and such. So this is a legal issue. Thus, if you want to have ffmpeg on your Fedora, one way to get it is to enable rpmfusion-free-updates (find more here). Be aware that rpmfusion repos are not officially supported, but it might be still the “most reliable” way to get it on Fedora natively. This way also ensures that it remains updated. Installing packages by individual rpm files is not suggested because it does not ensure updates and such. Also, the quality assurance of unknown package providers is unclear → rpmfusion folks are strongly interrelated with Fedora people, and the quality assurance is comparable.
There you go:
# cat /etc/yum.repos.d/fedora-cisco-openh264.repo
[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True
[fedora-cisco-openh264-debuginfo]
name=Fedora $releasever openh264 (From Cisco) - $basearch - Debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-debug-$releasever&arch=$basearch
type=rpm
enabled=0
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True
[fedora-cisco-openh264-source]
name=Fedora $releasever openh264 (From Cisco) - $basearch - Source
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-source-$releasever&arch=$basearch
type=rpm
enabled=0
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True
# dnf install openh264
Last metadata expiration check: 0:37:25 ago on Sat 30 Dec 2023 22:08:55.
No match for argument: openh264
Error: Unable to find a match: openh264
What about uname -r?
# uname -r
6.7.0-0.rc6.20231221gita4aebe936554.51.fc40.x86_64
That’s the issue. You are running a future version of Fedora that is still testing. I guess the openh264 repo is not integrated with that.
You can use openh264 on a current version of Fedora. This is F38 and F39. Obviously, F40 is not yet considered in this repo. I’m quite sure the search fails when resolving the $releasever parameter.
You are aware that you run an unstable testing system that should not be used for production use but only for testing? Your kernel is itself still in development and not yet released (rc6 = release candidate). So, both your Fedora and your kernel are testing and have to be considered highly unstable. I just want to be sure that you know what you are running.
I am fully aware of the risks. Since fedora-cisco repo does not serve rawhide please point me to the appropriate metalink.
Ok.
I guess there is no Fedora repo for that, and thus no F40 build of the package. If we had one, it would be resolved and found by the enabled repo.
You might download the F39 package (so, download the rpm file) and install it manually on F40. But there is no guarantee this works, although I expect it will. If there are further dependencies not satisfied by F40, you might do the same for these dependencies.
So, if you want to try this (unsupported) approach, get the packages (and all dependencies that are asked for that cannot be satisfied by F40), and do, e.g., dnf install openh264-2.3.1-2.fc39.x86_64.rpm <otherdependency1.rpm> <otherdependency2.rpm> from the very folder these *.rpm files are containted in.
Keep in mind that these packages will not be updated.
Like you rightly observed, dnf is not picking the package. I was expecting a download url (something wget can fetch). I can handle the rest. It would be nice if cisco’s repo shows package listing (indexed).
Please read my comments in total:
→ If you download the packages and run the dnf command from the very folder, it will find the packages contained in the folder.
Concerning the links …
https://codecs.fedoraproject.org/openh264/39/x86_64/os/Packages/o/openh264-2.3.1-2.fc39.x86_64.rpm
Here are all packages of this repo: Index of /openh264/39/x86_64/os/Packages
When you change 39 to 40 in the link, you can see that 40 does not yet exist.
Thanks a lot especially for the last link. You have made my day.
Happy to help. Feel free to mark a solution to help other people experiencing this or a comparable issue. This makes it easier to identify it when a topic has several posts.
I’m commenting since I and others could find that note interesting. I intend on doing a deep dive of Rawhide for some time and those small details are interesting to know.
I think containerizing applications could serve as a good tool to aid in some potential pain points with certain software and packages. Strong options for Web Browsers, Developer tools, Virtualization tools.
Thanks @py0xc3
Always happy to help 
It might be added that at this point we no longer guess but know for sure:
I guess the */40/* folder comes with the F40 release.
However, I mentioned already above that I expect it will work with the F39 files: the nature of the packages of this repo is neither tailored to Fedora nor should it be necessary to make noteworthy changes to this type of packages for different releases as long as some required packages / technologies are available.
At a wild guess, I just compared the F38 and F39 packages of openh264: both hash to the same sha256sum. So, they are equal.
If anyone needs this in rawhide, people might make a request to either create the next repo branch of this repo already when the related future release still evolves through rawhide, or something else that ensures updates.
In the end, with this type of packages, the current release’s repo branch should always be eligible for use in rawhide as long as required rawhide packages do not become “too new” (although this might cause issues from time to time when openh264 dependencies get updated in rawhide before it occurs in the releases) → but every way that ensures updates of the packages should be preferred over manual installations of rpm files.
The openh264 packages are built on the fedora build servers in the same way as the other fedora packages. I am not sure if it is legal to download the package from koji.
My argument doesn’t challenge this assumption 
Although I don’t think your assumption is correct: based upon our wiki, the paid licensing of Cisco is limited to the binary provided by them. This would also explain that F38 and F39 builds are equal.
I can see the packages in koji, but if I try to download the files (e.g., from the related koji page), koji forwards me here instead of starting the download: Non-distributable-rpms - Fedora Project Wiki
Indeed, it didn’t knew this detail before as well.
The above link does not use koji (as seen above, koji cannot provide the package, it only documents it). I do not see a reason why there should be a legal difference if dnf downloads from the above source or if the users do it themselves. The content of the repo comes from GitHub - cisco/openh264: Open Source H.264 Codec → BSD 2-clause license. All good so far. The related patent(s) of this implementations are covered from Cisco downstream to the users ([1] [2]): Fedora can use it throughout as long as we use the binaries from Cisco. Further, given the patent restrictions we have from Red Hat to protect them as the legal entity of Fedora, I have no doubt that Red Hat would not take the responsibility for this repo to be shipped by default if it could cause such issues.
A short extract from the page that koji refers to:
Cisco has paid for a patent grant for people to use this codec. However, one of the terms of the patent grant is that Cisco must distribute the binaries.
So all binaries we have shipped in Fedora are licensed from Cisco and are ok to be used downstream. Within Fedora, we do not need to care but only ensure that no one starts to create own builds from it (which is not allowed at all)
However, thanks for raising this assumption: I just learned something new 
Its indeed an interesting case!
( and have a good start into 2024 
)
8 posts were split to a new topic: Does the fedora-cisco-openh264 repo make Fedora to be not free? Is the repo content a binary blob? Implications?
I have moved the recent posts into a new topic because that had no longer anything to do with this topic. This way both topics can remain focused.