devel-announce October 2022

devel-announce@lists.fedoraproject.org

3 participants
16 discussions

Orphaned packages looking for new maintainers
by Miro Hrončok 31 Oct '22

31 Oct '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-10-31.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 ================================================================================ Falcon orphan 4 weeks ago adapta-backgrounds atim, orphan 1 weeks ago bottles atim, orphan 0 weeks ago capstone orphan, rebus, ret2libc 4 weeks ago containerd copperi, go-sig, gotmax23, 1 weeks ago orphan dillo aarem, atim, orphan 3 weeks ago fragments atim, orphan 3 weeks ago geompp orphan 6 weeks ago giada orphan 6 weeks ago gnome-feeds atim, orphan 3 weeks ago golang-github-anaskhan96-soup atim, go-sig, orphan 3 weeks ago golang-github-beevik-etree go-sig, mgoodwin, nathans, 5 weeks ago orphan golang-github-crewjam-httperr go-sig, mgoodwin, nathans, 6 weeks ago orphan golang-github-crewjam-saml go-sig, mgoodwin, nathans, 6 weeks ago orphan golang-github-dchest-uniuri go-sig, mgoodwin, nathans, 6 weeks ago orphan golang-github-hajimehoshi-mp3 atim, go-sig, orphan 3 weeks ago golang-github-hajimehoshi-oto atim, go-sig, orphan 3 weeks ago golang-github-logr-stdr eclipseo, go-sig, orphan 5 weeks ago golang-github-magefile-mage go-sig, mgoodwin, nathans, 5 weeks ago orphan golang-github-russellhaering- go-sig, mgoodwin, nathans, 6 weeks ago goxmldsig orphan golang-github-timberio-datemath go-sig, mgoodwin, nathans, 5 weeks ago orphan golang-github-tonistiigi- go-sig, orphan 1 weeks ago opentelemetry-contrib golang-github-ua-parser-uap go-sig, mgoodwin, nathans, 5 weeks ago orphan golang-modernc-ql go-sig, orphan 2 weeks ago gydl atim, orphan 3 weeks ago howl atim, orphan 3 weeks ago llvm11.0 orphan, tstellar 3 weeks ago moby-engine copperi, go-sig, gotmax23, 1 weeks ago orphan nautilus-search-tool orphan 6 weeks ago python-APScheduler orphan, zuul 4 weeks ago python-PyRSS2Gen orphan 3 weeks ago python-charon orphan 5 weeks ago python-hbmqtt orphan 6 weeks ago python-hs-dbus-signature ignatenkobrain, jbaublitz, 4 weeks ago orphan python-pecan-notario orphan 4 weeks ago python-phyghtmap orphan 0 weeks ago python-pycdlib orphan 4 weeks ago qextserialport orphan 0 weeks ago rubygem-POpen4 orphan 2 weeks ago rubygem-Platform orphan 2 weeks ago rubygem-arel orphan 2 weeks ago rust-base100 orphan, rust-sig 3 weeks ago rust-dutree orphan, rust-sig 3 weeks ago rust-heatseeker orphan, rust-sig 3 weeks ago rust-jql orphan, rust-sig 3 weeks ago rust-pommes orphan, rust-sig 3 weeks ago rust-procs orphan, rust-sig 3 weeks ago rust-tealdeer orphan, rust-sig 3 weeks ago rust-varlink-cli orphan, rust-sig 3 weeks ago rust-zoxide orphan, rust-sig 3 weeks ago saga orphan 0 weeks ago slv2 orphan, slaanesh 4 weeks ago xchm orphan, wolfy 2 weeks ago The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2022-10-31.txt 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): aarem: dillo adamwill: capstone adimania: moby-engine akoutsou: capstone amoralej: capstone anthr76: containerd, golang-github-logr-stdr apevec: capstone astepano: moby-engine, capstone atim: golang-github-anaskhan96-soup, gydl, gnome-feeds, howl, bottles, golang-github-hajimehoshi-oto, dillo, fragments, adapta-backgrounds, golang-github-hajimehoshi-mp3 bcl: capstone berrange: capstone bonzini: capstone buckaroogeek: containerd, golang-github-logr-stdr cleber: python-pycdlib clumens: capstone copperi: moby-engine, containerd, golang-github-logr-stdr copr-sig: capstone crobinso: capstone dcantrell: capstone dcavalca: containerd, golang-github-logr-stdr ddd: capstone dnglaze: capstone dperpeet: moby-engine, capstone dshea: capstone dturecek: capstone eclipseo: capstone, containerd, golang-github-logr-stdr elmarco: containerd, golang-github-logr-stdr eparis: containerd, golang-github-logr-stdr epel-packagers-sig: capstone ericb: capstone etrunko: capstone f1ash: capstone fpokorny: containerd frostyx: capstone gicmo: capstone go-sig: golang-github-beevik-etree, golang-github-anaskhan96-soup, golang-modernc-ql, golang-github-magefile-mage, golang-github-tonistiigi-opentelemetry-contrib, capstone, golang-github-russellhaering-goxmldsig, containerd, golang-github-crewjam-saml, golang-github-hajimehoshi-oto, moby-engine, golang-github-ua-parser-uap, golang-github-dchest-uniuri, golang-github-logr-stdr, golang-github-timberio-datemath, golang-github-crewjam-httperr, golang-github-hajimehoshi-mp3 gotmax23: moby-engine, containerd, golang-github-logr-stdr hno: capstone hobbes1069: capstone ignatenkobrain: python-hs-dbus-signature imcleod: capstone infra-sig: containerd jamatos: python-PyRSS2Gen jbaublitz: python-hs-dbus-signature jchaloup: containerd, golang-github-logr-stdr jforbes: capstone jkastner: capstone jsnow: python-pycdlib juergh: capstone kde-sig: capstone kevin: capstone kkoukiou: capstone laine: capstone larsu: capstone libvirt-maint: capstone lnie: capstone lsm5: moby-engine, containerd, golang-github-logr-stdr martinpitt: capstone mattia: containerd maxamillion: python-PyRSS2Gen mcascella: capstone mdbooth: capstone merlinm: moby-engine, python-pycdlib, capstone mgoodwin: golang-github-beevik-etree, golang-github-magefile-mage, golang-github-russellhaering-goxmldsig, golang-github-crewjam-saml, golang-github-ua-parser-uap, golang-github-dchest-uniuri, golang-github-timberio-datemath, golang-github-crewjam-httperr mikem: capstone mikep: capstone mmarusak: capstone myoung: capstone nathans: golang-github-beevik-etree, golang-github-magefile-mage, golang-github-russellhaering-goxmldsig, golang-github-crewjam-saml, golang-github-ua-parser-uap, golang-github-dchest-uniuri, golang-github-timberio-datemath, golang-github-crewjam-httperr ngompa: capstone obudai: capstone ochosi: capstone olem: containerd, golang-github-logr-stdr openstack-sig: capstone osbuild-sig: capstone packit: capstone praiskup: capstone puiterwijk: capstone quintela: capstone qulogic: capstone raphgro: capstone rebus: capstone ret2libc: capstone rjones: capstone rmattes: capstone rust-sig: rust-base100, rust-jql, rust-procs, rust-pommes, rust-tealdeer, rust-zoxide, rust-dutree, rust-varlink-cli, rust-heatseeker slaanesh: slv2 slagle: capstone slp: capstone strigazi: containerd, golang-github-logr-stdr tdecacqu: capstone tlavocat: capstone tomegun: capstone tstclair: containerd, golang-github-logr-stdr tstellar: llvm11.0 vascom: capstone veillard: capstone virtmaint-sig: capstone wolfy: xchm wwoods: capstone yanqiyu: containerd zbyszek: capstone zuul: capstone, python-APScheduler -- 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 Report finished at 2022-10-31 11:14:17 UTC

