This is about the following two packages coming from the fedora-cisco-openh264 on Fedora 29:
fedora-cisco-openh264
gstreamer1-plugin-openh264-1.14.2-1.fc29.x86_64 mozilla-openh264-1.8.0-2.fc29.x86_64
Ever since the fedora-cisco-openh264 repository has existed, I have had to manually enable the repository from the CLI and install the packages myself. It's not listed as one of the third party repositories, so I assume that it's not covered by the UI toggle for those. Since it's free software built on the Fedora build system, it's probably not right to club it with PyCharm, Chrome, NVIDIA and Steam anyway.
We have finally managed to reduce the gap with Ubuntu in terms of multimedia codecs. Out of the box H264 support seems like another big step forward in that direction.
Yes, it's correct that the third party repositories UI toggle in gnome-software doesn't cover fedora-cisco-openh264. The reason is that it is not needed because all the UI toggle does is install the .repo files for 3rd party repos. We don't need to do that for fedora-cisco-openh264 because the .repo file comes preinstalled.
gstreamer plugins already have automatic installation (including installing from enabled=0 enabled_metadata=1 repos, prompting to enable the repo if it's disabled). Firefox as far as I know lacks any kind of support for automatically installing mozilla-openh264 from package repos so that part is missing.
Also, Firefox has these days switched from gstreamer to ffmpeg (it can still use mozilla-openh264 for certain situations, afaik), so installing the gstreamer codec doesn't get us to working youtube playback in Firefox.
Can't we ship the repository as enabled, and then have gnome-initial-setup or gnome-software pull in the two RPMs immediately after installation at the first availability of a network? That seems simpler. Also, someone who might be on the road and wants to play H.264 in totem won't have to look for some unreliable network connection to install the codec.
totem
(I know that currently OpenH264 only supports H.264 to the extent that one can use WebRTC, but that's an orthogonal issue.)
Also, Firefox has these days switched from gstreamer to ffmpeg
Yes, I know. :) Surely we must have patched out the H.264 codec from the Fedora RPM?
I would like that too, but my understanding is that it was a Council requirement to ship it disabled. @uraeus or @mattdm maybe remember what the exact agreement was.
Yes, AFAIK Fedora firefox build doesn't include the ffmpeg code and needs compat-ffmpeg28 from rpmfusion installed to be able to play youtube.
Nope, YouTube works out-of-the-box for me with Fedora's Firefox. I certainly haven't installed anything extra.
Also, I think we need a concrete plan to implement Christian's old proposal to enhance openh264 with support for whatever non-baseline profiles that required for MP4 playback. I had been expecting this to have been completed a long time ago. :/
Unfortunately getting all the paperwork done took a lot longer than anticipated due to having so many companies involved, but Centricular has been working on this recently and I was told last week the work on reaching the higher profiles should be complete within a couple of weeks and submitted upstream to Cisco for merging. After that hopefully there will be a new release relatively quickly. Centricular plans on working performance improvements for a bit after that, so be aware that the first release will work,but not be highly performant, but that we should at least see some improvements to performance in later releases of OpenH264.
Umm... so shouldn't we at least enable the fedora-cisco-openh264 repository by default?
I understand that actually auto-installing the packages is much more complicated because we can't distribute them ourselves on the ISOs.
That's because Google transcoded most (all?) YouTube videos to WebM.
@uraeus, could you provide a status update on this, please?
The new release was just released last night and we have openh264-2.0.0-1.fc30 and gstreamer1-plugin-openh264-1.16.0-1.fc30 built in koji. Now it's up to Fedora releng and Cisco to publish the builds: https://pagure.io/releng/issue/8439
It'd be good to have a status update on this.
Metadata Update from @catanzaro: - Issue tagged with: meeting
It's waiting on releng to publish openh264 2.0.0 builds.
@uraeus, please remember last week's meeting action item to provide an update in this ticket :)
I can't install the totem recommended codec on Fedora 30 or Fedora 31, manually. Not exactly related because we want this to happen automatically to avoid all of this. https://bugzilla.redhat.com/show_bug.cgi?id=1749566
I'm becoming quite concerned about this issue, it's like it's been dropped into a void where nobody is taking care of it.
I'd like to see some motion to ensure releng will have builds ready in time for F31 beta. And then we'll need a Workstation developer to debug why codec installation is broken yet again.
agreed to propose: Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1
assuming:
Does this relate? https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/message/GDOFPFQKWJF5CRU7BNWNTJ756AIZOMYK/
I'm not able to reproduce bug 1749566 in F30 or F31. However, with or without gstreamer1-plugin-openh264-1.15.1-1.fc31.x86_64 installed, I get the same results on this page: http://demo.nimius.net/video_test/
no H.264/AAC yes WebM VP8 no MPEG 4 yes H.264 WebM yes WebM, H.264
Anyway, point is, I can't really evaluate the effectiveness of installing this plugin.
Chris, the new OpenH264 has not been built yet. Once releng builds it for us, Cisco needs to host it. Then we can start testing.
I was pushing to resolve this today because that's a lot of things that need to happen in a fairly short timespan if we want to advertise H.264 support in F31.
Probably not. I understand @uraeus has been working with Fedora Legal on this, and that it has to be Cisco that hosts the RPM, not Fedora.
@uraeus, we really need you to comment here and confirm, or this won't move forward.
@kalev or @uraeus to ensure the PackageKit GStreamer codec installer can propose and install OpenH.264 plugin when playing an MP4 video in totem
I managed to reproduce this and debugged and should be fixed by https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/315
Thanks Kalev!
I manually installed your gnome-software-3.34.0-2.fc31 update and tried playing an MP4 video. The codec launcher took me to this screen:
<img alt="Screenshot_from_2019-09-25_09-26-35.png" src="/fedora-workstation/issue/raw/files/9dea2da870b8bf71142f46689012f8ef75c7247218b65771b88e8a324cd24877-Screenshot_from_2019-09-25_09-26-35.png" />
Which is almost excellent. It's a bit weird that GStreamer Multimedia Codecs - Extra is showing up here, because it does not contain H.264 support. That should probably be fixed.
Then the description of the package, referring to non-encumbered codecs, is clearly incorrect:
<img alt="Screenshot_from_2019-09-25_09-27-51.png" src="/fedora-workstation/issue/raw/files/be38975cd2a3a4ce928df626f52df9767dbab88fe7914a93c56eeeeea618fcc8-Screenshot_from_2019-09-25_09-27-51.png" />
Anyway, these are both minor issues. What's important is that gnome-software was able to successfully install the right package.
Two more important issues before we close out this issue:
(Deleted my last comment because I'm an idiot, the test video I was using was some sort of weird 3D thing. Let me try another test video.)
Test video attached.
Video playback is working well, but audio does not work. We need to investigate why. I have fdk-aac-free-2.0.0-2.fc31 and gstreamer1-plugins-bad-free-1.16.0-4.fc31 installed, so I already have Kalev's changes to enable the AAC support in gstreamer1-plugins-bad-free.
Looks like Pagure silently dropped my attachment.
Test video: http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_60fps_normal.mp4
The audio works just fine for me here with your test file.
Haha, I had a problem with my headphone settings. It works! :D
We might need a more careful review of https://www.openh264.org/BINARY_LICENSE.txt, specifically the AVC/H.264 Patent Portfolio License Conditions. In particular, we probably need to adjust our appstream metadata. We could e.g. change the subtitle on the GNOME Software page from "Multimedia playback for H.264" to "OpenH264 Video Codec provided by Cisco Systems, Inc."
In regards to the question addressed to me about where the binary can be hosted, it has to be hosted by Cisco for the library to be covered by their patent license. If we host it ourselves it is no different from any other h264 implementation,
Discussed at today's meeting. Action items:
Discussed at today's meeting. Action items: @uraeus to confirm this has been approved by legal folks @uraeus to ask legal about AVC/H.264 Patent Portfolio License Conditions, specifically points three and four
@uraeus to confirm this has been approved by legal folks @uraeus to ask legal about AVC/H.264 Patent Portfolio License Conditions, specifically points three and four
Hi @uraeus, any updates here?
Also: I notice Firefox is unable to use the new codec, so currently this only works in GStreamer-based apps like Epiphany, Totem, etc. Is there any work underway to improve Firefox?
I'm removing the meeting tag since this is not ready for meeting.
Metadata Update from @catanzaro: - Issue untagged with: meeting
Keeping this open because there are three unresolved loose ends.
Incidentally, we are having some trouble with OpenH264 crashes and the OpenH264 developers have so far not been responsive in the GitHub issue created by Rob McQueen. Any contacts with Cisco might be helpful for this.
It would be good to have a summary of the status of this issue: we need approval from RH legal before we can enable the 3rd party repo for h264?
Is the issue raised by @catanzaro above a blocker or a just a detail?
Well we already enabled the repo.
Summary of current state begins at https://pagure.io/fedora-workstation/issue/84#comment-601209. I'm fairly certain that we already have approval from Legal, but the WG has asked Christian to confirm this and we're still waiting on him for that. Then there are a couple little details we asked him to bring to Legal.
Finally, functionality. Firefox is currently unable to play most HTML5 video because it doesn't use OpenH264 except for WebRTC. You have to install RPMFusion to make Firefox acceptably useful. Meanwhile, Epiphany can use it, but OpenH264 is crashing and Cisco won't respond to our bug report. We need to get in touch with them somehow.
but OpenH264 is crashing and Cisco won't respond to our bug report. We need to get in touch with them somehow.
Egads. Yes I agree, crashing is never a good thing. It's Is it urgent enough we should discuss whether to remove/disable in the fc32 cycle, if it isn't fixed by, say, final freeze?
I don't think we need to discuss that possibility yet.
Crashes and and other bugs seem a bit unrelated to this issue.
I filed this issue because it seemed to me that we are shooting ourselves in the foot by making it really convoluted to get codecs that were for so many years unavailable to us for legal reasons. Now that the legal barriers have been eased, we seem to have artificially put up some obstacles of our own making. :)
I say this based on the assumption that anything (configuration or code) that's statically baked into the installation image is more robust than anything that happens dynamically on the user's system based on some conditions. eg., shipping a repository as enabled=1 is more robust than having some code that can under certain conditions enable it; and unconditionally (barring privacy concerns) pulling in the two RPMs after installation is more robust than relying on GStreamer and GNOME Software to work it out when a certain codec is necessary.
enabled=1
The more we rely on the dynamic behaviour, the more important any bugs in those code paths become, which just means more stress for us. :)
Indeed, it seems that there are 3/4 issues being discussed in this ticket, which is making it quite difficult to follow.
I filed this issue because it seemed to me that we are shooting ourselves in the foot by making it really convoluted to get codecs that were for so many years unavailable to us for legal reasons. ... I say this based on the assumption that anything (configuration or code) that's statically baked into the installation image is more robust than anything that happens dynamically on the user's system based on some conditions.
I agree. #105 is one attempt to reduce the current complexity. It would be good to investigate if there are other steps we could make.
Well we can split out remaining issues once Christian gets back to us to answer our pending questions. I don't see any value in creating five issues for Christian to respond in when we currently have all pending action items for him in one place, and most can be resolved immediately upon his response. Whatever requires further tracking, we can split out at that time.
Rishi, I had no idea you weren't satisfied with the GStreamer-based solution. I'm certain the rest of the WG also thought that getting the GStreamer-based plugin workflow working was what you wanted. There is no policy reason that it cannot be enabled earlier. Your request is just to ship the repo as enabled=1 instead of enabled=0?
The repo file is https://src.fedoraproject.org/rpms/fedora-repos/blob/master/f/fedora-cisco-openh264.repo. Since this repo contains exclusively free software, I think we could just flip it on. It should not be controversial like fedora-workstation-repositories would be. But the software is not going to automatically install itself. You want some sort of post-installation script to install it unconditionally, even when the user hasn't attempted to play any media that requires it? How would this postinstallation script be more useful or more robust than the current workflow?
Rishi, I had no idea you weren't satisfied with the GStreamer-based solution. I'm certain the rest of the WG also thought that getting the GStreamer-based plugin workflow working was what you wanted. There is no policy reason that it cannot be enabled earlier. Your request is just to ship the repo as enabled=1 instead of enabled=0? The repo file is https://src.fedoraproject.org/rpms/fedora-repos/blob/master/f/fedora-cisco-openh264.repo. Since this repo contains exclusively free software, I think we could just flip it on. It should not be controversial like fedora-workstation-repositories would be. But the software is not going to automatically install itself. You want some sort of post-installation script to install it unconditionally, even when the user hasn't attempted to play any media that requires it? How would this postinstallation script be more useful or more robust than the current workflow?
Sorry about the confusion.
In principle, I just want everything to just work, but that's impractical. So I thought shipping fedora-cisco-openh264 with enable=1 could be an easy way to reduce some of the variables from the equation. See: https://pagure.io/fedora-workstation/issue/84#comment-549831
enable=1
The next step could be to have gnome-initial-setup or gnome-software or something automatically install the two RPMs from Cisco, but that involves writing code. So maybe that could be a future step. See: https://pagure.io/fedora-workstation/issue/84#comment-544062
gnome-initial-setup
gnome-software
As long as the codec installer is working, I don't see any problems with the current solution.
I disagree. It would be nice to make it simpler if we can (set enable=1 in the .repo file by default). This would remove one extra step/mouse click when installing the openh264 codecs, and also make them simpler to install from the command line.
Autoinstall it with the first batch of updates?
I don't think there's anything blocking us from changing to enable=1. I didn't realize that would remove a step from the process. If that makes it easier, let's do it.
I have a question. Why is gstreamer1-plugin-openh264 a separate package from gstreamer1-plugins-bad-free? I notice we are using upstream gstreamer-plugins-bad 1.16.0 for our gstreamer1-plugin-openh264, but using gstreamer-plugins-bad 1.16.1 for our gstreamer1-plugins-bad-free, i.e. our openh264 subpackage is updated less-frequently than the rest of the plugins. At first I assumed it was split out this way to somehow facilitate the installation of openh264, but there's no Requires from the gst plugin to the main package, so that can't be. Is it because we don't want gstreamer1-plugins-bad-free to depend on the openh264 package?
gstreamer1-plugin-openh264 is separate because we don't have openh264 available in koji build roots. As a workaround for that, gstreamer1-plugin-openh264 is built from the same source package as openh264 and shipped in the cisco repo.
Metadata Update from @chrismurphy: - Issue tagged with: meeting
From Taiga, there are two items we can discuss at the next meeting that do not depend on @uraeus
Reference: https://teams.fedoraproject.org/project/workstation-wg-1/us/16?kanban-status=396
Realized I missed this ticket for a while. So to try to respond: 1) legal has approved the current setup of having binaries provided by Cisco 2) As for metadata, to some degree that is not our problem to solve. If Cisco needs the metadata changed to conform to the H264 patent license then they should let us know. 3) As for Firefox, I suggest discussing with Martin Stransky to figure out what can be done.
3) As for Firefox, I suggest discussing with Martin Stransky to figure out what can be done.
I've opened a new ticket for this: https://pagure.io/fedora-workstation/issue/126
Thanks Christian!
So that clears out all our subtickets, and brings us back to Rishi's original request: (a) enable the repository by default rather than requiring the codec installer to do so, and then (b) have either gnome-initial-setup or gnome-software install it automatically? @kalev, this issue is squarely in your court now. Any opinions?
I've been asking for months now for Workstation WG to do a vote to say that they'd like to change fedora-cisco-openh264.repo from enabled=0 to enabled=1. Can we finally please do that? Armed with this, I am happy to go and ask releng to change this. Thanks.
change fedora-cisco-openh264.repo from enabled=0 to enabled=1
In tomorrow's meeting, I will ask consent to do exactly this.
Should the question apply only to F32? Or can and should it apply retroactively to F31/30? Seems to me the WG should decide a policy: changing 0->1. Whether to apply it to Fedora 32 only or 30+ is a technical matter. I'll be gratified to have complete clarity on this point.
We agreed to ask releng to change enabled=0 to enabled=1. We also agreed to ask releng to change pungi to ensure the contents of this repo are excluded from compose.
Discussing this further with Rishi. Regarding automatic installation, we have four options:
I'm fine with any of the above.
What about upgrades?
For clean install, I prefer 2 or 3. Gnome Software has a bunch of updates to do anyway, tacking this on seems easy.
We don't need to worry about upgrades because the codec installer exists. Anything using GStreamer should trigger the installer if it's needed (except for WebKit, which is broken). Then Firefox is the elephant in the room, for not using our platform media support and instead doing its own thing. I'd say support for OpenH264 would be incomplete if it doesn't also learn to use the codec installer, although it would want to do so via PackageKit directly since it doesn't use GStreamer anymore.
I think that's a good summary of the situation. Thanks, @catanzaro! I'm also fine with any of the four options above.
Metadata Update from @chrismurphy: - Issue untagged with: meeting
Let me know if there's more to discuss in a future meeting.
I don't think we necessarily need a future meeting, because we don't have any concrete proposal yet. I suspect the WG would be fine with any of the four proposals, and that if anyone has an objection it would have been noted by now.
Just don't automatically install it, instead expect the codec installer to work properly
Honestly, this is the path of least-resistance. There is no compelling reason it must be preinstalled, because all non-WebKit GStreamer-based applications should preinstall it as required. That should cover everything we care about except:
So I think we can safely close this issue if we achieve a positive outcome on the previous action items:
However, proposal 3, cross-repo Recommends, seems perfectly fine too. If Kalev wants to implement this, I see no reason to object, provided we receive an exception to the packaging guidelines.
Add a cross-repo Recommends to some Fedora package (requires packaging guideline exception, but this should be OK given the exceptional nature of the situation)
As for modifications to either gnome-initial-setup or gnome-software... well, these proposals also seem perfectly fine, but they require engineering effort. So I would say non-essential unless we have a volunteer.
There are a couple of good UX reasons to automatically install the codec:
There's also the issue that the "automatic" codec installation feature is known to be buggy and failure-prone.
h264 is super common, and automatic installation improves the experience for anyone who uses it. On that basis, we absolutely should automatically install it.
Regarding which mechanism or component to use to install the codec, one key consideration is whether we require explicit approval from the user, or for them to have an opt out, before the codec is installed.
Personally speaking, it's not really clear why it's necessary to ask the user before installing it.
We require opt-in consent before installing third-party or nonfree software.
Because OpenH264 is 100% free software, built by Fedora, and only distributed by Cisco for legal reasons, I don't think it should be controversial to install it without requesting consent. Nobody wants to be unable to play MP4 video when there is a free software solution available. We might as well ask the user "do you want to make your computer bad? yes/no"
I don't think it should be controversial to install it without requesting consent.
In that case, perhaps the cross-repo recommends option would be best?
it's not really clear why it's necessary to ask the user before installing it.
Playing the devil's advocate, I wonder if there might be some privacy angle here. A computer pinging the Cisco servers for a specific RPM could be used to identify Fedora users. I guess it depends on how network-prone our current installation and initial setup process is.
@rishi Near as I can tell, that doesn't ever happen. Everything in the fedora-cisco-h264 repo is found in koji and on Fedora mirrors.
Yesterday the working group agreed to automatically install the OpenH264 codec, by using a cross-repo recommends dependency (possibly from totem). To set this up, we will first need to have the OpenH264 repo enabled by default.
It's worth noting that this will automatically install the codec along with the first package update, which isn't as good as immediately installing the codec during initial setup. (We didn't actually discuss this aspect of the design during the meeting.)
Should we consider having gnome-initial-setup install the codec instead? I assume the disadvantage of that approach is that it's more design and engineering effort, and is potentially more fragile?
Sure, we could do that. The main downside I think is that to be able to install the codec during initial setup, we'd need to go and download the package metadata (~100 MB), which can significantly slow down the time it takes to click through the initial setup.
Another potential problem is that if we install something during initial setup without installing updates first, then that install might drag in other package updates through dependencies. This can create a situation where we have some packages on the system updated, some not. Cherry-picking just some updates is not supported in Fedora and can in some cases lead to problems (as we don't test that combination when releasing updates, we only test fully updated systems).
It could be something along the lines that gstreamer1-plugin-openh264 depends on newer gstreamer1 than what is on the install media, which in turn pulls in something else newer, so the end result is that we get a partially updated system when installing gstreamer1-plugin-openh264.
The main downside I think is that to be able to install the codec during initial setup, we'd need to go and download the package metadata (~100 MB) ... Another potential problem is that if we install something during initial setup without installing updates first, then that install might drag in other package updates through dependencies. ...
Makes sense. Recommends it is!
Metadata Update from @ngompa: - Issue assigned to ngompa
Initial steps have been taken:
fedora-repos
Excellent! Thanks, @ngompa!
Thanks for all the work on this, everybody!
Freeze Exception has been requested.
Is it intentional to not include cisco repo's GPG key in fedora-repos? We are hitting some issues with beaker auto installations of F32 and rawhide..
I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1814671 so we can discuss it there. Thanks!
p.s. we have also https://bugzilla.redhat.com/show_bug.cgi?id=1814596 for dnf (check-update fails as repo is untrusted)
See also: Bug 1768206 - DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first
I suspect this is a dnf bug. The key it's prompting for is the regular F32 signing key that all regular Fedora packages are signed with (and should be correctly imported to rpmdb as it doesn't prompt it for other repos).
One difference I can spot is that the fedora-cisco-openh264 repo has repo_gpgcheck=1 whereas regular fedora repos have repo_gpgcheck=0. Maybe this is triggering a bug in dnf?
Probably. This is discussed at https://bugzilla.redhat.com/show_bug.cgi?id=1814671
I went ahead and did this in totem-3.34.1-4.fc32 in https://bodhi.fedoraproject.org/updates/FEDORA-2020-c50d5f6c6f
This is done.
Metadata Update from @catanzaro: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Reopening. I did a fresh install of F32 earlier this week, and openh264 was not installed as expected during the first system update. I had to install it manually just now.
Metadata Update from @catanzaro: - Issue status updated to: Open (was: Closed)
Metadata Update from @catanzaro: - Issue tagged with: meeting-request
Upstream bug report: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1265
Metadata Update from @chrismurphy: - Issue untagged with: meeting-request - Issue tagged with: meeting
I think this may be because the totem package that added openh264 recommends is in the base F32 repo and preinstalled. dnf only looks at the recommends when updating (or installing), but since there is no totem update available it doesn't do anything.
This should hopefully get fixed when https://src.fedoraproject.org/rpms/openh264/c/8f60dd19b9bcb45ec63623eabd97b2f982d2415f?branch=master makes it out to the repos -- that commit moves the weak deps to openh264 package instead. As openh264 is not preinstalled, dnf should take the weak deps into account. So far it's waiting on https://pagure.io/releng/issue/9468
I'll ping releng and ask if they can get to publishing new openh264 soon (it's been two months since I filed the ticket :( ). If not, we can just do a simple totem rebuild that should fix the recommends-not-working issue.
Reopening. I did a fresh install of F32 earlier this week, and openh264 was not installed as expected during the first system update. I had to install it manually just now. I think this may be because the totem package that added openh264 recommends is in the base F32 repo and preinstalled. dnf only looks at the recommends when updating (or installing), but since there is no totem update available it doesn't do anything. This should hopefully get fixed when https://src.fedoraproject.org/rpms/openh264/c/8f60dd19b9bcb45ec63623eabd97b2f982d2415f?branch=master makes it out to the repos -- that commit moves the weak deps to openh264 package instead. As openh264 is not preinstalled, dnf should take the weak deps into account. So far it's waiting on https://pagure.io/releng/issue/9468 I'll ping releng and ask if they can get to publishing new openh264 soon (it's been two months since I filed the ticket :( ). If not, we can just do a simple totem rebuild that should fix the recommends-not-working issue.
I think this may be because the totem package that added openh264 recommends is in the base F32 repo and preinstalled. dnf only looks at the recommends when updating (or installing), but since there is no totem update available it doesn't do anything. This should hopefully get fixed when https://src.fedoraproject.org/rpms/openh264/c/8f60dd19b9bcb45ec63623eabd97b2f982d2415f?branch=master makes it out to the repos -- that commit moves the weak deps to openh264 package instead. As openh264 is not preinstalled, dnf should take the weak deps into account. So far it's waiting on https://pagure.io/releng/issue/9468 I'll ping releng and ask if they can get to publishing new openh264 soon (it's been two months since I filed the ticket :( ). If not, we can just do a simple totem rebuild that should fix the recommends-not-working issue.
You should probably supplement one of the gst1 codec packages we have instead, otherwise this just gets annoying with the number of players that need to be added to that...
I think this may be because the totem package that added openh264 recommends is in the base F32 repo and preinstalled. dnf only looks at the recommends when updating (or installing), but since there is no totem update available it doesn't do anything. This should hopefully get fixed when https://src.fedoraproject.org/rpms/openh264/c/8f60dd19b9bcb45ec63623eabd97b2f982d2415f?branch=master makes it out to the repos -- that commit moves the weak deps to openh264 package instead. As openh264 is not preinstalled, dnf should take the weak deps into account. So far it's waiting on https://pagure.io/releng/issue/9468
I tested this today by installing F32 in a VM and then running 'dnf upgrade'. Unfortunately it doesn't work. I think we're going to need to manually trigger openh264 installation, either in gnome-initial-setup, or the first time gnome-software is run.
It probably makes sense to do it when initial setup runs, it can run in the background while user setup occurs.
Arr, that's a bummer. OK, then we need to do some kind of initial setup integration there, agreed.
Metadata Update from @aday: - Issue set to the milestone: Fedora 34
There is also a mozilla-openh264 subpackage that also needs to be installed somehow.
Agreed: we would like a new gnome-initial-setup page to install mozilla-openh264, gstreamer1-plugin-openh264, and remove anaconda. Since OpenH264 is built by Fedora and is open source, there is no need to ask the user for permission. We need design help (@aday), including help to decide what to do if the network is not available.
Metadata Update from @catanzaro: - Issue untagged with: meeting-request
Er, I'm not sure we really thought that through properly yesterday. Do we really want gnome-initial-setup launching gnome-software in the initial setup session?
I don't think launching gnome-software as a separate app is an ideal experience, whether it happens in the gnome-initial-setup session or the user session. You really want this as just a step in the initial setup / welcome process, not as a detour into a different app.
We discussed this again at today's meeting.
We have a clear path forward on the technical aspects of the change. gnome-initial-setup needs to use PackageKit to perform an online installation of mozilla-openh264 and gstreamer1-plugin-openh264. It should disable all yum repos except for the openh264 repo to avoid downloading a huge amount of repo metadata. If the existing PackageKit D-Bus APIs are not enough, we should add new ones for this purpose. And we should plan for this step to take a potentially long time on slow connections, and to be skipped entirely if internet connection is not available.
We need design assistance, though. @aday, could you help with design?
That would imply that there's UI needed?
I have to say that I do have some doubts about using initial setup for this. Slow or non-existent connections at setup time are one factor. Another is initial setup's capacity to provide feedback in a useful or timely fashion, particularly if issues are encountered.
Have alternatives been considered? I suppose the most obvious one would be gnome-software...
We need design assistance, though. @aday, could you help with design? That would imply that there's UI needed?
That's what we were thinking. Package installation will be quick for users with broadband, but it could take a potentially long time for users with slow connections. And what happens if there is no internet?
I have to say that I do have some doubts about using initial setup for this. Slow or non-existent connections at setup time are one factor. Another is initial setup's capacity to provide feedback in a useful or timely fashion, particularly if issues are encountered. Have alternatives been considered? I suppose the most obvious one would be gnome-software...
We haven't seriously considered using gnome-software, no. Maybe you could propose a design for gnome-software instead? I think that would be fine.
Would GNOME Software visibly launch? Or can it just queue up the download invisibly in the background?
If it's visible, then maybe g-i-s needs informational text what and why GNOME Software is doing what it's doing? And then what about the interaction/sequencing with GNOME Tour?
We haven't seriously considered using gnome-software, no. Maybe you could propose a design for gnome-software instead?
I mean, the design would be that Software would install the packages in the background, as soon as it's able...
Advantages:
(This assumes a certain level of sophistication when it comes to the implementation, of course.)
Disadvantages:
Anything else?
I think I'd only want Software to install the packages if it could do so without the window popping up. I presume that this would be possible, since it already checks for and downloads updates in the background, but it would be good to have that confirmed.
OK, so looks like the action item here is to implement automatic online background installation of OpenH264 in GNOME Software. No design is required because the user should not know that it is happening.
We need to find somebody willing to implement this.
I think I would rather put it in gnome-initial-setup and avoid magically installing stuff in the background. In my opinion gnome-software is already too complicated and magical and this would just make the situation worse.
For what it's worth, I'd be interested in helping with the implementation if it's done through gnome-initial-setup. :)
Some of the reasons Allan suggested moving to GNOME Software, quoted from above:
Advantages: Software could wait for a network connection to install the packages Slow connections wouldn't be such an issue If something goes wrong, it would (theoretically) be better-positioned to show feedback Users could view download and install progress in the app
The first point is particularly persuasive. If you don't have a network connection when running gnome-initial-setup, then we've missed our chance to install the codec. Whereas with gnome-software, it doesn't matter: gnome-software can just try again later when network is available.
Alternative: I suppose we don't necessarily need to use either. We could add a new systemd unit that runs periodically to attempt to install the codec, and then disable itself once it succeeds. Sort of like how we currently have a systemd unit that enables the Fedora flatpak repo.
Metadata Update from @catanzaro: - Assignee reset - Issue untagged with: meeting
Yep, both ideas have their pros and cons. I think I would err on the side of making things explicit (so that the user feels in control and nothing goes and modifies the installed package set behind their back), but I can totally see the counter arguments.
Metadata Update from @kalev: - Issue assigned to ngompa - Issue tagged with: meeting
(Sorry, my comment somehow undid your metadata changes.)
Metadata Update from @kalev: - Assignee reset - Issue untagged with: meeting
I think I would err on the side of making things explicit (so that the user feels in control and nothing goes and modifies the installed package set behind their back),
If we want it to be explicit, then we need a design. And I think that would complicate this considerably, especially if it were to be done in Software.
So if you want to avoid doing this in Software, and Allan and I want to avoid Initial Setup, that suggests a new, very simple service would be a good place. OK?
Hm, maybe if the service was more generic, it could remove anaconda as well.
Yes, agreed that it would be nice to tackle removing anaconda at the same time.
Let's see what options we have:
1) gnome-initial-setup:
It could run after install in the first user mode and offer to do post-install installation steps / cleanup and remove anaconda and install openh264. Something like this sounds like it could work for Workstation. I am not sure how well it could work for Silverblue where a) anaconda does not install itself (so a generic "cleanup" g-i-s page doesn't work there), and b) gnome-initial-setup afaik never runs in first user mode because anaconda allows creating users there. (Correct me if I'm wrong here.)
I like this one because how linear it makes the installation: User starts the computer for the first time and all the cleanup tasks happen immediately, so they can afterwards go start using the computer. Also no issues here with conflicting with background updaters.
2) gnome-software
Could be the same as gnome-initial-setup, but offer to do the same thing post-install. Pros: maybe integrates better with Silverblue where gnome-initial-setup can be a bit problematic? gnome-software already got nice offline install integration that should make package removal safe. Cons: gnome-software is already huge and it would just complicate it even more. Maybe not the best workflow to prompt the user randomly if they want to remove packages / install new ones?
3) systemd service
Same as above, just without any UI. Open question: Should it do offline update? How to schedule that without UI? Or just remove anaconda and its deps online? How to avoid stepping on gnome-software toes when it's downloading updates at the same time?
4) anaconda itself
It could remove itself from the sysroot target and maybe install openh264 without prompting? Not sure it's a good idea as adding openh264 install there would considerably complicate the live install -- would have to access network there which is otherwise unnecessary.
1) gnome-initial-setup: It could run after install in the first user mode and offer to do post-install installation steps / cleanup and remove anaconda and install openh264. Something like this sounds like it could work for Workstation. I am not sure how well it could work for Silverblue where a) anaconda does not install itself (so a generic "cleanup" g-i-s page doesn't work there), and b) gnome-initial-setup afaik never runs in first user mode because anaconda allows creating users there. (Correct me if I'm wrong here.) I like this one because how linear it makes the installation: User starts the computer for the first time and all the cleanup tasks happen immediately, so they can afterwards go start using the computer. Also no issues here with conflicting with background updaters.
We've previously rejected this option because we want openh264 to be installed eventually even if the user does not have internet access when running gnome-initial-setup.
3) systemd service Same as above, just without any UI. Open question: Should it do offline update? How to schedule that without UI? Or just remove anaconda and its deps online? How to avoid stepping on gnome-software toes when it's downloading updates at the same time?
This seems like the simplest option to me, since it doesn't require new UI. Shouldn't GNOME Software notice and cancel/invalidate any prepared update if a package is installed? IMO GNOME Software is responsible for not stepping on its own toes, right?
4) anaconda itself It could remove itself from the sysroot target and maybe install openh264 without prompting? Not sure it's a good idea as adding openh264 install there would considerably complicate the live install -- would have to access network there which is otherwise unnecessary.
This has the same problem as (1) in that it won't work if the user does not have internet access when anaconda attempts to install openh264. But with options (2) or (3), we can keep retrying until it eventually works. So I recommend either (2) or (3).
I've seen ROSA Linux have Anaconda get autoremoved after installation, let me check to see how they do it...
Another thought, maybe removal could be done in a oneshot systemd service that runs offline (and before first login), so that we sidestep all of the issues with online removing it?
Perhaps it just complicates things further if we try to do openh264 install and anaconda removal from the same place.
Something like this (completely untested):
[Unit] Description=Remove Anaconda ConditionPathExists=/usr/bin/dnf ConditionPathExists=!/var/lib/dnf/.anaconda-removal-done [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/dnf remove -y anaconda ExecStartPost=/usr/bin/touch /var/lib/dnf/.anaconda-removal-done [Install] WantedBy=multi-user.target
That would probably work, though I'd probably put a ConditionPathExists on the anaconda binary itself too.
ConditionPathExists
Oh, and a check that we're not in a live environment.
Oh, good points. :) I'll play with it a bit tomorrow and see if I can get it to work right.
Do we have a good package to put such oneshot services in?
anaconda itself maybe?
For anaconda self-remove, it makes sense to have it in Anaconda.
And for the openh264?
Metadata Update from @catanzaro: - Issue untagged with: meeting - Issue assigned to kalev - Issue tagged with: pending-action
Someone in ROSA Linux wrote an Anaconda addon to trigger self-removal post-installation. @mikhailnov would probably know more about this.
12.04.2021 00:29, Neal Gompa пишет:
ngompa added a new comment to an issue you are following: Someone in ROSA Linux wrote [an Anaconda addon to trigger self-removal post-installation](https://github.com/Gel0bmstu/anaconda-packageremover). @mikhailnov would probably know more about this.
Someone in ROSA Linux wrote [an Anaconda addon to trigger self-removal post-installation](https://github.com/Gel0bmstu/anaconda-packageremover). @mikhailnov would probably know more about this.
ROSA uses rsync-based installation in Anaconda, not per-package one. This addon adds a spoke where packages from a pre-defined list can be chosen for removal after rsync-ing.
Anaconda is removed after rsync-ing by this script: https://abf.io/import/anaconda/blob/master/90-rosa1-postinstall.sh
Anaconda postinstall script sounds like a much cleaner way of doing it, compared to a systemd service. Thanks for the pointers, @mikhailnov!
BTW I believe we missed the dummy totem update required to pull in gstreamer1-plugin-openh264 for F34.
Thanks -- I kicked off a new totem build now.
@kalev - did this get done?
Metadata Update from @aday: - Issue set to the milestone: Fedora 35 (was: Fedora 34)
No, we still have no way to automatically install OpenH264. Sounds like Kalev's last comment indicates that he wants to use an anaconda postinstall script. Thinking about that now, I'm skeptical that will actually work, because if there's no internet available during installation, we still need to ensure OpenH264 gets installed the next time internet is available. So I suspect it really needs to be a systemd service.
Setting the meeting label, so we can talk about this in the future, if we need to come up with a consensus.
Metadata Update from @aday: - Issue tagged with: meeting
This was discussed at yesterday's WG meeting.
The plan is to use a one-shot systemd service to install openh264. This can use conditions to only run if there's network and if openh264 is not already installed (to be determined by the existence of a file provided by the openh264 package).
The previously discussed Anaconda post-install removal is to be treated separately - see #242.
Metadata Update from @aday: - Issue untagged with: meeting
(to be determined by the existence of a file provided by the openh264 package)
Technically, we're installing two different packages: mozilla-openh264 and gstreamer1-plugin-openh264. This doesn't change much, though. I guess we might not want to install mozilla-openh264 if Firefox is not installed.
I did some testing of an approach to do this, and found out it's not working as expected anymore. I filed RH#1997616 to ask the DNF team to look into fixing this.
Assuming that this isn't going to happen for F35 - moving to F36.
Metadata Update from @aday: - Issue set to the milestone: Fedora 36 (was: Fedora 35)
Metadata Update from @chrismurphy: - Issue set to the milestone: Fedora 37 (was: Fedora 36)
As per the discussion at this week's WG meeting, changing the assignee to @ngompa.
Metadata Update from @aday: - Assignee reset
First pass for this in Firefox: https://src.fedoraproject.org/rpms/firefox/pull-request/41
This did not receive amazingly favorable reviews.
IMO we should just go with the one-shot systemd service that we previously discussed. It's still needed to install gstreamer1-plugin-openh264 anyway, since that cannot be installed by any one particular app like mozilla-openh264 can.
We touched on this issue during yesterday's WG meeting. @ngompa is still planning on work on it for F37, as far as we're aware.
Metadata Update from @aday: - Issue assigned to ngompa
We discussed this today. @ngompa is working on it - still hoping to fix for F37.
Guys, is https://bugzilla.redhat.com/show_bug.cgi?id=2121959 related? Clean Fedora 36 install is missing mozilla-openh264 so Firefox won't play H.264 content. Thanks.
Yup, responded there.
Bad news, Martin reports that the Recommends is no longer enough to cause mozilla-openh264 to be installed automatically. My guess is it broke due to https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect. I wonder if users are just out of luck currently unless they install the package manually?
So I've made fedora-autofirstboot, which has a script for OpenH264: https://pagure.io/fedora-autofirstboot/blob/main/f/libexec/fedora-autofirstboot/scripts.d/install-openh264.sh
fedora-autofirstboot
Will this be sufficient to fix this?
I think so!
Package is now submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2022-32fad23e6a
So remaining tasks are: add to comps, then test a fresh install to ensure that it works?
Service needs to be added to fedora-release preset too.
Well we forgot to add this to comps and fedora-release, and I guess it's pretty late to do that for F37. But we can surely do it now for F38. Neal, want to submit some PRs?
Yeah, I'll do that soon. I'm currently working on my Akademy presentation stuff right now...
It seems that this didn't make it for F37. Let's try for F38.
Metadata Update from @aday: - Issue set to the milestone: Fedora 38 (was: Fedora 37)
We discussed this issue today, and it seems that the plan is to cover it in the same change proposal as for #242 . Once that's done we can include it in F38.
Change proposal submitted: https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
Metadata Update from @aday: - Issue set to the milestone: Fedora 39 (was: Fedora 38)
We discussed this issue at this week's working group meeting (27 June 2023). @ngompa intends to withdraw his autofirstbootservices proposal, due to several insurmountable technical issues.
The alternative we discussed is for gnome-software to install OpenH264, since it is able to wait for the network to come up, and is expected to always run on Workstation systems. Do you think that would be possible, @mcrha ?
Metadata Update from @aday: - Assignee reset - Issue untagged with: pending-action
The gnome-software contains a plugin, which auto-installs langpack packages based on the system locale (or some such thing).
Auto-installing a random package doesn't sound like a task for the gnome-software. I'm also unsure whether the upstream would agree on such change.
Why not add it as a default package being installed for the Fedora Workstation? That feels like the best, and the right, fit for your needs. Unless I misunderstood something.
The OpenH264 codecs cannot be distributed by Fedora and has to be installed from Cisco's servers. This means that they can't be part of Fedora's installation images.
We can write a new component to do this. But Software seems like the nicest place to me, since you can display it in the user interface and present an error message to the user if something goes wrong. Also, putting new functionality into existing packages is nicer than adding new packages. We have enough packages in Fedora already.
I don't see why it wouldn't be accepted upstream since (a) it's generally-useful for all distros that respect US law and wish to support H.264, (b) you're one of the upstream maintainers, and (c) the other upstream maintainer works for Endless, which also relies heavily on OpenH264, although they do so only via the Flatpak extension they developed.
(b) you're one of the upstream maintainers
while the above being mostly true (I'm not the "full" maintainer), I'm not the decision maker there. The best will be to open a bug in the upstream and see what the reaction will be. I can work on it once it's clear what can and cannot be done.
With respect of "each distro might benefit from it", the only downside is that each distro has its own way to install it, which makes such a general plugin kinda less general. At least from my point of view.
[…] Endless, which also relies heavily on OpenH264, although they do so only via the Flatpak extension they developed
For what it's worth, here is how Endless OS arranges for the Flatpak extension to be auto-installed:
Both of these are standard behaviours, upstream. There is nothing special for the OpenH.264 extension. This is believed to work well enough! But it does mean that it is a bit non-deterministic when this actually happens.
(We used to arrange to put the binary from the Flatpak extension into the host's library path. This worked but we realised nothing in the host system used it so we removed it.)
The situation is different for us, as we would want both the host and Flatpaks to be able to use it.
We used to have the same situation. Here is how we achieved it:
/run/lib/openh264
ldconfig
Metadata Update from @aday: - Issue set to the milestone: None (was: Fedora 39)
Wow, this issue's fifth birthday is next month.
We discussed this at yesterday's meeting and Kalev presented 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. Finally a solution is in sight. :)
Metadata Update from @catanzaro: - Issue assigned to kalev - Issue tagged with: pending-action
@kalev can you provide a status update here, please? I see noopenh264 has been packaged, and I also see that the openh264 package obsoletes it. So, are we done here?
Almost - noopenh264 is packaged and ready, but is not shipped in rawhide (or any other branches) yet: before we can ship it in a user facing repository, we need to first put new openh264 build in place in the Cisco repository that obsoletes noopenh264. Shipping the new openh264 build is tracked in https://pagure.io/releng/issue/11823 - everything is waiting on it. (We've had some back channel emails back and forth and this is hopefully not as stuck as it seems when looking at the releng issue ticket.)
So we have the new openh264 in F40 now. (Not yet in stable releases, as openh264 updates are very risky and we don't yet know whether it works or not.)
@kalev how about we add noopenh264 to the workstation-product comps group? That's probably needed, right?
Then once that's done, we should be able to install the F40 Workstation live image, run dnf update, and noopenh264 should get replaced by the real openh264. Yes?
dnf update
Please don't add anything to workstation-product. Use multimedia instead.
(Sidebar: we need to figure out if the workstation-product group makes sense anymore, the differences between it and standard are very low...)
Yep, it should be all in place for F40 now: noopenh264 is now available in rawhide koji build roots, and there is a new openh264 version in Cisco F40 repositories that obsoletes noopenh264 on first update.
I asked releng to hold off updating openh264 in stable Fedora releases for now so that we can get some feedback in rawhide first, but things are in place on Cisco's CDN to do that if (or when) we want to.
No, no need to do that - it's going to be pulled in through dependencies, as is usual for libraries. ffmpeg already has Recommends that pull it in.
Yes, correct - except that it should already work now. I just checked build logs and "noopenh264" was pulled in for all of Workstation iso images from last night. I think we are all good here :)
Next step would be to add the gstreamer openh264 plugin to Fedora proper, which would be another way that noopenh264 is going to get pulled in to the default install.
OK, sounds good.
There is one downside: if gstreamer-openh264 is installed, but the real openh264 is not, then the plugin will be broken. That's probably OK, I suppose.
Yes, but hopefully not any more broken than not having the plugin at all. The gstreamer plugin detects at runtime that it's using the stub noopenh264 library and disables itself automatically. As soon as we get noopenh264 swapped out with openh264, it should start working again.
Otherwise, what's the point of all this - we get the library automatically installed, but not the gstreamer plugin?
This plan sounds good.
So this means we would remove the GStreamer plugin from our openh264 package, and package it in a separate source package. Should be straightforward.
Yes, almost - that was my original plan (and I already got it through the package review with Neal's help as a reviewer), but then our gstreamer1-plugins-bad maintainer noticed this and asked if we could build it as part of gstreamer1-plugins-bad instead, which of course makes sense. So the new plan is to build it as part of gstreamer1-plugins-bad-free, but keep the same binary rpm name that it had when it was built out of openh264 source rpm: "gstreamer1-plugin-openh264". This should make the upgrade path straightforward and make it easy to roll this back if needed.
Separate gstreamer1-plugin-openh264 source package is probably still needed if we want to build this for EPEL 9 though, and maybe also for the F39-based flatpak runtime if we don't want to change how we ship openh264 stuff for regular F39 rpm users.
That is a better plan. It should certainly be part of gstreamer1-plugins-bad-free now that noopenh264 exists.
For what it's worth, I've a rawhide machine which I keep up-to-date by "continuous" updates (just updating the system from time to time). When I tried to update it today, I've got this error:
Problem: package gstreamer1-plugin-openh264-1.22.9-3.fc40.x86_64 from fedora requires libopenh264.so.7()(64bit), but none of the providers can be installed - package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from fedora conflicts with openh264 provided by openh264-2.1.1-2.fc35.x86_64 from @System - package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from rawhide conflicts with openh264 provided by openh264-2.1.1-2.fc35.x86_64 from @System - cannot install the best update candidate for package gstreamer1-plugin-openh264-1.18.2-1.fc35.x86_64 - problem with installed package openh264-2.1.1-2.fc35.x86_64
Yeah, the openh264 is from f35 for whatever reason, the same as the gstreamer1-plugin-openh264. As I said, I keep the machine up-to-date. Why these two are so much behind I do not know. My other machine has no openh package (rpm -qa | grep openh returns nothing).
openh264
f35
gstreamer1-plugin-openh264
openh
rpm -qa | grep openh
I'll left up to you whether it's a problem or not, or whether you'll want to address it or not.
This looks like an issue caused by locally disabled fedora-cisco-openh264 repository: New openh264 package that has obsoletes for noopenh264 isn't available in any enabled repository and things start conflicting.
I think update issues like this are a good reason why we shouldn't backport this work to stable Fedora releases and only keep it for Fedora 40 and later - users can probably deal with issues like this during distro upgrades, but it would be unexpected to suddenly get an update issue caused by disabled fedora-cisco-openh264 repository in a stable Fedora release.
@mcrha I wonder if this is something that gnome-software could help with and check and warn if the fedora-cisco-openh264 repository is disabled for upgrades to F40 and later and maybe allow enabling it in an easy way at the same time? Or maybe just silently enable it for all F40+ distro upgrades without user interaction? It's not really an optional repository any more at this point.
You are right, that repository had been disabled here. I enabled it, but it did not help:
# dnf update --refresh Fedora rawhide - x86_64 52 kB/s | 11 kB 00:00 Fedora rawhide - x86_64 1.1 MB/s | 445 kB 00:00 Fedora rawhide openh264 (From Cisco) - x86_64 126 B/s | 123 B 00:00 Fedora - Rawhide - Developmental packages for the next Fedora release 148 kB/s | 11 kB 00:00 Fedora - Rawhide - Developmental packages for the next Fedora release 1.1 MB/s | 445 kB 00:00 google-chrome 19 kB/s | 1.3 kB 00:00 Dependencies resolved. Problem: package gstreamer1-plugin-openh264-1.22.9-3.fc40.x86_64 from fedora requires libopenh264.so.7()(64bit), but none of the providers can be installed - package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from fedora conflicts with openh264 provided by openh264-2.1.1-2.fc35.x86_64 from @System - package noopenh264-0.1.0~openh264_2.4.0-1.fc40.x86_64 from rawhide conflicts with openh264 provided by openh264-2.1.1-2.fc35.x86_64 from @System - cannot install the best update candidate for package gstreamer1-plugin-openh264-1.18.2-1.fc35.x86_64 - problem with installed package openh264-2.1.1-2.fc35.x86_64
the cisco repo file contains: metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch
Ohhh, sorry, I missed that it's rawhide and not f40. The rawhide cisco repository is sadly empty after f40 branching :( It needs https://pagure.io/releng/issue/11955 before it gets back to working.
In the mean time, this can be worked around by doing dnf update --releasever=40 --disablerepo='*' --enablerepo='*cisco*' to get the packages from the F40 repo.
dnf update --releasever=40 --disablerepo='*' --enablerepo='*cisco*'
I see, that explains it. Using the f40 repo does fix the problem flawlessly. Thank you.
For the gnome-software auto-enable, I do not think it can be done. One needs root access to modify the file (directly or through the PackageKit), thus it could ask for the admin password in some unexpected time, which is a bad thing to do.
Ah true. I guess asking the user is the only option then - it wouldn't be unexpected to pop up a polkit dialog in that case.
I've tested this on a fresh install of Fedora KDE and it works perfectly. It should work for Workstation as well. (Please reopen if not, but I'm confident.)
Good job resolving this 5 year old issue, Kalev!
Metadata Update from @catanzaro: - Issue untagged with: pending-action
Actually wait, I may have closed this prematurely. There are actually three packages that we want to see installed:
We still need a solution for mozilla-openh264, so reopening. I remember talking to Kalev about this. I think we have to move mozilla-openh264 into Fedora proper and have it build against noopenh264, right?
Yes, that's the remaining thing left to fix.
Login to comment on this ticket.