#84 Automatically install the OpenH264 codecs
Opened 2 years ago by rishi. Modified 4 days ago

This is about the following two packages coming from the fedora-cisco-openh264 on Fedora 29:

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.

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.

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.

(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?

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.

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, I know. :) Surely we must have patched out the H.264 codec from the Fedora RPM?

Yes, AFAIK Fedora firefox build doesn't include the ffmpeg code and needs compat-ffmpeg28 from rpmfusion installed to be able to play youtube.

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.

Nope, YouTube works out-of-the-box for me with Fedora's Firefox.
I certainly haven't installed anything extra.

That's because Google transcoded most (all?) YouTube videos to WebM.

@uraeus, could you provide a status update on this, please?

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.

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

2 years ago

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:

  • @kalev or @uraeus to ensure the PackageKit GStreamer codec installer can propose and install OpenH.264 plugin when playing an MP4 video in totem
  • @uraeus to confirm that Fedora Legal is ok with the proposal

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.

Does this relate?
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/message/GDOFPFQKWJF5CRU7BNWNTJ756AIZOMYK/

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:

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:

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:

  • It installed gstreamer1-plugin-openh264-1.15.1-1.fc31, which is the old version that doesn't support MP4 playback. So it doesn't work yet. Do I need to wait a day or two before the new version becomes available?
  • In our last meeting, the full WG was not satisfied that we're allowed to do this. We still need confirmation from @uraeus that this received legal approval:

@uraeus, we really need you to comment here and confirm, or this won't move forward.

(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.

The audio works just fine for me here with your test file.

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:

  • @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

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

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

a year ago

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.

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.

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.

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. :)

Crashes and and other bugs seem a bit unrelated to this issue.

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.

Indeed, it seems that there are 3/4 issues being discussed in this ticket, which is making it quite difficult to follow.

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.

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.

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

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

As long as the codec installer is working, I don't see any problems with the current solution.

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 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.

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

a year ago

From Taiga, there are two items we can discuss at the next meeting that do not depend on @uraeus

  • Making it easier to install the h264 codecs, or installing them automatically
  • Figuring out a technical solution for h264 with Firefox

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:

  • Have code in gnome-initial-setup trigger installation
  • Have code in gnome-software trigger installation the first time it runs
  • 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)
  • Just don't automatically install it, instead expect the codec installer to work properly

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

a year ago

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:

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.

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:

  • It makes it available for offline usage - so you don't find that you're missing the codec you need at a point when you can't install it.
  • It means that users don't have to go through the rigmarole of the "automatic" GStreamer process. (App tries to play a file, fails, shows an error dialog. Do you want to search for the missing codec? Yes. Software opens up, takes an age while it searches, then you have to click on potentially multiple search results, wait for them to be installed, and then finally go back to the media app, and somehow restart playback. This is really annoying when you're poised ready to watch something.)

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?

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

a year ago

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

a year ago

Thanks for all the work on this, everybody!

Metadata Update from @catanzaro:
- Issue untagged with: meeting

a year ago

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)

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?

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

Makes sense. Recommends it is!

I went ahead and did this in totem-3.34.1-4.fc32 in https://bodhi.fedoraproject.org/updates/FEDORA-2020-c50d5f6c6f

Metadata Update from @catanzaro:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

11 months ago

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)

9 months ago

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

9 months ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

9 months ago

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.

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.

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...

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

8 months ago

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.

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.

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

6 months ago

There is also a mozilla-openh264 subpackage that also needs to be installed somehow.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

5 months ago

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

5 months ago

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.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

5 months ago

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?

Metadata Update from @catanzaro:
- Issue untagged with: meeting

4 months ago

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:

  • 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

(This assumes a certain level of sophistication when it comes to the implementation, of course.)

Disadvantages:

  • Could potentially delay installation of the codecs

Anything else?

Would GNOME Software visibly launch? Or can it just queue up the download invisibly in the background?

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.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

3 months ago

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

2 months ago

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

2 months ago

(Sorry, my comment somehow undid your metadata changes.)

Metadata Update from @kalev:
- Assignee reset
- Issue untagged with: meeting

2 months ago

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.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

2 months ago

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.

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.

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue assigned to kalev
- Issue tagged with: pending-action

10 days ago

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.

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!

Login to comment on this ticket.

Metadata