Hi folks!
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
networking criteria.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
==============================================
#fedora-meeting-2: Workstation WG (2020-11-24)
==============================================
Meeting started by cmurf at 02:47:33 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-25/workstation.2…
.
Meeting summary
---------------
* Rollcall (cmurf, 02:48:01)
* present: Michael, Allan, Jens, Langdon, Matthias, Neal, Tomas,
Chris, Owen (cmurf, 02:48:02)
* regrets wg members: (cmurf, 02:48:04)
* present guests: James, Felipe (cmurf, 02:48:06)
* Approve of 17 Nov minutes: (cmurf, 02:48:08)
* LINK:
https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-11-19-…
(cmurf, 02:48:10)
* Announcements, follow-ups, status reports (cmurf, 02:48:12)
* Automatically install the OpenH264 codecs (cmurf, 02:48:30)
* LINK: https://pagure.io/fedora-workstation/issue/84 (cmurf,
02:48:32)
* Further design work needed, but we have a basic idea (cmurf,
02:48:40)
* H264 support for Firefox (cmurf, 02:48:42)
* LINK: https://pagure.io/fedora-workstation/issue/126 (cmurf,
02:48:44)
* ACTION: Michael will work with Martin to adjust the firefox wrapper
shell script for this case (cmurf, 02:48:56)
* GNOME Software is recommending proprietary software (cmurf, 02:48:58)
* LINK: https://pagure.io/fedora-workstation/issue/111 (cmurf,
02:49:00)
* LINK: https://pagure.io/fedora-workstation/issue/203 (cmurf,
02:49:02)
* LINK: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/921
(cmurf, 02:49:12)
* Further discussion needed upstream (cmurf, 02:49:16)
* Open Floor (cmurf, 02:49:18)
Meeting ended at 03:07:03 UTC.
Action Items
------------
* Michael will work with Martin to adjust the firefox wrapper shell
script for this case
Action Items, by person
-----------------------
* **UNASSIGNED**
* Michael will work with Martin to adjust the firefox wrapper shell
script for this case
People Present (lines said)
---------------------------
* cmurf (46)
* zodbot (7)
* mcatanzaro (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
On Wed, 2020-11-18 at 14:32 -0500, Steve Grubb wrote:
> On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote:
> > A new version of libcap-ng is going to be released next week. Normally this
> > isn't newsworthy, nor is this a soname version bump. But it is important
> > to let the broader community know something about it. The behaviour of
> > capng_apply is changing slightly.
> >
> > In the past, capng_apply would silently eat errors when the bounding set
> > could not be changed. In order to change the bounding set, you have to have
> >
> > CAP_SETPCAP. A developer reported an issue in github where their project
> > needed to know that capng_apply was completely successful changing the
> > bounding set. Meaning that they need an error returned. I didn't think too
> > much of it and made the change.
> >
> > Then one day I noticed that I could not update a package against Fedora's
> > git or push a change. Looking into this, I found gnome-keyring was not
> > working. [1] I dug into the source code and found that it was trying to
> > change the bounding set when it had partial capabilities. The fix is to
> > simply verify that you have CAP_SETPCAP before attempting this.
> >
> > I don't know of any other software that is affected. But I wanted to give
> > everyone a heads up before I push it out. I always dogfood libraries I
> > work on, so maybe this is the only issue.
> >
> > Eventually libcap-ng needs to get pushed over to F33 because there is a
> > problem with ambient capailities that the new release fixes. And speaking
> > of ambient capabilities, the new version of libcap-ng contains a new
> > library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app
> > to drop ambient capabilities leaving the other capabilities intact. All
> > the work is done in the constructor, so no function calls are needed.
>
> Hello,
>
> The new libcap-ng has been built into rawhide.
...and it does break gnome-keyring, and it also breaks cifs-utils (so
you can't mount CIFS/SMB shares), as per this upstream bug report:
https://github.com/stevegrubb/libcap-ng/issues/21
whose reporter also noted what looks like a valid problem in your
gnome-keyring fix.
Was it really necessary to build this when you *knew* a major package
did not work with it? Did you talk to the Workstation folks about
getting the patch applied to gnome-keyring?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net