cross-posting test@ and desktop@
Fedora Workstation 32 (upgraded from f31)
Laptop on battery power set aside, 12 hours later it's dead instead of
sleeping. On F31 it reliably would sleep after 20 minutes.
Sleep still happens when pressing the power button and closing the
lid. It seems to be a GNOME automatic suspend timer problem.
Using dconf editor, I changed the
Custom value 30 and the problem doesn't happen. Is there a way to
increase debug messages somehow to find out whether this timeout is
being reached? And what process or policy is causing it to be reset?
With the available information I can't figure out what's preventing
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
For anyone who hasn't seen it yet - there's quite a kerfuffle today
about a major security issue in polkit:
turns out that ever since it was invented, `pkexec` has had a bug
allowing for local root privilege escalation. Which is...bad.
The issue and some of the comments around it prompted me to wonder -
why is `pkexec` still a thing? Particularly, why is it still a thing we
are shipping by default in just about every Fedora install?
My best recollection is that pkexec was kinda a kludge to allow us to
get rid of consolehelper: some apps weren't getting rewritten to the
Right Way of doing things under policykit, they still just wanted to
have the entire app run as root, and pkexec was a way to make that
But that was then, and this is now. Does anything in Workstation use
pkexec? Does anything in KDE use it? I'm pretty sure (at least I really
hope!) nothing in Server uses it. I don't think any of our
documentation recommends its use for interactive execution of things as
root (these days we tend to just specify `sudo` for that and assume the
install has an admin user).
Should we just split it out of the polkit package into a subpackage and
stop shipping the subpackage on those editions/spins at least? If
there's anything in other desktops still using it, it can grow a
dependency on the subpackage...
Am I forgetting some other reason we still need it?
IRC: adamw | Twitter: adamw_ha
On Fri, Jan 28, 2022 at 3:04 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
> Adam Williamson <adamwill(a)fedoraproject.org> writes:
> > ...and yet despite being so easy to review it somehow had a major
> > security vulnerability ever since it was written.
> This is not a good metric. easy to review != was sufficiently reviewed,
> and getting sufficient code review might be the hardest problem in
> software engineering.
> Additionally, if a project has never had an issue, it's just as likely
> that no one has ever really looked at it than that it's "safer".
Actually, someone had conceived that it might be a problem in 2013:
真実はいつも一つ！/ Always, there's only one truth!
On Thu, 2022-01-27 at 08:30 +0100, Milan Crha wrote:
> On Wed, 2022-01-26 at 15:18 -0800, Adam Williamson wrote:
> > There are still over a dozen packages in the distro that
> > require it:
> the gnome-software also calls pkexec is some occasions, once when
> external appstream data is used (not a thing in Fedora, as far as I
> know) and when invoking fedora-third-party in some cases. There's no
> hard require for it in the .spec file.
Yeah, I actually started looking last night and found a few other
places too :/ gnome-control-center installs a `/usr/libexec/cc-remote-
login-helper` which is run by pkexec, for instance. So I guess we're
stuck with it :(
IRC: adamw | Twitter: adamw_ha
It has been a while about default fedora backgrounds need a refresh. The
current method requires a package review for each release, which deemed
One of suggestions is making a package containing a set of 10 Fedora
release wallpaper. The issue will be the increase of file size as the
Design Team chose to keep PNG format instead of JPG for the default
Another idea is to have an umbrella of package named fxx-backgrounds as
an example containing subpackages including default and extras
wallpapers as illustrated below:
fxx-backgrounds as main package
f36-backgrounds-base and f36-backgrounds-extras as subpackages
The problem is I have no idea how to do that in spec format.
Fedora Design Team
Fedora Design Suite maintainer
#fedora-meeting-2: Workstation WG (2022-01-25)
Meeting started by brainycmurf at 20:52:10 UTC. The full logs are
* Present members: Owen, Neal, Allan, Jens, Tomas, Chris, Michael,
Matthias (brainycmurf, 20:52:23)
* Present guests: Luna Jernberg(bittin), Felipe (brainycmurf, 20:52:23)
* Regrets: (brainycmurf, 20:52:23)
* Missing: (brainycmurf, 20:52:23)
* Secretary: Owen (brainycmurf, 20:52:23)
* Improve the user feedback for OOM situations (brainycmurf, 20:52:24)
* LINK: https://pagure.io/fedora-workstation/issue/202 (brainycmurf,
* ACTION: Matthias to check with Benjamin Berg whether there is any
progress he is aware of. (brainycmurf, 20:52:28)
* Offline updates: install updates after the user triggers the
shutdown/restart command, instead of installing them in the next boot
* LINK: https://pagure.io/fedora-workstation/issue/258 (brainycmurf,
* Work on a new appindicator protocol (brainycmurf, 20:52:40)
* LINK: https://pagure.io/fedora-workstation/issue/264 (brainycmurf,
* Announcements, status updates (brainycmurf, 20:52:53)
* Devconf.CZ Online this weekend (brainycmurf, 20:53:10)
* LINK: https://www.devconf.info/cz/ (brainycmurf, 20:53:12)
* FOSDEM Hybrid the week after (brainycmurf, 20:53:14)
* LINK: https://fosdem.org/2022/ (brainycmurf, 20:53:16)
* The minutes from last week have been posted online. (brainycmurf,
Meeting ended at 20:54:14 UTC.
* Matthias to check with Benjamin Berg whether there is any progress he
is aware of.
Action Items, by person
* Matthias to check with Benjamin Berg whether there is any progress
he is aware of.
People Present (lines said)
* brainycmurf (31)
* zodbot (7)
* Allan (0)
Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions