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
I'm looking to see what it would take to add plasma mobile to epel8-next,
but I have one major problem.
There is no list of packages, anywhere.
At least not that I can find. Not in Fedora, nor in the plasma mobile site.
Please. I think I've been patient enough. Take some time today, write
them down, reply back to this email.
I'll even put them in the comps.xml file to finish this ticket.
Please be advised that an OpenEXR side-tag update  is on its way for
F35 (there was an older update that has been unpushed because the
side-tag it's expired during the beta freeze).
I tried to rebuild kf5-kimageformats in the side-tag before realizing
that it is being updated in a kf5 side-tag itself... so, before pushing
the kf5 side-tag into an update, please look if the OpenEXR update has
already been pushed to stable or if a buildroot override is needed to
build kf5-kimageformats against the newer OpenEXR.
Yesterday I upgraded two x86_64 boxes from F33 to F34, using the dnf
plugin. Both systems had undergone similar one-version upgrades in the
past, and this one appeared to go smoothly.
Immediately after this upgrade the kde launcher was almost unusable,
offering the same random-ish targets for all categories, and with a
different menu on successive attempts.
Fortunately, on the machine that I left running, the problem seems to
have gone away. It seemed to affect both X11 and Wayland.
I have just rebooted the other machine and at present the problem is
Since updating to kwin-x11-5.22.4-1.fc34.x86_64 yesterday, the "expand
vertically" function on the title bar controls (usually tied to the
middle mouse button) has stopped working.
The configuration panel is still the same and still set correctly.
In Fedora 34 I am not able to autostart dropbox in KDE. I have tried with systemd with the following dropbox.service file put in .config/systemd/user:
Description=Dropbox as a user service
It works with systemctl --user start dropbox but if I enable the service with systemctl --user enable dropbox, after login the service is dead. What am I missing? Thanks, Enrique.
Thanks to all who responded.
I see that I neglected to specify the Fedora Version. It's FC36.
I am starting /bin/startplasma-x11 I have no idea what the "secret code word is for this". The "Leave menu" contains no save option even if the "Desktop Session" has "restore a manually saved session". This is still disabled?
plasma-workspace-x11-5.22.4-6.fc36.x86_64 : Xorg support for Plasma
Repo : @System
Filename : /usr/bin/startplasma-x11
plasma-workspace-x11-5.22.5-2.fc36.x86_64 : Xorg support for Plasma
Repo : rawhide
Filename : /usr/bin/startplasma-x11