FinalBlocker +1

I don't think the cited criteria makes this a certain blocker in this case as the "default graphical package manager" isnt faulty 100% of the time for all geolocations.

The criteria also states " There may be times where a requirement is unmet only in a particular configuration, such as with some keyboard layouts but not others, or if a particular character is used in a username, password or passphrase. In such cases, the release team should use their judgement and refer to precedent to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by the issue, the severity of the case when the issue is encountered, and the ease or otherwise with which the issue can be avoided by both informed and uninformed users."

I cannot speak to the number of users but from what I've read the two big countries blocked are Ukraine & Russia would could translate to large number of users. On the other hand, the issue is easily avoided with a quick --skip-unavailable or by disabling the repo.

I'm on the fence about this so I'm going to hold my vote until tomorrow's meeting/discussion

On the other half, the issue is easily avoided with a quick --skip-unavailable or by disabling the repo.

@boniboyblue It's worth mentioning that this issue also makes installing Fedora Everything impossible, according to some users.

[Deleted]

Deleted due to wrong information.

Incidentally, trying to skip unavailable packages doesn't help. See this comment by Neal: https://discussion.fedoraproject.org/t/ciscobinary-openh264-org-is-unreachable-in-some-countries-ru-ua-ir/161434/20

FinalBlocker -1

I'll try and add my rationale to the bug, but I don't think disabling this for everyone is worth the rest not having it.

FinalBlocker +1

The impact here is too widespread.

I would prefer that repo fedora-cisco-openh264 is disabled by default instead of failing updates during installation or later, or even failed manual or kickstart installations.
If the problem is listed in common-bugs, for example, then I can enable the repo later if I need the package, but I have a stable running system without manual interaction. If a problem occurs with this repo, then I will remember that I have enabled it a (probably) short time ago, and can accordingly act.

FinalBlocker +1

I would really be happier if this was handled with the "enable third party repos" option instead of default enabled.

As it stands, I feel like it has to be a blocker, it sounds like both updates and installing from a Fedora Everything ISO are broken in the affected regions.

FinalBlocker +1

FinalBlocker +1

The US sanctions list should apply to Red Hat and Cisco the same way, so we probably only need to consider regions which are currently blocked but shouldn't be. From the upstream cisco ticket, that seems to include non-occupied parts of Ukraine. Does it also include anything else?

If this happens only in sanctioned countries or places, then there's nothing fedora can do about it.

Russia is not listed at under our export control policy. Possibly it should be? But it's not.

CC @jspaleta since he had expressed interest in talking to Cisco.

We had to remove the cisco repo from the rpmfusion koji instance due to the poor reliability, it was 404 many times per week.

A few notes:

This issue/ticket is for voting on blocker or not. Perhaps we could move the discussion to the bug?

The contents of the policy are beyond our scope here.

cisco used to have a home grown CDN, but moved a while back to a aws based (cloudfront/s3) thing, that is when this issue appeared. But aside the blocking in some regions I think it's a great deal more reliable, perhaps the 404's were before that (the old CDN wasn't so reliable).

A few notes:

This issue/ticket is for voting on blocker or not. Perhaps we could move the discussion to the bug?

Yeah, I agree to keep the core discussion in the bug itself, as not everyone interested would be following the blocker-review ticket.

The contents of the policy are beyond our scope here.

cisco used to have a home grown CDN, but moved a while back to a aws based (cloudfront/s3) thing, that is when this issue appeared. But aside the blocking in some regions I think it's a great deal more reliable, perhaps the 404's were before that (the old CDN wasn't so reliable).

Given what you say, not sure if Fedora can do anything here.

I'll go with Kevin's rationale here:

FinalBlocker -1

I think we're starting to lose the thread here... A temperamental third-party repository can make updating or even installing Fedora Linux impossible. This shouldn't be a thing.

It's also worth noting that pretty much nobody outside the US needs or wants OpenH264, so "the rest not having it" is highly unlikely to be consequential.

I think we're starting to lose the thread here... A temperamental third-party repository can make updating or even installing Fedora Linux impossible. This shouldn't be a thing.

I agree.

It's also worth noting that pretty much nobody outside the US needs or wants OpenH264, so "the rest not having it" is highly unlikely to be consequential.

Sorry, this is wrong. As far as I see, at least all users of WebEx using Firefox for the video conference session need the OpenH264-Videocodec in the web browser. It provides WebRTC required by WebEx. So it is required for us.

@imsedgar Oops... So it's not handled by the browser itself? From the "OpenH264 Video Codec provided by Cisco Systems, Inc." plugin entry:

This plugin is automatically installed by Mozilla to comply with the WebRTC specification and to enable WebRTC calls with devices that require the H.264 video codec.

AGREED RejectedFinalBlocker

Discussed at the 2025-09-22 (blocker / freeze exception) review meeting:

We agree that this is a very awkward state for folks in affected locations. However, as there is no entirely Fedora-controlled "fix" possible and the issue is not entirely limited to Fedora 43, we have decided it doesn't make sense to block on it. We will wait for Cisco to complete the process of refining their geoblock, then see where we stand and if we need to consider any changes on the Fedora side.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-22/f43-blocker-review.2025-09-22-16.01.txt

The following votes have been closed:

• Rejected FinalBlocker (+5, 0, -2)
  • +1 by leigh123linux, catanzaro, imsedgar, nielsenb, lruzicka
  • -1 by kevin, kashyapc

Two more questions:

1. Are there any plans to fix librepo, at least? Ideally, by F43.

2. Since Fedora makes an exception by enabling a third-party repository with not-exactly-free software by default, why not do the same for, say, Nvidia drivers and Steam? I'm pretty sure the latter two are way more important for most users than a certain codec.

Two more questions:

1. Are there any plans to fix librepo, at least? Ideally, by F43.

2. Since Fedora makes an exception by enabling a third-party repository with not-exactly-free software by default, why not do the same for, say, Nvidia drivers and Steam? I'm pretty sure the latter two are way more important for most users than a certain codec.

That is outside the remit of a blocker bug proposal. I would recommend moving this conversation to the bug report in rhbz or the Fedora Discussion Forums.

Release F43 is no longer tracked by BlockerBugs, closing this ticket.