F36 Change: New requirements for akmods binary kernel modules for
Silverblue / Kinoite support (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Binary_Kernel_Modules_rpm-ostree
== Summary ==
In order to improve the current support for akmods based binary kernel
modules in Silverblue/Kinoite, this change introduces a new dependency
in akmods to a meta package that strongly links the version of a
kernel package with its `-devel` sub-package.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]]
* Email: siosm(a)fedoraproject.org
* Name: [[User:Kwizart| Nicolas Chauvet]]
* Email: kwizart(a)fedoraproject.org
* Name: [[User:Tpopela| Tomáš Popela]]
* Email: tpopela(a)fedoraproject.org
== Detailed Description ==
Silverblue & Kinoite currently include the `kernel-devel` and
`glibc-devel` packages by default in the base image to work around
dependency issues when using akmods based binary kernel modules such
as the NVIDIA binary driver.
To be able to remove that dependency, a new meta-package has been
added as kernel sub-package to strongly link a given kernel with its
corresponding `-devel` sub-package that is needed for building those
kernel modules with akmods.
With this change, custom kernel builds outside of the fedora
repository will have to provide this new meta-package.
A longer explanation of how akmods based binary kernel modules are
supported in Silverblue / Kinoite is available in
https://src.fedoraproject.org/rpms/akmods/pull-request/3#comment-90939.
References:
* New `kernel{,-debug}-devel-matched` sub-packages:
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1195
* Dependency change in akmods:
https://src.fedoraproject.org/rpms/akmods/pull-request/3
* Dependency removal in Silverblue/Kinoite:
https://pagure.io/workstation-ostree-config/pull-request/214
== Feedback ==
See individual PRs for existing discussions.
== Benefit to Fedora ==
This change will noticeably reduce the size of the Silverblue /
Kinoite base image and updates for users that do not use any binary
kernel modules.
== Scope ==
* Proposal owners:
** Code changes are ready. Merging is in progress.
* Other developers:
** Custom kernel builds outside of the fedora repository will have to
provide this new meta-package.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
This should not impact existing systems on updates. Users already
using binary kernel modules will now have those dependencies
automatically installed. Other users will have them removed.
== How To Test ==
* Install an akmods based binary kernel module (NVIDIA driver from RPM
Fusion for example) on Silverblue/Kinoite once the changes mentioned
above are merged.
* This should work just like it does on F35.
== User Experience ==
There should be no change in user experience.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert to previous behavior
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late
System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GNUToolchainF36
== Summary ==
Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
The gcc 12 is currently under development and will be included in
Fedora 36 upon release. The glibc 2.35 change will be tracked in this
top-level GNU Toolchain system-wide update.
== Owner ==
* Name: [[User:submachine| Arjun Shankar]]
* Email: arjun(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU C Library, GNU Debugger, and GNU
Binary Utilities make up the core part of the GNU Toolchain and it is
useful for our users to transition these components as a complete
implementation when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 12 in Q2,
before the Fedora 36 release. It will contain many new features,
documented here: https://gcc.gnu.org/gcc-12/changes.html. The latest
point release for gcc 12 will be included in Fedora 36, this will most
probably be 12.1.
The GNU C Library version 2.35 is expected to be released in the
beginning of February 2022; we have started closely tracking the glibc
2.35 development code in Fedora Rawhide and are addressing any issues
as they arise. Given the present schedule Fedora 36 will branch after
the release of glibc 2.35. However, the mass rebuild schedule means
Fedora 36 will mass rebuild (if required) before the final release of
glibc 2.35, but after the ABI is frozen.
The GNU Binutils version 2.37 and GNU Debugger version 11.1 currently
included in Fedora 35 will continue to be included in Fedora 36. There
will be a GNU Binutils version 2.38 released at the end of January,
but the inclusion will be scheduled for Fedora 37.
== Benefit to Fedora ==
Stays up to date with latest features, improvements, security and bug
fixes from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the
GNU Toolchain.
== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb,
...) developers need to ensure that gcc, glibc, binutils, and gdb in
rawhide are stable and ready for the Fedora 36 branch.
* Other developers: Given that glibc is backwards compatible and we
have been testing the new glibc in rawhide it should make very little
impact when updated, except for the occasional deprecation warnings
and removal of legacy interfaces from public header files. An update
to GCC 12.1 would mean a new major release and could have broad scope
for change.
* Release engineering: A mass rebuild is strongly encouraged;
[https://pagure.io/releng/issue/10515]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.
The upgrade to glibc-2.35 coincides with the
[[Changes/RemoveNSCD|removal of nscd]].
Some source changes may be required for gcc 12 rebase:
https://gcc.gnu.org/gcc-12/changes.html
== How To Test ==
The GNU Compiler Collection has its own testsuite which is run during
the package build and examined by the gcc developers before being
uploaded.
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future we may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, Unicode 14 support, C.UTF-8 locale support, improved
experimental support for C++20 and C++23, new compiler warnings and
improvements to existing ones, and more.
== Dependencies ==
<!-- What other packages (RPMs) depend on this package? Are there
changes outside the developers' control on which completion of this
change depends? In other words, completion of another change owned by
someone else and might cause you to not be able to finish on time or
that you would need to coordinate? Other upstream projects like the
kernel (if this is not a kernel change)? -->
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 36 cycle. The mass rebuild would ensure all packages can be
built with the newer compiler and core runtime.
== Contingency Plan ==
* Contingency mechanism glibc: If glibc 2.35 proves too disruptive to
compiling the distribution we could revert to 2.34, but given that
Rawhide has started tracking glibc 2.35, no show-stopper problems are
expected. At this point, we can still revert to upstream version 2.34
if insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency mechanism for gcc: If gcc 12 proves too disruptive to
compiling the distribution we could revert to gcc 11.
* Contingency deadline: Fedora mass rebuild on 2022-01-19.
* Blocks release? Yes, upgrading to the gcc 12 release blocks the
release. Yes, upgrading to glibc 2.35 does block the release.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU Compiler Collection version 12 is soon to be released. See
https://gcc.gnu.org/gcc-12/changes.html.
The GNU C Library version 2.35 will be released at the beginning of
August 2021. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
F36 Change: Django 4.0 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Django4.0
== Summary ==
Update Django to version 4.0.
== Owner ==
* Name: [[User:mrunge| Matthias Runge]]
* Email: mrunge(a)redhat.com
== Detailed Description ==
The Django project has regular releases about every 9 months. Django
4.0 is a major milestone, and this Change will
bring the Fedora included version to the latest version.
The immediate step is to bump the python-django package to version
4.0. It is expected, that dependent packages will be
updated as well, or retired, if they haven't seen an update for long time.
== Benefit to Fedora ==
This updates to the latest Django version and allows to use the
distribution provided version to be used both in new developments and
also with latest Django applications.
The upstream project has more info on what's new
https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/
The risk of not completing this change is that the next update will be
more disruptive, Django 4.1 is planned for about the same time as
Fedora 37 will land.
== Scope ==
* Proposal owners: python-django will be updated to version 4.0.
* Other developers:
Other developers or maintainers will have to test their packages with
Django 4.0.
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
The python3-django package has to be installed in order to run the test.
django-admin --version
4.0
== Dependencies ==
Django (the fedora package name is python-django) has a few dependent
packages which should get updated (or removed) as noted above. If they
were not updated for Django 4.0, that probably means that their
upstream is not very active anymore.
== 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 (not a System Wide Change)
== Documentation ==
Extensive upstream documentation can be found at
https://docs.djangoproject.com/en/4.0/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
F36 Change proposal: No ifcfg by default (Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/NoIfcfgFiles
== Summary ==
Do not not include NetworkManager support for legacy network
configuration files by in new installations.
== Owner ==
* Name: [[User:Lkundrak| Lubomir Rintel]]
* Email: <lkundrak(a)v3.sk>
* Name: Ana Cabral
* Email: <acabral(a)redhat.com>
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller(a)redhat.com>
== Detailed Description ==
Long ago, network was configured using "network" service.
It was essentially a set of shell scripts, that sourced snippets of
configuration from `/etc/sysconfig/network-scripts/ifcfg-*` ("ifcfg
files").
The ifcfg files compatible with the legacy network service were kept
when NetworkManager was intruduced.
As the NetworkManager feature set was expanding beyond what the legacy
network service could support,
the ifcfg files written by NetworkManager could no longer be
guarranteed to be compatible.
NetworkManager eventually gained support for connection types
completely unknown to the legacy network service
and ended up using a more streamlined configuration file format for
those, known as keyfile.
NetworkManager's use of various configuration files is, in fact,
configurable and extensible with plugins.
Prior to Fedora 33, NetworkManager by default was configured to enable
both ifcfg files and keyfiles, with the former taking precedence when
possible.
The precedence changed in
[https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_...
Fedora 33] to perfer keyfile.
The precedence has an effect when a network connection profile is created.
Once the connection profile exists, NetworkManager is unable to
convert the profile to a different configuration backend.
This makes it necessary for NetworkManager to support the same feature
set in all configuration backend.
Given the complexities stemming from historical legacy of ifcfg files
not being designed (or documented) in a
particularly forward-looking way, this has been a huge and complex
effort with all the downsides:
The ifcfg support code is huge (130K lines, not counting the enormous
test suite) and has constantly been a source of bugs.
== Benefit to Fedora ==
This change removes a body of code that has a large cost in terms of
bugs and maintenance at questionable benefit.
It slightly reduces the default installation size.
== Scope ==
* Proposal owners: Split the ifcfg plugin into a subpackage package.
Make sure the ifcfg plugin stays on upgrades. Provide a migration
tool.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
For the time being the ifcfg plugin is kept around, albeit in a
sub-package that's not included in new installations.
The appropriate RPM tags will ensure the sub-package with the ifcfg
plugin will be installed on upgrades.
A migration tool will be provided for users who'd like to remove the
legacy package from their systems after upgrade.
== How To Test ==
N/A.
The keyfiles are used by default in Fedora 33 already, so any problem
with them would've already been spotted.
== User Experience ==
Regular users will not notice anything.
Users of old installations with ifcfg files will get the new
sub-package on upgrade.
New systems will default to use keyfiles, which is not something
regulars user would notice.
System integrators and administrators might use tools that drop in
ifcfg files during automated installations (e.g. via kickstart or a
configration management tool).
They will need to update their tools -- convert the ifcfg files to
keyfiles or include the ifcfg sub-package.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: If it turns out we can't drop support for
ifcfg files by default, we can either fold the ifcfg sub-package back
into the main NetworkManager package or make sure it is included in
new installations (via comps change).
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
We'll need to write the documentation for the migration tool.
Perhaps also something the sysadmins wondering why their ifcfg files
don't work anymore could find and refer to.
TODO: Update this once it's done.
== Release Notes ==
We'll need to include a paragraph about this in the release notes.
TODO: Update this with the actual release note text.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 3 months
A handful of orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-01-03.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
apache-rat mizdebsk, orphan 0 weeks ago
cptutils orphan 2 weeks ago
dans-gdal-scripts orphan 2 weeks ago
direvent orphan 5 weeks ago
e00compr orphan 2 weeks ago
esniper orphan 2 weeks ago
fkill-cli orphan 1 weeks ago
fx orphan 1 weeks ago
fx-completion orphan 1 weeks ago
icedtea-web jvanek, omajid, orphan 4 weeks ago
jakarta-saaj orphan 0 weeks ago
jakarta-xml-ws orphan 0 weeks ago
jmock orphan 0 weeks ago
js-termynal orphan 4 weeks ago
nodejs-svgo nodejs-sig, orphan 1 weeks ago
npm-name-cli orphan 1 weeks ago
perl-Net-HL7 orphan 1 weeks ago
python-jenkins-job-builder ignatenkobrain, ktdreyer, orphan, 2 weeks ago
pabelanger
python-productivity orphan 5 weeks ago
ravada orphan 3 weeks ago
rubygem-rsolr orphan 1 weeks ago
rust-biscuit orphan 3 weeks ago
rust-signature orphan 5 weeks ago
siril astro-sig, lkundrak, lupinix, 1 weeks ago
orphan
topojson-client orphan 1 weeks ago
topojson-server orphan 1 weeks ago
topojson-simplify orphan 1 weeks ago
uddi4j galileo, orphan 4 weeks ago
uml_utilities chkr, orphan 0 weeks ago
wsil4j galileo, orphan 4 weeks ago
xcf-pixbuf-loader orphan 3 weeks ago
The following packages require above mentioned packages:
Depending on: e00compr (1), status change: 2021-12-13 (2 weeks ago)
saga (maintained by: volter)
saga-7.6.1-10.fc36.src requires e00compr-devel = 1.0.1-25.fc35
Depending on: fx (1), status change: 2021-12-22 (1 weeks ago)
fx-completion (maintained by: orphan)
fx-completion-1.0.5-5.fc36.noarch requires npm(fx) = 20.0.2
fx-completion-1.0.5-5.fc36.src requires npm(fx) = 20.0.2
Depending on: jakarta-saaj (2), status change: 2022-01-02 (0 weeks ago)
jakarta-xml-ws (maintained by: orphan)
jakarta-xml-ws-2.3.1-3.fc35.noarch requires mvn(javax.xml.soap:saaj-api) = 1.4.2
jakarta-xml-ws-2.3.1-3.fc35.src requires mvn(javax.xml.soap:saaj-api) = 1.4.2
jmock (maintained by: orphan)
jmock-2.12.0-4.fc35.src requires mvn(javax.xml.ws:jaxws-api) = 2.3.1
Depending on: jakarta-xml-ws (1), status change: 2022-01-02 (0 weeks ago)
jmock (maintained by: orphan)
jmock-2.12.0-4.fc35.src requires mvn(javax.xml.ws:jaxws-api) = 2.3.1
Depending on: uddi4j (1), status change: 2021-12-02 (4 weeks ago)
wsil4j (maintained by: galileo, orphan)
wsil4j-1.0-25.fc35.noarch requires mvn(org.uddi4j:uddi4j) = 2.0.5,
osgi(org.uddi4j) = 2.0.5
wsil4j-1.0-25.fc35.src requires uddi4j = 2.0.5-25.fc35
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
astro-sig: siril
chkr: uml_utilities
galileo: wsil4j, uddi4j
ignatenkobrain: python-jenkins-job-builder
jvanek: icedtea-web
ktdreyer: python-jenkins-job-builder
lkundrak: siril
lupinix: siril
mizdebsk: apache-rat
nodejs-sig: nodejs-svgo
omajid: icedtea-web
pabelanger: python-jenkins-job-builder
volter: e00compr
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
2 years, 3 months