Fedora 32 System-Wide Change proposal: iptables-nft-default
by Ben Cotton
https://fedoraproject.org/wiki/Changes/iptables-nft-default
== Summary ==
Make iptables-nft the preferred iptables variant.
== Owner ==
* Name: [[User:psutter| Phil Sutter]]
* Email: psutter(a)redhat.com
== Detailed Description ==
<code>iptables-nft</code> package provides alternative implementations of
iptables, ip6tables, ebtables and arptables and associated save and restore
commands. These use nftables internally while providing the same look'n'feel as
the original tools. Users may choose between both implementations using
<code>alternatives</code> tool.
Upstream considers the traditional implementations legacy and therefore renamed
the binaries adding '-legacy' suffix. In Fedora, same has been done to
<code>arptables</code> and <code>ebtables</code> packages, namely renaming them
to <code>arptables-legacy</code> and <code>ebtables-legacy</code>. Legacy
<code>iptables</code> and <code>ip6tables</code> remain in
<code>iptables</code> package, which in fact is the only one other packages
depend upon.
To change the status quo, two measures are planned:
=== Raise priority of nft-variants in <code>alternatives</code> ===
Currently, legacy variants are installed with priority 10 and nft
variants with priority 5. This must be changed as otherwise installing
<code>iptables-legacy</code> in a system with
<code>iptables-nft</code> installed would change the active
alternative (since they are in automatic mode by default).
On the other hand, existing systems using legacy variants should not
be changed by a system update. Therefore nft variants' priorities
should be chosen to match legacy ones.
=== Rename <code>iptables</code> package ===
New name should be <code>iptables-legacy</code> which aligns with
ebtables and arptables and reflects upstream status. To resolve
dependencies, <code>Provides: iptables</code> statement will be added
to <code>iptables-nft</code> package. This should automatically change
the default variant to nft.
== Benefit to Fedora ==
* RHEL8 ships nft-variants exclusively, make Fedora align with that by
default while still providing the option to fall back to legacy tools.
* New features and improvements are likely to hit nft-variants due to
the possibility nftables backend allows for. Although at this point
some legacy features (e.g. ebtables among match) are still missing,
others are already there (like, e.g. xtables-monitor tool) or are
being upstreamed right now (improved tool performance when dealing
with large rulesets).
== Scope ==
* Proposal owners:
Changes are rather simple: Rename <code>iptables</code> package, add
<code>Provides:</code> line to <code>iptables-nft</code> package,
change priorities used when calling <code>alternatives</code>.
* Other developers: N/A
The changed tools may cause regressions among packages using them and
it affects only new installations (or those manually switched over).
So while no explicit effort is required from them, they should be made
aware of the change so they take a possible regression in iptables
into account, quickly test against legacy variant and file a ticket
(or complain to the right person) if that fixes the problem.
* Release engineering: [https://pagure.io/releng/issue/8934 #8934]
* Policies and guidelines: No change required
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Due to the package rename and <code>Provides:</code> line, upgrades will pull
in <code>iptables-nft</code> package. But due to the equal alternatives
priorities, existing choices won't be changed and so existing installations
shouldn't be harmed (apart from forced installation of
<code>iptables-nft</code> package).
Sadly, there are a few known issues, like e.g. missing support for ebtables
broute table or among match and a few iptables targets/matches. Users depending
on such features are advised to install <code>iptables-legacy</code> package
and switch variants using <code>alternatives</code>.
== How To Test ==
Any users of iptables/ebtables/arptables should switch to nft-variants using
alternatives tool (if necessary) and check that everything works as before. Any
issues should be reported despite the known compatibility issues described
above since knowledge about who uses the missing features is valuable
information for both up- and downstream.
== User Experience ==
Ideally look'n'feel shouldn't change. Since iptables-nft does not need a lock
file anymore, no problems with stale xtables-lock or parallel iptables calls in
different mount namespaces are expected anymore. Given the changes currently
being upstreamed, users dealing with large rulesets should see a performance
increase when manipulating the ruleset (lower run-times of iptables or
iptables-restore, packet processing speed should not really change).
== Dependencies ==
Other packages depending on iptables:
* NFStest
* clatd
* ctdb
* fail2ban-server
* firewalld
* fwsnort
* iptstate
* libvirt-daemon-driver-network
* libvirt-daemon-driver-nwfilter
* moby-engine
* nfacct
* origin
* podman
* psad
* python3-ipatests
* ravada
* rkt
* shorewall
* shorewall-init
* shorewall-lite
* shorewall6
* shorewall6-lite
* sshuttle
* sslsplit
* ufw
Since nft-variants are supposed to be drop-in replacements, no outside
contribution is needed in order to perform this change.
== Contingency Plan ==
* Contingency mechanism: Nothing needs to be done, the change should
be atomic.
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools
* Man pages:
** [http://man7.org/linux/man-pages/man8/xtables-nft.8.html xtables-nft.8]
** [http://man7.org/linux/man-pages/man8/xtables-legacy.8.html xtables-legacy.8]
** [http://man7.org/linux/man-pages/man8/xtables-monitor.8.html
xtables-monitor.8]
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
I think we should stop building i686 packages we're not shipping
by Matthew Miller
This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
build stuff like libreoffice for i686, but then (mostly) don't ship it.
This seems like a waste of resources and time.
I know it's somewhat complicated (for example, there's actually a library
package in libreoffice, libreofficekit, so that gets plucked in to
multilib), and there's quite a lot to work out, but ... does this seem like
a good intended direction?
One immediate way to do this is to start adding `ExcludeArch: i686` to
"leaf" packages (I mean: to allow / encourage people to do that). But I
don't want to add _more_ cruft to the standard minimal spec file, so this
seems like the wrong direction. And I still think we want to keep multilib
for compatibility (hello, old games!). Could we do something clever in koji
instead?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2 years, 7 months
co/lead-maintainer sought: python-mailmerge (python)
by Brian (bex) Exelbierd
Hi,
I added python-mailmerge to Fedora Linux as it was super important to
large parts of my work as FCAIC. In my current $dayjob I use it less
frequently, though I know of colleagues who still depend on it.
I'd love to find a maintainer to help me with it. There is a new
release pending, which I suspect will just be "build the rpm with new
code; test it; ship it" level effort. I am happy to hand the whole
thing off to someone or to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 7 months
F35 Change: Switch to WirePlumber as the PipeWire session manage
(late Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WirePlumber
== Summary ==
PipeWire currently uses a simple example session manager. This
proposal is to move to the more powerful WirePlumber session manager.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
PipeWire requires a session manager that at least needs to implements
the following features:
* create and configure detected devices in the system. This includes
audio cards, video and bluetooth devices.
* configure applications and route audio/video to/from them to the
devices and filters.
* keep track of prefered devices and volumes.
* move audio/video streams when devices appear and disappear.
PipeWire uses a simple example session manager with limited features
and configuration options. The proposal is to
move to WirePlumber.
WirePlumber is built on GNOME (GObject) technologies and has bindings
for most languages using GObject introspection.
WirePlumber allows one to implement many of the rules for setup and
configuration using small LUA scripts, which are
easier to maintain and customize. These are some of the functions that
are scriptable in LUA:
* setup and configuration of the devices and streams. This includes
deciding if devices and streams need to operate in 5.1 or stereo mode,
depending on the available devices.
* routing of the streams based on metadata of the streams (Roles) and
overall state of the system.
* volume/mute restore of devices and streams
== Benefit to Fedora ==
PipeWire currently uses a simple example session manager with mostly
hardcoded logic and rules. This proposal wants to replace the session
manager with a more advanced session manager, called WirePlumber.
WirePlumber brings to following improvements
* Drop-in replacement session manager for PipeWire, implements the
exact same features as the example session manager
* built with GObject, which provides a richer development experience
and adds bindings for most languages
* extensible with loadable modules
* scriptable policy using small lua scripts
* better integration with desktop settings
The main benefits will be that this session manager would allow for
more customization of the policy
and rules. Initially we aim for feature parity with the current
solution and work on more features
in the next releases.
== Scope ==
* Proposal owners:
This is a rather isolated changed. Instead of starting the
pipewire-media-session executable we would need to package
and start WirePlumber instead.
WirePlumber has been kept up to data with the features in the example
session manager and would need testing.
* Other developers: None. This is an isolated PipeWire change.
* Release engineering: A new systemd service will need to be activated
in the default install.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Should not cause any change.
== How To Test ==
Experience should be the same as before. Retest all audio testcases.
== User Experience ==
Should not cause any visible change.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?): If the
feature can not be completed we continue using the existing
pipewire-media-session.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 7 months
co/lead-maintainer sought: gocryptfs+dependencies (go-lang)
by Brian (bex) Exelbierd
Hi,
While I still actively use gocryptfs, I am busy enough with my $dayjob
that I know I am not able to put enough time into maintaining it.
Right now this has been OK as they have stopped new releases while
they get v2.0 out the door. However, that will ship soon.
I'd love to get some help maintaining the main rpm and the 6
dependencies I have for it. I am happy to hand it all over to you or
to work with you.
Thank you.
regards,
bex
--
Did this email arrive after work for you? Stop reading it and enjoy
some work/life balance.
Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com
2 years, 7 months
Orphaning the cura-lulzbot package set
by Tom Callaway
This fork of cura has basically been abandoned by upstream, and the new
company that acquired Lulzbot has gone out of compliance with the source
code for the firmware. They have made it very clear that they have no real
interest in working with the community to improve this situation, and I no
longer have any motivation to maintain these packages.
Accordingly, I've orphaned the following packages:
* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot
~spot
P.S. I opened an upstream pull request to add support for the Lulzbot TAZ
Pro and the Mini 2 in the main Cura codebase (still actively maintained). I
would highly recommend that anyone considering reviving these packages
devote their efforts in that direction instead.
2 years, 7 months
Heads Up: OpenEXR / Imath 3.1 update
by Richard Shaw
I've done quite a bit of checking on builds using a COPR so I don't believe
these updates make anything worse than they already are and might help in a
few cases.
As usual, the plan is to build in a side tag and I plan to update both
rawhide and f35.
Thanks,
Richard
2 years, 7 months
Fedora 35 Change: Add Fedora Kinoite as a variant (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Fedora_Kinoite
== Summary ==
Introduce Fedora Kinoite as a variant of Fedora alongside Fedora Silverblue.
== Owner ==
* Name: [[User:siosm| Timothée Ravier]] (travier AT redhat DOT com)
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] (ngompa13 A gmail D com)
* SIG: [[SIGs/KDE|KDE SIG]]
== Detailed Description ==
Fedora Kinoite is an immutable desktop operating system featuring the
KDE Plasma desktop. It is based on the same technologies as Fedora
Silverblue (rpm-ostree, Flatpak, podman). Fedora Kinoite is to the
Fedora KDE Spin what Fedora Silverblue is to Fedora Workstation.
We chose the Kinoite name for the following reasons:
* KDE based projects traditionally start with a 'K'
* Kinoite is a blue mineral (https://en.wikipedia.org/wiki/Kinoite),
thus referring to both the 'silver' and 'blue' part of Silverblue and
the blue color of the KDE logo.
* "Kinoite" means "There is a tree" in Japanese
(https://translate.google.com/?sl=auto&tl=en&text=kinoite&op=translate),
thus referring to the 'tree' in 'ostree'.
== Benefit to Fedora ==
This will make Fedora more attractive to users that are interested in
immutable OSes and underlying technologies but would prefer to use the
KDE desktop environment. This should also strengthen Silverblue as
more effort may be put into fixing the issues in the shared
technologies.
== Scope ==
* Proposal owners:
** The KDE SIG will submit the [https://pagure.io/pungi-fedora Pungi
changes] needed to add this new variant to the compose.
** The KDE SIG will submit the changes to add a new sub-package to
[https://src.fedoraproject.org/rpms/fedora-release fedora-release].
** The KDE SIG will maintain the Kinoite specific rpm-ostree config in
the [https://pagure.io/workstation-ostree-config
workstation-ostree-config repo].
* Other developers: N/A (not a System Wide Change)
* Release engineering: Submitted as [https://pagure.io/releng/issue/9952 #9952].
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: The "Fedora Kinoite" trademark has been
[https://pagure.io/Fedora-Council/tickets/issue/344 approved]
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
This edition has been built and made available as an unofficial
preview and can be tested with the instructions from this
[https://fedoramagazine.org/discover-fedora-kinoite/ Fedora Magazine
article].
== User Experience ==
Current limitations (last updated 2021-01-18):
* No rpm-ostree support in Discover (graphical package and update
manager). A Season of KDE is in progress to work on that.
* Partial Flatpak support in Discover.
* [https://pagure.io/fedora-kde/SIG/issue/13 KDE applications are not
yet available as Flatpak from the Fedora registry].
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Report to the next release.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A
== Documentation ==
A lot of the known issues impacting Fedora Kinoite are shared with
Silverblue and their resolution is the same:
https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/.
It is not clear for now if Kinoite specific documentation is needed
but a landing page with pointer to known issues might be good.
== Release Notes ==
Fedora Kinoite has been introduced as a new variant of Fedora Linux
featuring the KDE desktop environment and the same technologies as
Silverblue (rpm-ostree, Flatpak, podman).
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 7 months
