F36 Change: Retired Packages (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RetiredPackages
== Summary ==
Easy the task of removing packages, which were retired and no longer
receives updates.
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msuchy(a)redhat.com
== Detailed Description ==
This follows the [[Changes/Fedora-Retired-Packages]] which was
withdrawn. This time I provide a script `remove-retired-packages`
(presented in the package of the same name) which identifies packages
retired between N-1 and current (N) version. Alternatively, user can
run:
remove-retired-packages 32
which will look for packages between Fedora Linux 32 and the current version.
The packages are suggested to be removed one by one, which allows the
admin to skip the package and keep it on their machine despite being
retired.
Part of this proposal is to change
[https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-...
the documentation for the upgrade].
== Feedback ==
See [[Changes/Fedora-Retired-Packages#Feedback original feedback page]]
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Discussion] on devel mailing list prior this proposal.
== Benefit to Fedora ==
* We suggest users to remove packages that are no longer maintained
and may contain security vulnerabilities.
* We make sure that archaic packages do not break upgrade between two
versions of Fedora.
== Scope ==
* Proposal owners:
Subpackage `remove-retired-packages` has been created (subpackage of
`fedora-upgrade`).
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
Edit of https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#sect-...
- will be done after approval from FESCO.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Packages that are no longer maintained are removed during a
distribution upgrade.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 5 months
Introduction: nedia, a Silverblue fan
by Aiden Langley
Kia ora koutou,
I'm nedia, I live in NZ & I've been knocking about the matrix/irc for a few days now. I'll be 28 on the 30th, I've been using Fedora for about a year, Linux for about 3-4 (Ubuntu & Antergos), & have been doing software dev for about 5-6 years.
I started my career w/ Java, then spent some time w/ PHP on some legacy spaghetti, wrote a cool CLI that interfaced w/ AWS EC2 instances to run data conversions and had a lot of fun with it, and I've dabbled in some Rust, C#, Python and more JavaScript than I'd like to admit. Keen to write something in Go one day.
https://wowhub.co.nz is what keeps me occupied at the moment, I contract / volunteer at a not for profit, charge enough to pay my bills but my work is mostly kōha (a gift \ given free of charge.) I could potentially spend a lot of time on Fedora related projects, my weekends are v open & I give the Whakaoranga Whanau about 24 hours a week. I have tourettes so sometimes I need days to myself to recoup mentally.
I'm currently using Silverblue, I'm enamored by the ideas - immutability is huge to me now. I get anxiety whenever I use another distro, knowing one false step might lead to a re-install. I'm a tinkerer so it happens a fair bit.
I'm also running Rawhide, since Silverblue affords me an extra layer of security, it seemed like it was the perfect fit for running some potentially unstable software.
An area that seems like it could use some work from what I've observed is `rpm-ostree`, being able to upgrade packages for testing e.g. `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-992e409289` & group installs are missing at the moment. I wanted to be able to run a 2nd DE in case of bugs, but would have to install each package individually as it stands so I settle for just rebasing when the time comes. Is `rpm-ostree module` intended to be the new `group`?
Anyway, v interested in Silverblue and putting myself in a position to test & contribute to the above, so if anybody would like to sponsor / point me in the right direction, that would be much appreciated.
Cheers,
*nedia*
2 years, 5 months
deltarpm usefulness?
by Marek Marczykowski-Górecki
Hi all,
I think deltarpm is not really useful anymore:
- there are very few drpm files in the repository, see for example:
https://download.fedoraproject.org/pub/fedora/linux/updates/34/Everything...
https://download.fedoraproject.org/pub/fedora/linux/updates/33/Everything...
- those that actually are there, are mostly about small packages anyway
- personally, I haven't seen it being used for a long time
- there is also argument that people's connection bandwidth nowadays
tends to be fast enough to make the package rebuilding actually
slower than downloading the whole package (but that really vary between
different installations)
- and most importantly: drpm files are - by design - processed before
checking the package signature, which exposes rather big attack
surface(*)
Can deltarpm be disabled by default? In the few cases where it's
actually useful (if there are any...), user is free to enable it, but
the default would be significantly more secure this way.
(*) it is integrity protected via a hash in the repository metadata, but
repository metadata in Fedora are still not signed - so this all heavily
depends on the integrity of the [HTTPS connection to]
mirrors.fedoraproject.org server (or any of CAs trusted by the system) -
a rather fragile single point of failure.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
2 years, 5 months
openbabel-3.1* in Rawhide
by Antonio T. sagitter
Hi all.
openbabel-3.1.1 is ready for Rawhide branch. 'libopenbabel' soname is
updated from 5 to 7, all dependent packages will need a rebuild at least:
$ repoquery --whatrequires openbabel-devel --disablerepo=*
--enablerepo=*-source
IQmol-0:2.15.0-3.fc34.src
ghemical-0:3.0.0-16.fc34.src
molsketch-0:0.7.2-1.fc34.src
xdrawchem-0:1.10.2-4.fc34.src
I'm waiting some days (one week around) before creating a side-tag.
Ragards.
--
---
Antonio Trande
Fedora Project
mailto: sagitter(a)fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keyserver1.pgp.com/
2 years, 5 months
llvm 13.0.0-final ABI Change
by Tom Stellard
Hi,
I'm going to start packaging LLVM 13.0.0-final for rawhide and f35. The
13.0.0-final release has a different ABI than 13.0.0-rc1, so I will be
rebuilding the following packages as part of the update:
castxml
doxygen
gnome-builder
mesa
openshadinglanguage
qt-creator
qt6-qttools
zig
-Tom
2 years, 5 months
Strange mock chainbuild issue: package has incorrect checksum
by Julian Sikorski
Hi,
my local kernel rebuilds have started failing for no apparent reason - I
was using a similar command successfully for several months.
/mnt/openmediavault is a samba share. This is what gets output into the log:
$ mock --chain --localrepo /mnt/openmediavault/kernel/ -r
fedora-34-x86_64 --disable-plugin=tmpfs --enable-plugin=yum_cache
--isolation=simple ../pesign/pesign-113-16.fc35.src.rpm
redhat/rpm/SRPMS/kernel-5.14.6-300.s0ix02.fc34.src.rpm --with baseonly
--without debuginfo --define='pe_signing_token NSS Certificate DB'
--define='pe_signing_cert Julians Secure Boot signing key - Julian Sikorski'
...
Error calculating checksum
/mnt/openmediavault/kernel/results/fedora-34-x86_64/pesign-113-16.fc35/pesign-113-16.fc34.x86_64.rpm:
(39, fsync failed: Permission denied)
Package "pesign-113-16.fc34.x86_64" from local repository
"local_build_repo" has incorrect checksum
Error: Some packages from local repository have incorrect checksum
ERROR: Exception(redhat/rpm/SRPMS/kernel-5.14.6-300.s0ix02.fc34.src.rpm)
Config(fedora-34-x86_64) 0 minutes 7 seconds
INFO: Results and/or logs in:
/mnt/openmediavault/kernel/results/fedora-34-x86_64/kernel-5.14.6-300.s0ix02.fc34
ERROR: Command failed:
# /usr/bin/dnf builddep --installroot
/var/lib/mock/fedora-34-x86_64/root/ --releasever 34
--setopt=deltarpm=False --allowerasing --disableplugin=local
--disableplugin=spacewalk --disableplugin=versionlock
--disableplugin=local --disableplugin=spacewalk
--disableplugin=versionlock
/var/lib/mock/fedora-34-x86_64/root//builddir/build/SRPMS/kernel-5.14.6-300.s0ix02.fc34.src.rpm
--setopt=tsflags=nocontexts
Any ideas what is going on in here? Thanks!
Best regards,
Julian
2 years, 5 months
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, 5 months
Fedora 35 status and testing needed
by Adam Williamson
Hi folks! Just wanted to give an update on Fedora 35 status and beg for
testing :D
We are now down to either one or two blocker bugs. They are in quite
specific areas so the fixes will not be hugely impactful to anything
else. I'm hoping to be able to run an RC compose later today (Tuesday).
However, we're also only 2 days from go/no-go.
Given this, it'd be super helpful if people could help get the
validation tests run on the current nominated nightly compose. We don't
need to wait for an RC to run most tests; for the more complicated or
trickier tests, we can run them now against a nightly and the results
can be counted so long as nothing relevant changes in the RC.
I've just manually nominated the most recent compose (20211018.n.0) for
testing; it won't have the fixes currently in updates-testing (mainly
for plasma-discover), so take that into account. You can see the
summary page (which shows results from all individual pages) here:
https://fedoraproject.org/wiki/Test_Results:Current_Summary
you can enter results by editing individual sections from that page
(the wiki will automagically edit the correct individual page), or by
using the relval tool - just 'dnf install relval' then 'relval report-
results'.
You can look for tests that really need to be run here:
https://openqa.fedoraproject.org/testcase_stats/35/
each of the pages there shows a sort of 'over time view' of the test
cases of that type, showing when it was most recently run and a little
chart view that illustrates which composes the test has been run on and
what the results were (green for pass, orange for warn, red for
failed). Look out for tests that have release level 'Basic', 'Beta' or
'Final' and which have not been run recently or at all; these are the
ones to focus on. For instance, at
https://openqa.fedoraproject.org/testcase_stats/35/Desktop.html we can
see that several of the desktop tests have not yet been run on aarch64;
it'd be great if anyone with an aarch64 system capable of running
Workstation could run those tests and add the results.
Thanks everyone!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years, 5 months