1 0

Fedora Linux 37 Final is NO-GO
by Ben Cotton 28 Oct '22

28 Oct '22

Due to outstanding blocker bugs[1], F37 Final release candidate 3 was declared NO-GO. Because of the upcoming OpenSSL critical vulnerability disclosure, we are pushing the next target date out a week. See the Fedora Magazine article[2] for more information. The next Fedora Linux 37 Final Go/No-Go meeting[3] will be held at 1700 UTC on Thursday 10 November in #fedora-meeting. We will aim for the "target date #3" milestone of 15 November. The release schedule[4] has been updated accordingly. Minutes[5] and full logs[6] are available on Meetbot. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://fedoramagazine.org/fedora-linux-37-update/ [3] https://calendar.fedoraproject.org/meeting/10360/ [4] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [5] https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no… [6] https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no… -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F39 proposal: Python 3.12 (System-Wide Change proposal)
by Ben Cotton 25 Oct '22

25 Oct '22

https://fedoraproject.org/wiki/Changes/Python3.12 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the Python stack in Fedora from Python 3.11 to Python 3.12, the newest major release of the Python programming language. == Owner == * Name: [[User:Thrnciar|Tomáš Hrnčiar]] * Name: [[User:Churchyard|Miro Hrončok]] * Email: python-maint(a)redhat.com == Detailed Description == We would like to upgrade Python to 3.12 in Fedora 39 thus we are proposing this plan early. See the upstream notes at [https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12] and [https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12]. === Important dates and plan === * 2022-05-08: Python 3.12 development begins * 2022-10-24: Python 3.12.0 alpha 1 ** Package it as {{package|python3.12}} for testing purposes ** Start the bootstrap procedure in Copr ** Do a mass rebuild against every future release in Copr * 2022-11-14: Python 3.12.0 alpha 2 * 2022-12-05: Python 3.12.0 alpha 3 * 2023-01-09: Python 3.12.0 alpha 4 * 2023-02-06: Python 3.12.0 alpha 5 * 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39 ** The earliest point when we can start rebuilding in Koji side-tag * 2023-03-06: Python 3.12.0 alpha 6 * 2023-04-03: Python 3.12.0 alpha 7 * 2023-05-08: Python 3.12.0 beta 1 ** No new features beyond this point * 2023-05-29: Python 3.12.0 beta 2 ** The ideal point when we can start rebuilding in Koji * 2023-06-05: Expected side tag-merge (optimistic) * 2023-06-19: Python 3.12.0 beta 3 * 2023-06-26: Expected side tag-merge (realistic) * 2023-07-10: Python 3.12.0 beta 4 * 2023-07-17: Expected side tag-merge (pessimistic) * 2023-07-19: Fedora 39 Mass Rebuild ** The mass rebuild happens with the fourth beta. We might need to rebuild Python packages later in exceptional case. ** If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 38. * 2023-07-31: Python 3.12.0 candidate 1 ** This serves as "final" for our purposes. * 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40 * 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable) * 2023-08-22: Fedora Beta Freeze ** If rebuild with 3.12.0rc1 is needed, we should strive to do it before the freeze - there is a window of 3 weeks. * 2023-09-04: Python 3.12.0 candidate 2 * 2023-09-12: Fedora 39 Beta Release (Preferred Target) ** Beta will likely be released with 3.12.0rc2. * 2023-09-19: Fedora 39 Beta Target date #1 * 2023-10-02: Python 3.12.0 final * 2023-10-03: Fedora 39 Final Freeze ** We'll update to 3.12.0 final using a freeze exception. * 2023-10-17: Fedora 39 Preferred Final Target date * 2023-10-24: Fedora 39 Final Target date #1 (From [https://peps.python.org/pep-0693/#release-schedule Python 3.12 Release Schedule] and [https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html Fedora 39 Release Schedule].) The schedule might appear somewhat tight for Fedora 39, but Python's [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… annual release cycle was adapted for Fedora] and this worked fine since Python 3.9 and Fedora 33. It is now common that Python is upgraded on a similar schedule in every odd-numbered Fedora release. Note that upstream's "release candidates" are frozen except for blocker bugs. Since we can and will backport blocker fixes between Fedora and upstream, we essentially treat the Release Candidate as the final release. === Notes from the previous upgrade === There are notes from the previous upgrade available, so this upgrade may go smoother: [[SIGs/Python/UpgradingPython]] == Benefit to Fedora == Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.12. There's also a benefit to the larger Python ecosystem: by building Fedora's packages against 3.12 while it's still in development, we can catch critical bugs before the final 3.12.0 release. == Scope == We will coordinate the work in a side tag and merge when ready. * Proposal owners: *# Introduce {{package|python3.12}} for all Fedoras *# Prepare stuff in Copr as explained in description. *# Update {{package|python-rpm-macros}} so {{package|python3.12}} builds {{package|python3}} *# Build {{package|python3.12}} as the main Python *# Mass rebuild all the packages that runtime require `python(abi) = 3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October 2022) *# Build {{package|python3.12}} as a non-main Python * Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: [https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12 Porting to Python 3.12]. The python-maint team will be available to help with fixing issues. * Release engineering: [TBD] * Policies and guidelines: nope * Trademark approval: nope == Upgrade/compatibility impact == All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.11 is forward compatible with Python 3.12. === The Python standard library distutils module will be removed === For many years distutils module was providing support for building and installing additional modules into a Python installation. Since Python 3.10 distutils package is deprecated, and will be removed in Python 3.12. Its functionality for specifying package builds has already been completely replaced by third-party packages setuptools and packaging, and most other commonly used APIs are available elsewhere in the standard library (such as platform, shutil, subprocess or sysconfig). Affected packages will be failing with `ModuleNotFoundError: No module named 'distutils'`. The python3-setutpools package provides a distutils module, so sometimes "simply" adding BuildRequires: python3-setuptools might workaround the problem. Unfortunately, it is not 100 % compatible with the removed standard library one distutils: https://github.com/pypa/setuptools/issues/3532 Fedora packagers can check if their packages build without distutils by removing it form Python 3.11: # `fedpkg clone <package name> && cd <package name>` # `mock -r fedora-rawhide-x86_64 init` # `mock -r fedora-rawhide-x86_64 install python3-devel` # `sudo rm -rf /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/` # `fedpkg mockbuild -N` Later, when [https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ Python 3.12 COPR] is available, you can use it for testing. See https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj… for known Fedora packages that'll need changes. == How To Test == Interested testers do not need special hardware. If you have a favourite Python 3 script, module, or application, please test it with Python 3.12 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using {{package|python3.12}} even before this change is implemented, in Fedora 36, 37 or 38. In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.12 version of the python3 rpm. Right now that rpm is available in copr, along with all other python packages that build successfully with python 3.12. See https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for detailed instructions on how to enable Python 3.12 copr for mock. Once the change is in place, test if your favourite Python apps are working as they were before. File bugs if they don't. == User Experience == Regular distro users shouldn't notice any change in system behaviour other than the Python 3 interpreter will be in version 3.12. == Dependencies == 4000+ packages depend on Python 3 and ~3900 packages need rebuilding when Python is upgraded. See scope section. == Contingency Plan == * Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.11 version (never needed before) * Contingency deadline: TBD * Blocks release? Yes, we'd like to block Fedora 39 release on at least 3.12.0rc1 * Blocks product? See above == Documentation == [https://peps.python.org/pep-0693/ Python 3.12 Release Schedule] [https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12] [https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12] [https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12 Porting to Python 3.12] == Release Notes == * Migrating user installed packages - https://pagure.io/fedora-docs/release-notes/issue/503 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
by Ben Cotton 25 Oct '22

