Now that we've reached the branch point, it's time to start doing
weekly blocker summaries again! Beta freeze begins on 22 February and
the current target Beta release date is 15 March.
1. anaconda — When running anaconda on Wayland with two keyboard
layouts configured, hitting any modifier key with the second layout
selected switches to the first layout — ASSIGNED
ACTION: Maintainers to diagnose issue
2. distribution — Fedora 36 backgrounds not present on
release-blocking desktops (GNOME, KDE) — NEW
ACTION: Maintainers to update background packages
3. fedora-release — fedora-release-identity-cloud says "Cloud
Edition", Cloud has not been an edition for years — NEW
ACTION: Maintainers to update fedora-release-identity-cloud or
group-with-such-authority to waive this.
4. kwin — openQA clicks in anaconda on KDE stop working shortly after
it starts — NEW
ACTION: Maintainers to diagnose issue
5. libinput — GNOME doesn't accept input from wireless keyboard if
there's not another "keyboard" input available — NEW
ACTION: Maintainers to diagnose issue
6. linux-firmware — Fedora 36: Server boot x86_64 image exceeds
maximum size — ASSIGNED
1. distribution — Some variants are missing /etc/resolv.conf symlink
(use systemd-resolved) — POST
ACTION: QA to verify issue is resolved
2. dnf — exclude_from_weak_autodetect=true effectively renders rich
weak dependencies useless — NEW
ACTION: dnf maintainers to decide on approach for "instally only newly
recommended packages" proposal
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2016613 — ASSIGNED
When running anaconda on Wayland with two keyboard layouts configured,
hitting any modifier key with the second layout selected switches to
the first layout
adamwill's research shows that this bug has existed since F25, but
became more viisble after KDE switched to Wayland by default. This bug
was deferred to F36 Beta under the "too hard to fix" exception.
There's ongoing discussion trying to come up with a potential fix,
however we still seem to be a long way from that point.
2. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2052654 — NEW
Fedora 36 backgrounds not present on release-blocking desktops (GNOME, KDE)
The usual desktop background blocker.
3. fedora-release — https://bugzilla.redhat.com/show_bug.cgi?id=2018271 — NEW
fedora-release-identity-cloud says "Cloud Edition", Cloud has not been
an edition for years
Waived from F35 final under the "late blocker exception." Cloud WG is
working on a proposal to re-promote Cloud to Edition status, but that
will not happen for F36 release cycle.
4. kwin — https://bugzilla.redhat.com/show_bug.cgi?id=2047503 — NEW
openQA clicks in anaconda on KDE stop working shortly after it starts
Shortly after the installer starts, mouse clicks in openQA stop
working. Using 'development mode' which allows for manual interaction
still works. This bug only affects KDE, and appears to have been
introduced in the KDE Plasma 5.24 pre-release on 2022-01-19. This bug
is accepted under the "hinders execution of required Beta test plans"
5. libinput — https://bugzilla.redhat.com/show_bug.cgi?id=2017043 — NEW
GNOME doesn't accept input from wireless keyboard if there's not
another "keyboard" input available
On some hardware, devices with multiple capabilities that include
keyboard do not get registered as a keyboard. Thus they only work if
another keyboard is connected. It seems to mostly (or exclusively)
affect some ARM hardware.
6. linux-firmware —
https://bugzilla.redhat.com/show_bug.cgi?id=2031214 — ASSIGNED
Fedora 36: Server boot x86_64 image exceeds maximum size
Fedora-Server-netinst-x86_64-36-20220210.n.0.iso is 731906048 bytes,
which is below the maximum size of 734003200. This bug can probably be
closed until the image exceeds the limit again.
1. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=2032085 — POST
Some variants are missing /etc/resolv.conf symlink (use systemd-resolved)
Some variants are not using systemd-resolved as intended. With some
recently-merged changes to Anaconda, this appears to be working
2. dnf — https://bugzilla.redhat.com/show_bug.cgi?id=2033130 — NEW
exclude_from_weak_autodetect=true effectively renders rich weak
Behavior introduced by the "Enable exclude_from_weak_autodetect by
default in LIBDNF" System-Wide Change appear to have undesired effects
in some use cases, particularly with language packs. It appears that a
robust fix is technically difficult, and the Change owners are
discussing reverting this Change for F36 (see BZ 2013327).
He / Him / His
Fedora Program Manager
Hi folks! So I've had this action item at meetings forever now:
"adamw to try and clarify intent of "default application functionality"
criterion regarding arches"
That's referring to
, which kinda reads at first glance like it's excluding Workstation
aarch64, but that isn't the intent. The intent is that we require the
specific list of application types to work on all release-blocking
desktops and arches, including Workstation aarch64. Beyond that, we
require *all* installed apps to work on Workstation x86_64.
I think it'd be clearer if we write the criterion in the same order as
my explanation above. So I propose we revise it to:
For all release-blocking desktop / arch combinations, the following
applications must start successfully and withstand a basic
* web browser
* file manager
* package manager
* image viewer
* document viewer
* text editor
* archive manager
* terminal emulator
* problem reporter
* help viewer
* system settings
If there are multiple applications of the same type (e.g. several web
browsers), the primary/default one must satisfy the requirements. If
the primary/default application can't be determined, at least one of
said applications must satisfy the requirements.
Additionally, for Fedora Workstation on the x86_64 architecture,
'''all''' applications installed by default must meet this requirement.
Thoughts? Is this an improvement? Anyone have a better idea? Thanks!
IRC: adamw | Twitter: adamw_ha
Summary: Firefox cannot tolerate being downgraded a major version, the
behavior gets all whacky. Note, the problem does not occur with new
clean installs (unless you preserve /home), just upgrades.
Since the ensuing behavior is indistinguishable from buggy behavior,
we should have a release criterion ensuring Fedora beta and final ship
a version of Firefox equal to or newer than what's available in the
two current releases. I think even if it is "a beta" this is way too
much horkage to subject beta testers to. They are expecting bugs, but
this is not a bug, it's a bad procedure to compel users (without a way
to opt out) to downgrade and in effect get a busted web browser
experience on upgrade.
ship FF 97 in Fedora beta
ship FF 99 in Fedora final
There is a "Default application functionality" final release
criterion, it requires a basic functionality test, and includes the
web browser. It surely applies here, because the browser is broken for
many web sites. As for beta, well it's a beta.
(It's the best contrary argument I could make. I think the "it's a
beta! weee!" is not compelling. Plus, it's significantly incompatible
with the catch all beta criterion "Bug hinders execution of required
Beta test plans or dramatically reduces test coverage" because we just
get a bunch of bogus "it's broken" reports from unwitting users who
upgrade at beta, ostensibly to test, and then get bitten by this.)
A. Release-blocking desktops must ship a version of Firefox [default
web browser] equal to, or newer than, the version available with both
current Fedora releases.
B. Release-blocking desktops must ship a version of Firefox [default
web browser] that avoids it being downgraded when performing a system
So at this week's blocker review meeting, the fact that we don't have
explicit networking requirements in the release criteria really started
to bite us. In the past we have squeezed networking-related issues in
under other criteria, but for some issues that's really difficult,
notably VPN issues. So, we agreed we should draft some explicit
This turns out to be a big area and quite hard to cover (who'd've
thought!), but here is at least a first draft for us to start from. My
proposal would be to add this to the Basic criteria. I have left out
some wikitext stuff from the proposal for clarity; I'd add it back in
on actually applying the proposed changes. It's just formatting stuff,
nothing that'd change the meaning. Anyone have thoughts, complaints,
alternative approaches, supplements? Thanks!
=== Network requirements ===
Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).
==== Basic networking ====
It must be possible to establish both IPv4 and IPv6 network connections
using DHCP and static addressing. The default network configuration
tools for the console and for release-blocking desktops must work well
enough to allow typical network connection configuration operations
without major workarounds. Standard network functions such as address
resolution and connections with common protocols such as ping, HTTP and
ssh must work as expected.
Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking
==== VPN connections ====
Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VNC servers with typical configurations.
Footnote title "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net