It's become clear that I haven't had the time I thought I'd have this past
year due to $life ...
These are in a bit of a broken state and right now I'd advise people that
need them to use upstream packages/containers.
I don't foresee sufficient time coming in the near future with family needs
in advance of hobbies like Fedora of course.
I'll give it a week or so for anyone to contact me who wants to pick them
up, otherwise I'll update pagure to assign them to "orphan"
Good Morning Everyone,
At Flock, a few of us met to discuss a future vision of the packager workflow.
This discussion was triggered by the realization that a number of initiatives
are happening around packaging in Fedora but there is no real shared vision on
what we want the packager UX/workflow to be.
The lack of vision on the packager workflow means we could deploy something
today, thinking it is the improvement over the current workflow but would
prevent us from (or make it harder to) doing other changes afterwords that would
be even more beneficial..
So once that concern was raised, we took some time during the Fedora
Infrastructure hackfest to gather the people interested around a white board and
brainstorm on what a future packager workflow could look like.
We tried not to link this process to any tool in particular as well as focus on
the what and why rather than any how.
Here is what the vision we came to and that we would like to discuss:
○ Every changes to dist-git is done via pull-requests
○ Pull-requests are automatically tested
○ Every commit to dist-git (ie: PR merged) is automatically built in koji
○ Every build in koji results automatically in an update in bodhi
○ Every update in bodhi is automatically tested
○ If the tests pass, the update is automatically pushed to the repository
For this workflow to work nicely we need to fix a few things first:
- We need to work on the change logs in the spec files, as otherwise
pull-requests are going to conflict more often than not
- We need to fine a place to insert the end-user information about an update (in
the PR description?)
- When a group of people want to collectively work on a change (involving one or
more packages), they’ll need a place to collaborate. This could be someone’s
fork or, preferably, a fork of the project collectively maintained by that
For example: the python SIG would have a group with forks of the different
python packages they are working on
- We need to figure out how to enable opening a pull-request again multiple
branches at one.
Why should we agree now on a long term vision?
A concrete example to this, I have been playing with the idea to get ride of git
branches in dist-git for a while now. Basically use git as it is meant to be
used: have one branch for development (most often master) and branch of master
when you need to, not simply because a new version of Fedora happened.
However, if we implemented this, we would break the workflow described above as
suddenly there would be no way to specify that a given PR is meant to land in a
certain version of Fedora or another (Is this PR for rawhide? F31? F30? All of
them? Some of them?).
Having this idea of where we want to go should give us a goal as well as way to
reflect if changes we think are good in isolation would actually help achieving
this vision or not.
This proposal was based on the brainstorming session a few of us had at flock,
but before we can see how to implement it we need more inputs and this is where
you come in :)
Do you like this vision? Would you change some pieces of it? Would you change it
In an ideal world, what would packaging software look like to you?
Looking forward to the discussion,
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://email@example.com...
I finally found how to mute "Projects in Copr" on discussion.fedoraprojects.org.
It is now muted for new users and all **existing** users as well.
This should suppress this category from Latest and RSS as many people requested.
If you want to follow this category or topic in this category, please enable following in WebUI once again. Your choice
will override the site defaults.
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
Hello. I don't know if I'm right to ask this in this mailing list and if
I should post this elsewhere, please forgive me bothering you.
I believe GNU IceCat updates are not shipped to Fedora repositories and
we're still using 60.9 version. How can I ask for updates or just remind
maintainers about it?
Thanks and sorry I bothered.
== 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
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
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
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:
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
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
* 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]
He / Him / His
Fedora Program Manager