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
Hey folks! While we're working through fixing this up, I wanted to send
out a note about what's going on.
tl;dr summary: GNOME is broken in Rawhide, and blueberry (Cinnamon's
bluetooth app) may have dep issues temporarily. If you need GNOME to
work, downgrade gnome-shell and mutter. Otherwise, apologies for the
rough ride, hold onto your hats, we're trying to get things fixed up.
Full version: gnome-shell and mutter 42~beta builds were run yesterday.
For Fedora 36 they were done in a sidetag, but for Rawhide, no sidetag
yet existed, so unfortunately they went straight to the main Rawhide
tag and were included in yesterday's compose.
It turns out having those packages at 42~beta but older versions of
other packages gives you a broken GNOME; anyone who updated to Rawhide
yesterday will likely see GNOME crash to the "Oh no!" screen on boot.
To deal with that for now, the best thing to do is to downgrade gnome-
shell and mutter back to the previous builds from Koji.
Since the builds have been in a compose, we can't untag them from
Rawhide, we can only move forwards. So we're trying to build enough of
the rest of GNOME 42~beta to get things working again, but it turns out
quite a lot of stuff needs to be built for that.
A particular pain point is gnome-bluetooth. gnome-shell 42~beta needs
gnome-bluetooth 42, but the new gnome-bluetooth changes the library
API. We noticed that Cinnamon's bluetooth app, blueberry, is built
against the old gnome-bluetooth API, and there are no patches upstream
to handle this.
That left us in an awkward spot. Ideally what should happen is the
gnome-bluetooth soname bump would be announced and Leigh would have a
week to figure out what to do for blueberry/cinnamon. But if we do that
now, GNOME would be broken for a week in Rawhide, which is not ideal.
The solution we decided on is to bump gnome-bluetooth to 42~beta, but
add a gnome-bluetooth3.34 compat package, which should keep blueberry
working until Cinnamon folks can come up with a plan. David King
submitted the package, and I reviewed it:
and it should be built soon. blueberry will need to be rebuilt with its
deps changed a bit, but that should be all. It would be ideal if Leigh
could take over maintenance of this package as long as it's needed.
As things stand right now, gnome-bluetooth 42~beta is built for Rawhide
but gnome-bluetooth3.34 is not yet; depending on exactly when we get it
built it may just miss today's compose, meaning Cinnamon image compose
would be broken for that day, and updates of Rawhide Cinnamon systems
to that day's packages would likely have issues. Most of the other
packages we think we need to build to make GNOME work again are done,
but gnome-control-center is proving tricky; I got some work done
towards getting it to build, but wasn't able to get it all the way, so
I've left a couple of PRs:
and David is going to pick it up and move forward. I'll check back in
in the morning.
Thanks folks, and sorry again for the trouble!
IRC: adamw | Twitter: adamw_ha