25 Oct '22

https://fedoraproject.org/wiki/Changes/PortingToModernC. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Back in 1999, a new revision of the C standard removed several backwards compatibility features. However, GCC still accepts these obsolete constructs by default. Support for these constructs is confusing to programmers and potentially affect GCC's ability to implement features from future C standards. == Owner == * Name: [[User:fweimer| Florian Weimer]] * Email: [mailto:fweimer@redhat.com| fweimer(a)redhat.com] == Detailed Description == The most important change is the <b>removal of implicit function declarations</b>. This legacy compatibility feature causes the compiler to automatically supply a declaration of type `int function()` if `function` is undeclared, but called as a function. However, the implicit return type of `int` is incompatible with pointer-returning functions, which can lead to difficult debugging sessions if the compiler warning is missed, as described here: * [https://developers.redhat.com/blog/2019/04/22/implicit-function-declaration… Implicit function declarations: flex's use of "reallocarray"] On x86-64, functions returning `_Bool` called with an implicit declaration will also not work correctly because the return register value for `_Bool` functions is partially undefined (not all 32 bits in the implicitly declared `int` are defined). Another change for C99 is the <b>removal of implicit `int` type declarations</b>. For example, in the following fragment, both `i` and `j` are defined as `int` variables: <pre> static i = 1.0; auto j = 2.0; </pre> Support for this obsolete constructs is incompatible with adoption of type inference for `auto` definitions (which are part of C++). Neither change is trivial to implement because introducing errors for these constructs (as required by C99) alters the result of autoconf configure checks. Quite a few such checks use an implicitly declared `exit` function, for instance. These failures are not really related to the feature under test. If the build system is well written, the build still succeeds, the relevant features are automatically disabled in the test suite and removed from reference ABI lists, and it's not immediately apparent that feature is gone. Therefore, some care is needed that no such alterations happen, and packages need to be ported to C99. Various tools for this porting activity are being developed to support this proposal. Cross-distribution collaboration will help as well, sharing patches and insights. GCC 14 may also make other changes by default, as described below. These changes will also require extensive testing, and some adoption of configure checks. ==== Removal of old-style function definitions ==== An old style function definition looks like this: <pre> int sum (a, b) char *a; int b; { return atoi (a) + b; } </pre> It is equivalent to this definition with a prototype: <pre> int sum (char *a, int b) { return atoi (a) + b; } </pre> This legacy feature is very close to being incompatible with the C2X standard, which introduces unnamed function arguments. But due to a quirk in GCC's implementation, it should be possible to support both at the same time. ==== New keywords <code>bool</code>, <code>true</code>, <code>false</code> ==== Packages which supply their own definitions instead of including `<stdbool.h>` (which remains available) might fail to build. ==== Change of meaning of <code>()</code> in function declarators ==== In earlier C versions, a declaration `int function()` declares `function` as accepting an unspecified number of arguments of unknown type. This means that both `function(1)` and `function("one")` compile, even though they might not work correctly. In a future C standard, `int function()` will mean that `function` does not accept any parameters (like in C++, or as if written as `int function(void)` in current C). Calls that specify parameters will therefore result in compilation errors. We believe that this change is ABI-compatible, even on ppc64le (with its parameter save area), although it comes very close to an implicit ABI break. ==== Rejecting implicit conversions between integers and pointers as errors ==== Currently, GCC does not treat conversion between integers at pointers as errors, so this compiles: <pre> int ptr = "string"; </pre> However, this is very unlikely to work on 64-bit architectures (it may work by accident without PIE/PIC). == Feedback == The transition plan has been discussed at various GNU Tools Cauldrons. Feedback has been generally positive, except a general worry about the work required. Without a deliberate porting effort, a lot of breakage occurs, [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… seen in 2016 in Fedora with an uncoordinated change], and more recently [https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-… an uncoordinated Clang update]. == Benefit to Fedora == Programmers will no longer waste time tracking down things that look eerily like compiler or ABI bugs because in several cases, builds will fail with a clear error message, instead of producing a warning that is easily missed. Potential blockers to adoption of further C language changes are removed. == Scope == * Proposal owners: Update rawhide over time to be compatible with strict C99 compilers. * Other developers: Help out with non-obvious porting issues, and with upstreaming patches in case active upstreams cannot be easily identified. Tolerate early backports of upstream-submitted fixes in Fedora dist-git. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Fedora compiler policy will likely change due to the adoption of GCC 14 in Fedora 40. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == The change is expected to be transparent to those users who do not use C compilers. No features are supposed to be added or removed as a result. In fact, most of the porting effort focuses on avoiding configuration changes. == How To Test == General regression testing is sufficient. == User Experience == User experience does not change. == Dependencies == To avoid regressing the porting effort, GCC as the system compiler needs to reject obsolete constructs by default. This is expected for GCC 14, to be released as part of Fedora 40 in Spring 2024. == Contingency Plan == * Contingency mechanism: Upstream GCC will probably accept obsolete constructs longer in case distributions like Fedora cannot port to modern C in time. * Blocks release? No if GCC doesn't switch. If GCC switches, we have to complete the port. == Documentation == This section will be updated once more documentation of the porting effort will become available. == Release Notes == Probably not needed because no user visible impact is intended. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 37 Final is NO-GO
by Ben Cotton 20 Oct '22

