devel-announce December 2022

devel-announce@lists.fedoraproject.org

5 participants
31 discussions

Automation of Fedora SCM requests
by Michal Konecny 10 Jan '23

10 Jan '23

Hello everyone, for some time CPE (Community Platform Engineering) team is working on automating Fedora SCM requests [0]. The automation is currently live on staging. You can see the output (closed tickets) in Fedora SCM requests staging repo [1]. The automation is done using a plugin in toddlers [2]. We have a documentation [3] for the new toddler, if you want to know more about it. There is also a ticket [4] tracking this work. We plan to deploy this in production on *10th January 2023*, after that all the Fedora SCM request will be processed automatically and it will ping correct people if the manual intervention is needed. This will not change anything in user workflow, it will just make the job of Fedora Release Engineering Team easier and let them focus on other things. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests [1] - https://stg.pagure.io/releng/fedora-scm-requests [2] - https://pagure.io/fedora-infra/toddlers [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs [4] - https://pagure.io/releng/issue/9274

1 3

F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
by Ben Cotton 05 Jan '23

05 Jan '23

https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes 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 == The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. When an RPM package is built, mtimes of packaged files will be clamped to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest `%changelog` entry. As a result, more RPM packages will be reproducible: The actual modification time of files that are e.g. modified in the `%prep` section or built in the `%build` section will not be reflected in the resulting RPM packages. Files in RPM packages will have mtimes that are independent of the time of the actual build. == Owner == * Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]] * Email: mhroncok at redhat.com, zbyszek at in.waw.pl == Detailed Description == This change exists to make RPM package builds more reproducible. A common problem that prevents [https://reproducible-builds.org/ build reproducibility] is the mtime (modification times) of the packaged files. Suppose we package an RPM package of software called `skynet` in version `1.0`. Upstream released this version at datetime A. A Fedora packager creates the RPM package at datetime B. Unfortunately, the packager needs to patch the sources in the RPM `%prep` section. When the build runs at datetime C, the modification datetime of the patched file is set to C. When the build runs again in an otherwise identical environment at datetime D, the modification datetime of the patched file is set to D. As a result, the build is not bit-by-bit reproducible, because the datetime of the build is saved in the resulting package. Patching is not necessary to make this happen. When a source file is compiled into a binary file, the modification datetime is also set to the datetime of the build. In practice, the modification datetime of many files packaged in RPM packages is dependent on when the package was actually built. To eliminate this problem, we propose to clamp build mtimes to `$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the `$SOURCE_DATE_EPOCH` environment variable based on the latest `%changelog` entry because the `%source_date_epoch_from_changelog` macro is set to `1`. We will also set the `%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when files are packaged to the RPM package, their modification datetimes will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry datetime). Clamping means that all files which would otherwise have a modification datetime higher than `$SOURCE_DATE_EPOCH` will have the modification datetime changed to `$SOURCE_DATE_EPOCH`; files with mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the original mtimes. This functionality is already implemented in RPM. We will enable it by setting `%clamp_mtime_to_source_date_epoch` to `1`. === Non-goal === We do not aim to make all Fedora packages reproducible (at least not as part of this change proposal). We just eliminate one problem that we consider the biggest blocker for reproducible builds. === Python bytecode === When Python bytecode cache (a `.pyc` file) is built, the mtime of the corresponding Python source file (`.py`) is included in it for invalidation purposes. Since the `.pyc` file is created before RPM clamps the mtime of the `.py` file, the mtime stored in the `.pyc` file might be higher than the corresponding mtime of the `.py` file. With the previous example, if `skynet` is written in Python: # `skynet.py` is modified in `%prep` and hence has mtime set to the time of the build # `skynet.pyc` is generated in `%install` and the mtime of `skynet.py` is saved in it # RPM clamps the mtime of `skynet.py` # `skynet.pyc` is considered invalid by Python on runtime, as the stored and actual mtime of `skynet.py` don't match To solve this, we will modify Python to clamp the stored mtime to `$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream Python chooses to invalidate bytecode cache based on hashes instead of mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause performance issues for big files, so Fedora's Python already deviates from upstream behavior when building RPM packages. To avoid accidentally breaking the behavior when `%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and buildroot policy scripts for creating the Python bytecode cache will be modified to unset `$SOURCE_DATE_EPOCH` when `%clamp_mtime_to_source_date_epoch` is not set to `1`. This behavior might be proposed upstream if it turns out to be superior to the current upstream choice, in case we [https://discuss.python.org/t/14594 won't redesign the bytecode-source relationship entirely] instead. === Opting out === Packages broken by this new behavior can unset `%clamp_mtime_to_source_date_epoch` but packagers are encouraged to fix the problem instead. == Feedback == Enabling this RPM feature was [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/126 proposed as a pull request] to {{package|redhat-rpm-config}} in April 2021. It received good feedback with the exception of the following: * it was said the change needs to be coordinated with the Python maintainers * it was said the change should be done via a change process for better coordination and exposure We believe that by proposing this via the change process and planning for the changes needed in Python, both issues are addressed. == Benefit to Fedora == We believe that many RPM packages will become reproducible and others will be more reproducible than before. The benefits of reproducible builds are better explained at https://reproducible-builds.org/ == Scope == * Proposal owners: ** Propose a PR for {{package|redhat-rpm-config}} (set `%clamp_mtime_to_source_date_epoch` to `1`, possibly only when `%source_date_epoch_from_changelog` is set) ** Propose a PR for {{package|python-rpm-macros}} (unset `$SOURCE_DATE_EPOCH` while creating `.pyc` files iff `%clamp_mtime_to_source_date_epoch` is not `1`) ** Propose a PR for [https://src.fedoraproject.org/rpms/python3.11/blob/b2d80045f9/f/00328-pyc-t… the Python's bytecode invalidation mode patch] for all Python versions that have it ** Backport (the new portion of) the patch to older Pythons ({{package|python2.7}}, {{package|python3.6}} and PyPys) ** Test everything together in Copr and deploy it if it works. ** Optional: Run some reproducibility tests before and after this change and produce some statistics. * Other developers: ** Test their packages with the new behavior, report problems, and opt-out if really needed. * 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 (not needed for this Change) == Upgrade/compatibility impact == Nothing anticipated. == How To Test == The change owners plan to perform a mass rebuild in Copr to see if this breaks anything significantly. If it actually works as anticipated, they also plan to run some reproducibility tests and hopefully produce some statistics before and after this change. Other packages can test by building their packages and verifying they still work as expected and no packaged files have higher mtimes than the last `%changelog` entry. To verify if this change has landed, run: `rpm --eval '%clamp_mtime_to_source_date_epoch'` on Fedora 38. The result should be `1`. == User Experience == Users of Fedora Linux on their machines should not be impacted at all. Users who build RPM packages atop Fedora will be impacted by this change the same way Fedora is. == Dependencies == * RPM needs to support this (it already does) * RPM needs to set `$SOURCE_DATE_EPOCH` (it already does) == Contingency Plan == * Contingency mechanism: The change owners or {{package|redhat-rpm-config}} maintainers or proven packagers will revert the change in {{package|redhat-rpm-config}}. That should be enough to undo anything as the changes in Python should be dependent on that. If not enough, revert everything. * Contingency deadline: Ideally, we should do this before the Mass Rebuild. Technically, we can land it any time before the Beta Freeze, but it would not change all the packages, which is a bit messy. * Blocks release? No < == Documentation == This page is the documentation. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

2 1

F38 proposal: FPC repackaging (Self-Contained Change proposal)
by Ben Cotton 30 Dec '22

30 Dec '22

https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging 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 == Split the `fpc` package (the Free Pascal Compiler) into several sub-packages (built from the same spec file). == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: <fedora(a)svgames.pl> == Detailed Description == The `fpc` package will be split into three packages: * `fpc` - the compiler itself, plus utility programs * `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`) * `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's stdlib") for developing programs for Linux The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`. == Benefit to Fedora == The TUI IDE will be moved to a separate package, slightly reducing the download size for packages requiring FPC to build. Putting Linux units in an `fpc-units-ARCHNAME-linux` package will create a precedent which can be used in the future for introducing cross-compilation packages, like `fpc-units-x86_64-win64` for MS Windows. == Scope == * Proposal owners: ** Edit `fpc.spec` as required and rebuild the package, preferably before the Mass Rebuild. * Other developers: No action required. * Release engineering: No action required. * 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 == After upgrading to Fedora 38, users interested in the TUI IDE will need to manually install the `fpc-ide` package. For those not interested in the TUI IDE, there will be no impact. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/fpc-split/ copr/suve/fpc-split]. This copr repository also modifies the spec to build units for MS Windows (`x86_64` only), allowing for cross-compilation. == User Experience == For users not interested in the TUI IDE, this Change will slightly reduce the install size (about 1.5 MiB for the IDE plus another 3.5 MiB for its dependencies). Since the TUI IDE does not launch the compiler as a sub-process, but rather contains an embedded copy of the compiler, users who use only the IDE and not the standalone compiler will benefit in a similar way - they will be able to install just the IDE, without the main compiler package. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `fpc.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `fpc` package no longer includes the terminal-based TUI IDE. Users interested in the IDE should install the `fpc-ide` package. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
by Ben Cotton 30 Dec '22

30 Dec '22

https://fedoraproject.org/wiki/Changes/GNUToolchainF38 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 Fedora 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37. The existing gdb 12.1 will be used as-is. The set of core GNU Toolchain packages for Fedora 38 are as follows: * GNU C Compiler 13.0 ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.39 * GNU C Library 2.37 * GNU Debugger 12.1 (immediately available in Fedora 37) The gcc 13.0 change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.39 change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.37 change will be tracked in this top-level GNU Toolchain system-wide update. == Owner == * Name: [[User:codonell|Carlos O'Donell]] * Email: carlos(a)redhat.com == Detailed Description == The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and the GNU Debugger 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 13.0, after the Fedora 38 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-13/changes.html. The latest release candidate for gcc 13 will be included in Fedora 38 and will be updated when released. The GNU Binutils version 2.39 was released before Fedora 38; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution for the last 4 months. Given the present schedule for Fedora 38 we will continue to use Binutils 2.39. The GNU C Library version 2.37 is expected to be release before Fedora 38; we have started closely tracking the glibc 2.37 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 38 will branch after the release of glibc 2.37. However, the mass rebuild schedule means Fedora 38 will mass rebuild (if required) before the final release of glibc 2.37, but after the ABI is frozen. The GNU Debugger version 12.1 was released before Fedora 38; and we plan to continue to use this version of the debugger. == 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 38 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. * Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/XX #XX] ** Filed after approval. * 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. Some source changes may be required for the gcc 13 update. Please refer to the latest changes here: https://gcc.gnu.org/gcc-13/changes.html Any source level changes required for glibc 2.37 will be noted here: https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes == 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. The GNU Binutils has its own testsuite which is run during the package build and examined by binutils developers before being uploaded. The regression testsuite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own testsuite which is run during the package build and examined by gdb developers before being uploaded. The regression testsuite is run to verify the correct operation of the debugger. == User Experience == Fedora developers as well as developers using the distribution will be able to use and develop using the new features offered by the updated components. Developers will need to enable specific compiler features as required e.g. '-mcpu=neoverse-v2'. == 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 38 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.37 proves too disruptive to compiling the distribution we could revert to 2.36, but given that Rawhide has started tracking glibc 2.37, no show-stopper problems are expected. At this point we can still revert to upstream version 2.36 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism binutils: If binutils 2.39 proves too distruptive to assembling and linking the distribution we could revert to 2.38, but given that Rawhide is using 2.39, no show-stopper problems are expected. At this point we can still revert if insurmountable problems appear, but to do so may require a mass rebuild if the defects involve generated binaries. * Contingency mechanism for gcc: If gcc 13 proves too disruptive to compiling the distribution we could revert to gcc 12. * Contingency mechanism for gdb: The gdb 12.1 release is already in all the Fedora releases and it would not be reverted. If any gcc, glibc or binutils changes cause gdb to fail then that would need to be reviewed on a case-by-case basis. * Contingency deadline: Fedora mass rebuild on 2023-01-18. * Blocks release? ** Yes, upgrading to gcc 13.0 does block the release. ** Yes, upgrading to binutils 2.39 does block the release. ** Yes, upgrading to glibc 2.37 does block the release. ** No, upgrading to gdb 12.1 does block the release (already released). == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The binutils 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. The gdb manual contains the documentation for the release and doesn't need any more additional work. == Release Notes ==  See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler Collection version 13 release notes.  The GNU C Library version 2.37 will be released at the beginning of February 2023. 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 The GNU Binary Utilities version 2.39 was released August 2022. The current release notes will be sent to the developer mailing list: https://sourceware.org/pipermail/binutils/2022-August/122246.html. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Noto Fonts For More Languages (System-Wide Change proposal)
by Ben Cotton 30 Dec '22

30 Dec '22

https://fedoraproject.org/wiki/Changes/NotoFontsForMoreLang 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 == Changes the default font for more languages to Noto Fonts. == Owner == * Name: [[User:Tagoh| Akira TAGOH]] * Email: <tagoh AT redhat DOT com> == Detailed Description == We have changed our default fonts to Noto in [[Changes/DefaultToNotoFonts|f36]] though, some languages was still missing even though Noto Fonts provides fonts for their languages. This Change continues to accomplish consistent text rendering across our supported languages as far as possible. The following languages are targeted in this Change: * Khmer * Thai == Feedback == == Benefit to Fedora == We would get better text rendering on applications and desktops for the above languages as well as languages we have already migrated. Also this change should save about 344kB on the fresh install. <pre> $ rpm -qlv khmer-os-system-fonts thai-scalable-waree-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 504660</pre> <pre> $ rpm -qlv google-noto-sans-khmer-vf-fonts google-noto-sans-thai-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 160573</pre> == Scope == * Proposal owners: ** Update google-noto-fonts and fonts packages currently used as default, to change the priority of fontconfig config. ** Update langpacks to update dependencies ** Update comps to update default fonts sets ** Update lorax templates * Other developers: Nothing * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Nothing == Upgrade/compatibility impact == The migration will be done by updating langpacks. after upgrading and rebooting, the default font will be Noto instead of `Khmer OS System`/`Waree`. Since this change aims to switch non-variable fonts to variable fonts, it may not works with legacy applications as expected such as missing some variants. in that case, you can install non-variable fonts packages. the package name will be similar and simply drop -vf from the variable fonts packages. == How To Test == * This change can be simply tested by fc-match command like `fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your language>` and `fc-match monospace:lang=<your language>`. `:lang=km` for Khmer and `:lang=th` for Thai. * Test the text rendering in your favorite application, which use the system default font. == User Experience == Khmer/Thai Users will see the default font is changed to Noto by this change. == Dependencies == Only khmer-os-system-fonts, thai-scalable-waree-fonts, langpacks, and fontconfig are required to update. Other packages which explicitly has a dependency to above fonts packages are basically optional to update. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Revert the relevant packages updated. * Contingency deadline: Beta freeze * Blocks release? No == Documentation == None == Release Notes == The default fonts for Khmer and Thai will be Google Noto Fonts to keep consistency on the text rendering and to provide better quality among languages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton 30 Dec '22

30 Dec '22

https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default 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 == Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as the default approach. Packaging Guidelines and other documentation are adjusted to describe this approach first. Various tools that provide spec file templates are adjusted. == Owner == * Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl == Detailed Description == {{admon/note|Brief reminder about rpmautospec| The spec file contains: <pre> Version: 1.2.3 Release: %autorelease ... %changelog %autochangelog </pre> Rpmautospec uses git history. Whenever the package is built (`.src.rpm` is generated), rpmautospec tooling will replace the `%autorelease` macro with the number of commits since the last commit that changed the `Version` field, and the `%autochangelog` macro with a text generated from `git log`. For details see the [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html docs]. }} Rpmautospec has been deployed in Fedora since F35 ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%). But it is still a "second-class citizen": most documentation doesn't mention it, and many packagers know that it exists but don't use it in their packages. We think that it's reasonable to switch to `%autorelease`+`%autochangelog` for almost all packages and that Packaging Guidelines and various packaging howtos should recommend that approach to packagers. The "traditional" approach of manually-managed `Release` and `%changelog` will remain valid and will be documented as a fallback. This change is targeted at Fedora 38, but it will actually apply to all releases. The goal is to update the Packaging Guidelines and other prominent documentation and tools now, and other docs and tools possibly at a later time. Changing packages is out of scope. It is worth mentioning that `rust2rpm` uses `%autorelease`+`%autochangelog` since a few releases, so most rust packages have switched. (Generally, rust spec files are recreated using the generator for each new version, so the switch would happen whenever a new version is packaged unless the packager opts out.) == Feedback == * Thread on fedora-devel in August 2022: [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… rpmautospec by default] ** open issues: a bunch have been fixed. ** maintenance: Nils will add some co-maintainers. ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see Scope section. == Benefit to Fedora == Various packaging workflows become smoother for packagers and contributors: * packagers don't need to touch the `Release` field on updates * packagers describe changes just once in the git commit message, the `%changelog` entry is autogenerated * patches to the spec file can be cherry-picked between branches without trivial conflicts * pull requests on src.fedoraproject.org can be merged without trivial conflicts * in workflows that regenerate the spec file (rust2rpm, pip2rpm, …) `%changelog` section doesn't need to be copied over == Scope == * Proposal owners: ** provide pull requests to Packaging Guidelines and other docs to make `%autorelease`+`%autochangelog` the default ** implement fixes for issues reported by packagers ** make semi-regular releases of rpmautospec ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… 0.3.1 was released on November 17th, and should be deployed to production in about two weeks]) * Other developers: ** provide pull requests to other docs as appropriate ** accept the changes to documentation ** update other spec file generators (pip2rpm, others?) * Somebody (TBD): ** `fedora-review` — https://pagure.io/rpkg/issue/641 ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the command will fail. A replacement workflow that instead restores `%autorelease`+`%autochangelog` in the file committed to dist-git needs to be implemented. * Related work ** https://pagure.io/rpkg/c/3087dd7 ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: a list of places to be updated ** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs ** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning ** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial… * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Rpmautospec is already used by a decent number of packages, so any issues are already being seen and need to be fixed anyway. == How To Test == * Convert an existing package: `rpmautospec convert`. Ideally this step is done right before a version bump so that the release numbers restart at `-1`. * Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`). * Do builds in koji. Verify correctness of version-release and the changelog. * For new packages, use `%autorelease`+`%autochangelog`. Repeat all the tests listed above. * Assume you are a newbie packager. Read the packaging docs and check that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly. == User Experience == No changes visible to end users. == Dependencies == None. == Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation. * Contingency mechanism: Revert changes to documentation by reverting the appropriate commits. This can be done easily by FPC. * Contingency deadline: Any time. * Blocks release? No. == Documentation == This page and any changes to Packaging Guidelines and other documents. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 election results
by Ben Cotton 23 Dec '22

