devel-announce January 2022

devel-announce@lists.fedoraproject.org

6 participants
25 discussions

F36 Change: New requirements for akmods binary kernel modules for Silverblue / Kinoite support (Self-Contained Change proposal)
by Ben Cotton 07 Jan '22

07 Jan '22

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

1 0

F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
by Ben Cotton 05 Jan '22

05 Jan '22

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 ==  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

1 0

F36 Change: Django 4.0 (Self-Contained Change proposal)
by Ben Cotton 05 Jan '22

05 Jan '22

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

1 0

F36 Change proposal: No ifcfg by default (Self-Contained Change)
by Ben Cotton 05 Jan '22

05 Jan '22

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_if… 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 1

A handful of orphaned packages looking for new maintainers
by Miro Hrončok 03 Jan '22

03 Jan '22

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2022