20 Oct '22

Due to outstanding blocker bugs[1], F37 Final release candidate 2 was declared NO-GO. The next Fedora Linux 37 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 27 October in #fedora-meeting. We will aim for the "target date #2" milestone of 1 November. The release schedule[3] has been updated accordingly. Logs and minutes are not available in Meetbot because Zodbot failed halfway through, but I have uploaded my local logs to the Internet Archive[4]. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://calendar.fedoraproject.org/meeting/10352/ [3] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [4] https://archive.org/download/37-final-go-no-go-meeting.-2022-10-20-17.13.lo… -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Reminder: F37 Final G/No-Go meeting Thursday
by Ben Cotton 19 Oct '22

19 Oct '22

The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 20 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Final for the 25 October target date #1[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 2 accepted and 1 proposed release blocker bugs[4]. [1] https://calendar.fedoraproject.org/meeting/10352/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Modernize Live Media (System-Wide Change proposal)
by Ben Cotton 18 Oct '22

18 Oct '22

https://fedoraproject.org/wiki/Changes/ModernizeLiveMedia This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Modernize the live media by switching to the "new" live environment setup scripts provided by {{package|livesys-scripts}} and leverage new functionality in {{package|dracut}} to enable support for automatically enabling persistent overlays when flashed to USB sticks. == Owner == * Name: [[User:Ngompa|Neal Gompa]], [[User:Mcoleman|Matt Coleman]] * Email: ngompa13(a)gmail.com, matt(a)1eanda.com == Detailed Description == As part of preparing to change our tooling around producing images, we need to update the way we produce working live media. This has been done in two parts: the live environment setup scripts have been reworked to run properly through systemd and are packaged in {{package|livesys-scripts}} and new functionality in {{package|dracut}} has been added to enable support for automatically enabling persistent overlays when flashed to USB sticks so that <code>livecd-iso-to-disk.sh</code> can be retired. == Benefit to Fedora == Since we introduced [[Releases/FeatureLiveCD|live media in Fedora Linux 7]], the actual mechanism in which the live environment sets itself up has been complex and intricately tied to the method in which we produce the media (using Kickstarts). The nature of the implementation of those scripts means that they are hard to understand and debug, which has caused problems in the past whenever we've needed to update them. As we look forward to new and better tooling for producing images (such as {{package|kiwi}} and {{package|osbuild}}), we cannot continue to rely on kickstart-driven image builds that construct shell scripts on the fly to embed in the image as we do now. With {{package|livesys-scripts}}, those scripts have been simplified and turned into systemd services that activate only in live environments. This also gives us the opportunity to introduce new functionality for live media. [https://github.com/dracutdevs/dracut/pull/1991 New functionality was added to dracut] and [https://src.fedoraproject.org/rpms/dracut/pull-request/26 backported to Fedora] so that we can retire the remaining usage of <code>livecd-iso-to-disk.sh</code> and provide a better experience with our live media, particularly for portable backup and rescue environments by introducing the ability to automatically setup persistence on boot when unpartitioned space is detected on a USB stick on boot. == Scope == * Proposal owners: ** Modify [https://pagure.io/fedora-kickstarts fedora-kickstarts] to drop embedded livesys setup scripts and use {{package|livesys-scripts}} ** Add <code>livesys.service</code> and <code>livesys-late.service</code> to the systemd presets in {{package|fedora-release}} ** [https://src.fedoraproject.org/rpms/dracut/pull-request/26 Backport <code>dmsquash-live-autooverlay</code> module] to {{package|dracut}} ** Modify [https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic lorax-generic-templates] to offer menu entries for configuring the persistent overlay * Other developers: ** Anaconda may need adaptations to correctly filter out more live environment specific boot arguments when configuring the installed environment. * Release engineering: [https://pagure.io/releng/issue/11091 #11091] * 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 == There should be no impact here, as this affects only the live environment. == How To Test == Once the changes are merged, simply try to boot produced live media. There should be new options for resetting the persistent overlay and booting with no persistence. The default options should boot with persistence and setup of persistence should work. Testing persistence behavior is simple: # Boot normally # Create a file in the home directory # Reboot into the environment # See the file is there still Testing the reset behavior would go similar to the regular test, except you should expect the file to not show up in step 4. Same for booting with no persistence. Otherwise, the media should work like before, and things like live installation should work as expected. == User Experience == When booting live media, two new menu options will become available: one to reset the persistent overlay while booting, and one to boot without persistence. The default boot options will create a persistent overlay if it doesn't exist and can be written (e.g. when booting from a USB stick). == Dependencies == * [https://pagure.io/fedora-kickstarts fedora-kickstarts] * {{package|anaconda}} * {{package|dracut}} * {{package|livesys-scripts}} * {{package|lorax}} == Contingency Plan == * Contingency mechanism: Revert changes to fedora-kickstarts and lorax to go back to previous behavior * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == Information on the persistent overlay functionality is included in the Dracut documentation. == Release Notes == By default, Fedora Linux live environments flashed to writable USB media with sufficient free space will maintain user changes to the environment. This "persistence" can be reset at boot time through the boot menu. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: LXQt image for aarch64 (Self-Contained Change proposal)
by Ben Cotton 14 Oct '22