23 Dec '22

Greetings, all! The elections for the Fedora Linux 37 cycle have completed. ## Fedora Council Aleksandra Fedorova is elected to the Fedora Council ## Fedora Engineering Steering Committee (FESCo) The following candidates are elected to FESCo: * Kevin Fenzi * Miro Hrončok * Zbigniew Jędrzejewski-Szmek * David Cantrell * Fabio Valentini ## Fedora Mindshare Committee Fernando F. Mancera is elected to the Fedora Mindshare Committee. Congratulations to all those elected and thank you to the candidates and voters. For more details, see the Community Blog post: https://communityblog.fedoraproject.org/fedora-linux-37-election-results/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
by Ben Cotton 22 Dec '22

22 Dec '22

https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer 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 == A downstream configuration change to reduce the systemd unit timeout from 2 minutes to 15 seconds. == Owner == * Name: catanzaro * Email: mcatanzaro at redhat dot com * Name: aday * Email: aday at redhat dot com == Detailed Description == Currently, a service that fails to stop at shutdown time can block shutdown for up to 2 minutes. This is extremely frustrating for our users - someone goes to shutdown or reboot their system, and then unexpectedly has to wait for a long time before they can do anything else. The most common service to cause this issue is PackageKit, but there are others. When a service fails to shutdown when it is instructed to do so, it is not behaving properly, and it is preventing the system from behaving in an orderly and predictable manner. Desktop APIs exist for cases when services or apps legitimately need to prevent shutdown, and these allow the shutdown inhibit to be communicated to admins and users, so they understand what is happening. When the user decides to shut down anyway, services must terminate in a timely manner. The Workstation Working Group feels that 15 seconds is the maximum appropriate time for both system and user services, and that Fedora should be robust to buggy and misbehaving services that do not shut down in an appropriate manner. === History === The Workstation Working Group has been [https://pagure.io/fedora-workstation/issue/163 working on this issue for several years]. Investigations have revealed that it's not possible to fix every misbehaving service: in some cases the misbehaviour comes from design flaws that are difficult to resolve. An attempt has also been [https://github.com/systemd/systemd/pull/18386 made to have the unit timeout changed in upstream systemd]. That attempt did not go anywhere, despite various efforts to move it along. We are no longer comfortable waiting for upstream changes to land. To our knowledge, there are no issues that will result from forcing services to stop after 15 seconds on typical systems. However, system administrators may need to configure a higher timeout if waiting longer for a particular service, which may be true for database services, for example. == Feedback == The relevant [https://pagure.io/fedora-workstation/issue/163 Workstation Working Group ticket] includes some discussion. This change [https://pagure.io/fesco/issue/2853 was also previously proposed to FESCo]. == Benefit to Fedora == The primary benefit of the change will be to mitigate a very annoying and - frankly - embarrassing bug. Our users shouldn't have to randomly sit waiting for their machine to shutdown. It will also encourage the correct use of shutdown inhibit APIs. Although this change will "paper over" bugs in services without fixing them, we emphasize that reducing the timeout is not merely a workaround for buggy services, but also the desired permanent design. Of course it is desirable to fix the underlying bugs as well, but it doesn't make sense to require this before fixing the service timeout to match our needs. == Scope == * Proposal owners: ** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85 the downstream change] to {{package|systemd}}. * Other developers: ** Test their packages with the new behavior and report issues as necessary. * Release engineering: [https://pagure.io/releng/issue/11193 #11193] * Policies and guidelines: No policy or guideline changes required * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == System and user services will be killed with SIGKILL 15 seconds after receiving SIGTERM, from previously 1 minute 30 seconds for most system and user services, or 2 minutes for user manager system services (the system service that runs all user services for a user), so services will have less time to shut down gracefully by default. These defaults are configurable and system administrators who require longer timeouts would need to adjust them before or after upgrade. You may edit the DefaultTimeoutStopSec= setting in /etc/systemd/user.conf and /etc/systemd/system.conf. You may also create a drop-in to change the TimeoutStopSec= setting for user@service. == How To Test == Given the intermittent and unpredictable nature of the bug that is being targeted, the best way to test is by using the upcoming Fedora release. Are shutdown delays eliminated as intended? Do system services experience issues as a result of the change? == User Experience == This change will make the Fedora user experience less annoying. It will also encourage the use of the existing inhibit APIs, which provide better feedback for users when system shutdown does need to be delayed. == Dependencies == No specific changes are required in other packages. However, service developers may want to take this opportunity to examine the shutdown behavior of their components. == Contingency Plan == * Contingency mechanism: the change owners will revert the change in systemd. * Contingency deadline: if we back out the change it would be best to do it before beta freeze, but this can happen at any point. * Blocks release? No. == Documentation == Documentation isn't required for this minor configuration change. Services that legitimately need to prevent system shutdown should use [https://www.freedesktop.org/wiki/Software/systemd/inhibit/ systemd inhibit]. Desktop applications can use the [https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.… XDG inhibit portal]. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
by Ben Cotton 21 Dec '22

21 Dec '22

https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients 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 == X server implementations (e.g. Xorg and Xwayland) will (by default) no longer allow clients with different endianess to connect. == Owner == * Name: [[User:whot| Peter Hutterer]] * Email: peter.hutterer(a)redhat.com == Detailed Description ==  X server implementations (e.g. Xorg and Xwayland) allow clients with an endianess different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients. One needs to only look at e.g. [https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this X.Org security advisory] and count the `SProc` mentions for an indication on how bad this is. A simple solution to remove this attack surface is to prohibit clients with a different endianess. These clients will simply fail, in a matter similar to failing to authenticate against an X server. The use-case for clients with different endianess is ''very'' niche. It was common in the 1980s when X was originally developed but at this point a vanishingly small number of users run clients and X servers on different machines, let alone on different machines with different endianess. I'd be surprised if Fedora had ''any'' users requiring this feature. Note: * this only affects use-cases where the server runs on a little endian host and the client on a Big Endian host (or vice versa). * this is a change in '''the default behavior''' only and can be changed via configuration options (for `Xorg`) and/or commandline arguments (all X servers). * this is a change in the upstream default behavior that Fedora will follow along with. This Change is primarily to increase the exposure. == Benefit to Fedora == This change removes a large potential attack surface that can be used by malicious clients to expose memory locations, crash the X server and/or do other entertaining things malicious programs like to do. == Scope == * Proposal owners: # Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream PR] # Backport patch to Fedora's `xorg-x11-server` and `xorg-x11-server-Xwayland` packages * Other developers: This is labelled as system-wide change simply because it's a change in Xorg/Xwayland. It is otherwise self-contained in that no other packages need updating, '''unless''' they want to opt-out of this default. Which is better left to system-specific configuration anyway. * Release engineering: This feature does not require coordination with release engineering * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == For the ''extremely niche'' use-case of users that run X clients on a remote machine with a different endianess, these clients will no longer be able to connect '''by default'''. For Xorg, the following `xorg.conf.d` snippet will re-enable the old behavior: <pre> Section "ServerFlags" Option "AllowSwappedClients" "on" EndSection </pre> Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the `+byteswappedclients` flag to Xwayland. At the time of writing, GNOME does not yet provide such a configuration. == How To Test == To test the impact of this change, you need: * an X server running on a little endian architecture and an X client running on a Big Endian architecture (or the other way around) * set up the X server to accept remote connections, either via TCP or through SSH * run the X client which will fail to connect Alternatively, a test client is available in [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the upstream PR]. This test client pretends to be BigEndian and will fail to connect when run against a little endian X server. == User Experience == For virtually all users, there is no change in behavior. Users with X server and client on two different machines must add the `xorg.conf.d` snippet shown above on affected systems. == Dependencies == No other RPMs depend on this change. == Contingency Plan == This change depends on whether upstream merges this new default behavior. If upstream does not merged the feature in time, this Change will be postponed until the next Fedora version to avoid potential incompatibilities between configurations or commandline options. * Contingency mechanism: keep current behavior, try again with next Fedora version * Contingency deadline: beta freeze * Blocks release? No == Documentation == == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
by Ben Cotton 20 Dec '22

20 Dec '22

https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1 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 == Add support for unified kernels images to Fedora. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kraxel(a)redhat.com == Detailed Description == The goal is to move away from initrd images being generated on the installed machine. They are generated while building the kernel package instead, then shipped as part of a unified kernel image. A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature. The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot. Main motivation for this move is to make the distro more robust and more secure. Switching the whole distro over to unified kernels quickly is not realistic though. Too many features are depending on the current workflow with a host-specific initrd (and host-specific kernel command line), which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😃 A host-specific initrd / command line is needed today for: * features needing optional dracut modules (initrd rebuild needed to enable them). * configuration / secrets baked into the initrd (booting from iscsi for example). * configuration being specified on the kernel command line. ** root filesystem being the most important one. [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] allow to remove this. Phase 1 goals (high priority): * Ship a unified kernel image as (optional) kernel sub-rpm. Users can opt-in to use that kernel by installing the sub-rpm. Initial focus is on booting virtual machines where we have a relatively small and well defined set of drivers / features needed. Supporting modern physical machines with standard setup (i.e. boot from local sata/nvme storage) too should be easy. * Update kernel install scripts so unified kernels are installed and updated properly. * Add bootloader support for unified kernel images. Add [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-ima… unified kernel bls support] to grub2, or support using systemd-boot, or both. Phase 1 goals (lower priority, might move to Phase 2): * Add proper discoverable partitions support to installers (anaconda, image builder, ...). ** Temporary workaround possible: set types using sfdisk in %post script. ** When using btrfs: configure 'root' subvolume as default volume. * Add proper systemd-boot support to installers. ** Temporary workaround possible: run 'bootctl install' in %post script. * Better measurement and remote attestation support. ** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to allow pre-calculate TPM PCR values. ** avoid using grub2 (measures every config file line executed which is next to impossible to pre-calculate). * Switch cloud images to use unified kernels. Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38). * Move away from using the kernel command line for configuration. * Move away from storing secrets in the initrd. * Handle dracut optional modules in a different way. systemd has some building blocks which can be used, although none of them are used by fedora today. [https://www.freedesktop.org/software/systemd/man/systemd-creds.html systemd credentials] can be used for secrets (also for configuration). The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html unified kernel stub] can load credentials from the ESP. The unified kernel stub can also load [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html extensions] from the ESP, which can possibly be used to replace optional dracut modules. == Feedback == == Benefit to Fedora == * Better secure boot support (specifically the initrd is covered by the signature). * Better confidential computing support (measurements are much more useful if we know what hashes to expect for the initrd). * More robust boot process (generating the initrd on the installed system is fragile, root cause for kernel bugs reported is simply a broken initrd sometimes). == Scope == * Proposal owners: ** Update kernel build to create unified kernel sub-package. *** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 PR#2179] *** part two: (wip) [https://gitlab.com/kraxel/kernel-ark/-/commits/unified/ https://gitlab.com/kraxel/kernel-ark/-/commits/unified/] * Other developers: ** grub2: add unified kernel support *** wip code at [https://github.com/osteffenrh/grub2/ https://github.com/osteffenrh/grub2/] ** installer(s): add support for discoverable partitions. *** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288] * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == None (using unified kernel is opt-in for Phase 1). == How To Test == Try on a existing (uefi) system: * make sure you are running fedora 37 or rawhide. * make sure your root filesystem has type "Linux root (x86-64)" (use `fdisk -l` to check). ** should that not be the case use the fdisk tag command ('t') to change the partition type. * when using btrfs: make sure the 'root' subvolume is set as default volume. * `dnf copr enable kraxel/unified.kernel` * `dnf update "grub2*"` * `dnf install kernel-unified-virt` * `reboot` You should find two entries in the grub2 boot menu, one for classing kernel with separate initrd and one for the unified kernel image. Both should boot fine. The https://gitlab.com/kraxel/fedora-uki project has kickstart files and helper scripts for generating virtual machine images. * image using grub2-efi: https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub… * image using systemd-boot: https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdbo… Prebuilt virtual machine images are available from https://www.kraxel.org/fedora-uki/. == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: ** Probably none (unified kernel images are opt-in for Phase 1). ** In case we tried switching the cloud images to unified kernels: revert the kickstart config changes. * Contingency deadline: * Blocks release? No == Documentation == == Release Notes == -- 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 December 2022