14 Oct '22

https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Generate LXQt image (both iso and disk image) for aarch64 architecture. == Owner == * Name: [[User:Zsun|Zamir SUN]] * Email: zsun#AT#fedoraproject.org == Detailed Description == LXQt has moved out of 0.x version and is now 1.1.0, so I consider it to be a pretty stable desktop environment. Recently, 64bit ARM architecture is becoming more and more popular in laptops and workstations. By generating a LXQt image for aarch64 will offer aarch64 another easier option to evaluate and use Fedora. == Benefit to Fedora == Offers users of 64bit ARM architecture another desktop option that works out-of-the-box. == Scope == * Proposal owners: Nothing. The LXQt packages are already in the distribution. And the kickstart for generating LXQt image on x86_64 can be directly used. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/11086 11086] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Install using the ISO or the disk image on aarch64 system. The system should work as it should be by manually installing on top of any existing aarch64 system. == User Experience == Users of aarch64 systems should be able to directly install from LXQt ISO or disk image if they want to use LXQt. == Dependencies == We need to ask release engineering team to generate the image. == Contingency Plan == * Contingency mechanism: Just do not ship the newly generated image. * Contingency deadline: Fedora 38 Beta Freeze * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
by Ben Cotton 13 Oct '22

13 Oct '22

https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Continue the work done in https://fedoraproject.org/wiki/Changes/OstreeNativeContainer but in an officially stable format, and expanded to cover more OSTree-based editions. This goes "all in" on being container-native and significantly changes the technology and user emphasis. == Owner == * Name: [[User:walters| Colin Walters]], [[User:jmarrero| Joseph Marrero]], [[User:baude| Brent Baude]] * Email: walters(a)verbum.org, jmarrero(a)fedoraproject.org, baude(a)fedoraproject.org == Detailed Description == * rpm-ostree's functionality to [https://coreos.github.io/rpm-ostree/container/ boot and upgrade from Docker/OCI container images] is declared stable * Rework Fedora editions and spins (CoreOS, IoT, Silverblue, Kinoite, etc) that use ostree to instead deliver via Docker/OCI container images * `rpm-ostree` is reworked to gain strong CLI compatibility with `yum/dnf` commands (cliwrap) * The new container native functionality is exposed via `dnf image` * (TBD: Rebranding of rpm-ostree itself to `dnf-image` or something else) * Support and documentation for generating derived images * Support in Anaconda and other tools * Support for generating bootable images A top level goal is that users should not need to know or understand ostree (or rpm-ostree); they only need to know containers and most key functionality is exposed via the `yum/dnf` frontend with a few extensions. === Backwards compatibility === If you're a user of ostree today: no need to worry. Everything that works today in ostree and rpm-ostree will continue to work for years to come (it's shipped in RHEL9). However, it's expected that most users will find the new model sufficiently compelling to switch fairly quickly. === Stable Bootable OCI === More information about this is available in [https://coreos.github.io/rpm-ostree/container/ the rpm-ostree documentation]. This Change highlights that this functionality is planned to be officially stable. === Changing to OCI over the wire === Today Fedora has an OSTree repository that contains updates for editions such as Fedora CoreOS and Fedora Silverblue. These editions instead will become [https://github.com/opencontainers OCI base images], available at e.g. * `quay.io/fedora/fedora-coreos:stable` ([https://quay.io/repository/fedora/fedora-coreos this exists today]!) * `quay.io/fedora/fedora-silverblue:38` (does not exist, but can soon) An update will be shipped that will cause existing systems tracking the production ostree branches to be switched to the corresponding container image. Concretely for example, a system running `fedora:fedora/36/x86_64/silverblue` will execute `rpm-ostree rebase ostree-remote-registry:fedora:quay.io/fedora/fedora-silverblue:36`. Note that at the current time, Fedora does not sign container images. This should change (likely to something based on [cosign](https://github.com/containers/skopeo/pull/1701)) but in the mean time, the ostree-container flow supports verifying the embedded ostree-baesd GPG signatures and this will continue to be used. The Fedora OSTree repository will become read-only and stop receiving updates. Note that for Fedora CoreOS specifically, there is some outstanding design discussion around the intersection with Cincinnati: https://github.com/coreos/fedora-coreos-tracker/issues/1263 ==== Wire efficiency ==== Today the container images generated by rpm-ostree are "chunked" in a reproducible fashion; for more information on this, see * https://github.com/ostreedev/ostree-rs-ext/issues/69 * https://coreos.github.io/rpm-ostree/container/ However, longer term (as that first issue notes) we do want to add [https://github.com/containers/image/pull/902 container deltas]. Doing so will benefit non-host containers too. === dnf/yum CLI compatibility === rpm-ostree has a feature called [cliwrap](https://coreos.github.io/rpm-ostree/cliwrap/) today. A key motivation here is that in the switch to using containers as the frontend, the project name "rpm-ostree" (which is very literal) no longer makes sense. A further emphasis on "container native" will strongly encourage writing e.g. a `Dockerfile` like this: <pre> FROM quay.io/fedora/fedora-silverblue:stable RUN dnf -y install sway && ostree container commit </pre> *Today*, one can spell this as `RUN rpm-ostree install -y sway && ostree container commit` - but a toplevel goal here is to allow host system customization using the same patterns and tools one uses to build application containers, and to de-emphasize the "ostree backend" aspect. To complete this story on the client side, what is today called "ostree native containers" will be exposed via a new `dnf image` subcommand on the client system. For example: <pre> $ dnf image rebase quay.io/examplecorp/customos:latest </pre> As well as other offline/"image based" functionality such as `dnf image rollback` and `dnf image apply-live`. However, as many people know, rpm-ostree does today support "per-machine" package layering/overrides - and *that will continue to work*. So users are not *required* to do builds on a remote server even in "image mode". Concretely, it will also work to `sudo dnf -y install sway` inside a root terminal on a Fedora Workstation for example. This will still be a transactional operation. More: https://github.com/coreos/rpm-ostree/issues/2883 === Rebranding of rpm-ostree === This is a fundamental change in technology *and* positioning for rpm-ostree (and for the projects that use it). The terminology of "immutable" gets even fuzzier now (see also [this blog](https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionabl…) It would make sense to rebrand the project due to this. No decision has been made on this, but the choices are: - Keep as is - Rebrand to dnf-image (or, reviving a past name, yum-image) - Rebrand to something else More: https://github.com/coreos/rpm-ostree/issues/405 === Support for building derivative containers === Until now, the model for systems like Fedora CoreOS and Silverblue etc. has included an emphasis on containerization, but avoiding extensive customization of the host system. This will be weakened somewhat - it will be fully supported to build derivative operating system images that in turn contain software which itself should run directly on the host system, and not in a container. A key aspect of this is that by generating a custom build, one binds together the code and configuration as a transactionally updatable unit. The role of things like Kickstart, cloud-init, and Ignition and other system config management shrinks significantly. === Example 1: Kubernetes and kubelet === It is not supported upstream to run the kubelet in a container image itself. Today, for OpenShift 4 we embed the kubelet as part of the CoreOS builds. The [https://www.okd.io/ OKD] project [https://github.com/openshift/okd-machine-os/blob/fa2248d332abc9926e68428dc6… already installs kubelet during a container build] deriving from the base `fedora-coreos` image. It is possible that RHEL CoreOS will make [https://github.com/openshift/os/issues/799 a similar split]. === Example 2: Agent software === Many organizations require agents (cloud agents, security scanners, antivirus) which are not ready to be containerized. Often too, these tools come in e.g. RPM form, and also expect to be configured (remote logging server, etc.). This tooling allows to `dnf install` these *and* embed the configuration, generating a standard container image which can then be booted as an atomic unit. (Note that in the OpenShift context, we expect this to chain with the first example - users instead derive from a `okd-node-base` image which itself derives from `fedora-coreos`). === Example 3: Podman machine === The `[http://podman.io Podman]` project has a function called `[https://github.com/containers/podman/blob/main/docs/source/markdown/podman-machine.1.md machine]` where it creates a virtual machine and boots standard CoreOS builds. Podman developers and users has long desired a custom FCOS image that is focused on container deployment using Podman, including certain QEMU packages that allow for cross-architecture development. This approach will solve a series of problems including but not limited to getting more timely release alignment between Podman and FCOS. We also have a user base that wants to customize the VM image based on restrictive environments ... bring your own virtual machine image. === Support in Anaconda and other tools === Anaconda support for custom images is tracked in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=2125655 But, as part of this Change, it should also work to generate an Anaconda ISO which allows *user choice* for whether to install in "image mode" or "traditional". === Support for generating bootable images === Instead of using an existing disk image/ISO (Anaconda, AWS AMI, etc.) and then doing an in-place update to a generated container image, in many cases will want to generate disk images using their container image as input. For example, generating an ISO that embeds that container image as input and will install it. In this proposal, we plan to ship a container image as part of Fedora CoreOS that will do this: https://github.com/coreos/fedora-coreos-tracker/issues/1151 But, it also makes sense to have a tool that e.g. does this and generates an Anaconda ISO (we will inherently be doing this as part of generating ostree-based Anaconda ISOs already!) - this would just be supporting that in a clear external way too. One likely target for this is [https://github.com/osbuild osbuild] and [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/ht… RHEL Image Builder]. == Feedback == == Benefit to Fedora == The need to understand ostree goes away for most users; they understand RPMs and containers. While retaining all the current (rpm-)ostree features. == Scope == * Proposal owners: * Other developers: May affect e.g. gnome-software and similar tools that talk to rpm-ostree. * Release engineering: [https://pagure.io/releng/issue/11047] * Policies and guidelines: None. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: None == Upgrade/compatibility impact == We will ship a systemd unit that transitions systems currently using OSTree on the wire over to tracking the corresponding container images. Note again, all features of rpm-ostree continue to work! For example, if you have layered packages, that will continue to be applied. == How To Test == Build container images, boot them. == User Experience == Users will not need to understand ostree (at least at a superficial level), only container images. == Dependencies == Needs improvements in Anaconda in some cases, also would like to increase alignment with dnf. Fetching container images uses `skopeo`, maintained by containers team. == Contingency Plan == * Contingency mechanism: Continue to ship things the way we ship them today * Contingency deadline: Dunno * Blocks release? No == Documentation == https://coreos.github.io/rpm-ostree/container/ and https://github.com/coreos/coreos-layering-examples etc. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 37 Final is NO-GO
by Ben Cotton 12 Oct '22

12 Oct '22

Due to outstanding blocker bugs[1], we do not have a current release candidate. As a result, Fedora Linux 37 Final is NO-GO. The next Fedora Linux 37 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 20 October in #fedora-meeting. We will aim for the "target date #1" milestone of 25 October. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://calendar.fedoraproject.org/meeting/10352/ [3] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce October 2022