Dear maintainers.
Based on the current fail to build from source policy, the following packages
should be retired from Fedora 43 approximately one week before branching,
i.e. 2025-08-05.
5 weekly reminders are required, this is the fourth one.
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 40.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
golang-* packages excluded via https://pagure.io/fesco/issue/3447
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers
================================================================================
OliveTin @go-sig, jamesread
dtkwm @deepinde-sig, cheeselee, felixonmars, zsun
freemarker didiksupriadi41
ghdl sailer
git-cinnabar qulogic
javapoet mbooth
juniversalchardet didiksupriadi41
koffice-kivio kkofler, rdieter
mingw-GConf2 orphan
minicomputer verdurin
mod_qos cdamian, neil
netresolve pemensik
pdfsign fale
php-symfony-polyfill siwinski
plotdrop sagarun
rubygem-abrt vondruch
rubygem-fakefs athoscr
scalpel rebus
smesh jkastner, orphan
tinygo @go-sig, qulogic
The following packages require above mentioned packages:
Depending on: dtkwm (1)
deepin-screenshot (maintained by: @deepinde-sig, cheeselee, zsun)
deepin-screenshot-5.0.0-14.fc41.src requires pkgconfig(dtkwm)
deepin-screenshot-5.0.0-14.fc41.x86_64 requires libdtkwm.so.5()(64bit)
Depending on: javapoet (2)
auto (maintained by: mbooth)
auto-1.6.1-13.fc42.src requires mvn(com.squareup:javapoet)
auto-value-1.6.1-13.fc42.noarch requires mvn(com.squareup:javapoet)
jmock (maintained by: didiksupriadi41)
jmock-2.12.0-19.fc42.src requires mvn(com.google.auto.service:auto-service)
Depending on: rubygem-fakefs (1)
rubygem-pathspec (maintained by: athoscr, ignatenkobrain)
rubygem-pathspec-0.2.1-17.fc42.src requires rubygem(fakefs)
Affected (co)maintainers
@deepinde-sig: dtkwm
@go-sig: tinygo, OliveTin
athoscr: rubygem-fakefs
cdamian: mod_qos
cheeselee: dtkwm
didiksupriadi41: javapoet, juniversalchardet, freemarker
fale: pdfsign
felixonmars: dtkwm
ignatenkobrain: rubygem-fakefs
jamesread: OliveTin
jkastner: smesh
kkofler: koffice-kivio
mbooth: javapoet
neil: mod_qos
pemensik: netresolve
qulogic: git-cinnabar, tinygo
rdieter: koffice-kivio
rebus: scalpel
sagarun: plotdrop
sailer: ghdl
siwinski: php-symfony-polyfill
verdurin: minicomputer
vondruch: rubygem-abrt
zsun: dtkwm
Wiki - https://fedoraproject.org/wiki/Changes/php85
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-php-8-5-self-con…
This is a proposed Change for Fedora Linux.
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 PHP stack in Fedora to the latest version 8.5.x
== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org
* A testing SCL (and soon testing module) is available in my
[https://blog.remirepo.net/post/2025/07/04/PHP-8.5-as-Software-Collection
repository]
* List of [https://github.com/remicollet/remirepo/issues/307
extensions compatibility list]
* [https://wiki.php.net/todo/php85 Upstream schedule for 8.5]
== Detailed Description ==
Update the PHP stack in Fedora to latest version 8.4.x.
Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice
for some years:
* 2 Fedora cycles for each PHP minor release (exceptions below)
* 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time
before next major
* 1 Fedora cycle for first major (e.g. 7.0 or 8.0)
Fedora 40 and 41 have PHP 8.3, Fedora 42 and 43 have PHP 8.4.
As this version should be the last 8.x (before 9.0), it should be in
Fedora 44, 45 and 46.
If the PHP project chooses to do an 8.6, it should land in 46.
== Benefit to Fedora ==
Provides the latest PHP version to developers and system administrators.
== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.
* Other developers: N/A (not a System Wide Change)
* Release engineering:[https://pagure.io/releng/issues #Releng issue number]
* 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 ==
* The PHP stack (extensions and libraries) are monitored by Koschei,
see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started
Koschei PHP group]
* install and play with your web applications
== User Experience ==
Developers and system administrators will have the great benefit or
running the latest PHP version.
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible (and not fixable) packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* [https://raw.githubusercontent.com/php/php-src/master/UPGRADING UPGRADING]
* [https://raw.githubusercontent.com/php/php-src/master/UPGRADING.INTERNALS
UPGRADING.INTERNALS]
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/TBB2022.2.0
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-tbb2022-2-0-self…
This is a proposed Change for Fedora Linux.
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 tbb package in Fedora from version 2022.0.0 to 2022.2.0.
== Owner ==
* Name: [[User:jjames| Jerry James]]
* Email: loganjerry(a)gmail.com
* Name: [[User:jwakely| Jonathan Wakely]]
* Email: jwakely(a)redhat.com
== Detailed Description ==
In tbb 2022.0.0 and earlier, certain macros expanded to code that
accessed internal elements of the API. Some of those internal
elements were removed in tbb versions 2022.1.0 and 2022.2.0. Although
the public API has not changed, ELF objects in some Fedora packages
refer to symbols that are not provided by the newer versions. Thus, a
rebuild of all tbb-using packages is needed.
Evidence that the API has not changed is available in a
[https://copr.fedorainfracloud.org/coprs/jjames/TBB/ COPR repository]
containing the new version of TBB and builds of consuming packages.
Three packages (embree3, rkcommon, and root) could not be built
because they currently fail to build from source in Rawhide, but all
others were successfully built unmodified.
The proposed changes to the tbb package are visible in
[https://src.fedoraproject.org/rpms/tbb/pull-request/20 this pull
request].
Besides tbb itself, the packages that must be rebuilt (with maintainers) are:
* blake3 (sicherha)
* dyninst (fche, mcermak, lberk, orion, wcohen)
* easyeffects (vascom)
* embree (luya, aekoroglu, slaanesh)
* embree3 (luya)
* gfan (jjames, pcpa)
* ispc (luya, aekoroglu, slaanesh, tstellar)
* Macaulay2 (rdieter)
* mathicgb (jjames)
* mold (sicherha)
* oidn (luya, aekoroglu, slaanesh)
* opae (trix)
* opencascade (hobbes1069)
* opencv (kwizart, jridky, jkucera, hhorak)
* openpgl (luya, aekoroglu)
* openvino (aekoroglu)
* openvkl (aekoroglu)
* pagmo2 (topazus)
* papilo (jjames)
* polymake (jjames, rmattes)
* prusa-slicer (tibbs, spot, jstanek, adelton, churchyard)
* ptl (topazus)
* rkcommon (aekoroglu)
* root (ellert, @r-maint-sig)
* scip (jjames)
* soplex (jjames)
* TOPCOM (jjames)
* usd (luya, aekoroglu, slaanesh, music, @multimedia-sig)
Some of those packages take many hours to build, and some of the very
long builds must be done sequentially due to dependencies between
packages on the list. Approximately 2 to 3 days will be needed to do
all of the builds.
== Feedback ==
== Benefit to Fedora ==
We will be able to take advantage of improvements in tbb versions
[https://github.com/uxlfoundation/oneTBB/releases/tag/v2022.1.0
2022.1.0] and [https://github.com/uxlfoundation/oneTBB/releases/tag/v2022.2.0
2022.2.0], as well as unblocking our ability to continue updating to
newer releases.
== Scope ==
* Proposal owners:
We will contact owners of the affected packages and negotiate a time
when the rebuilds can be done. Once a time has been arranged, we will
announce it on fedora-devel-list and do all of the builds in a side
tag at the arranged time.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This proposal supports the
[https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about
First foundation]
== Upgrade/compatibility impact ==
Third-party applications linked with tbb may need to be rebuilt.
== How to Test ==
N/A
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: N/A
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/ManDbCacheDirChange
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-fontconfig-cache…
This is a proposed Change for Fedora Linux.
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 man-db cache files are placed in/var/cache/man now. This seems
incompatible with the ostree model, so this is a proposal to move it
to /usr/lib/man/cache. This is also heavily requested for
[https://bugzilla.redhat.com/show_bug.cgi?id=2339038 image-mode]
== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com
== Detailed Description ==
Currently, the man-db cache files are stored in `/var/cache/man`,
which works fine in traditional setups. However, this location doesn't
play well with the OSTree model, where `/var` is often treated
differently or even shared across deployments. To make man-db more
compatible with OSTree-based systems, this proposal suggests moving
the cache files to `/usr/lib/man/cache` instead. That way, the cache
can live alongside the rest of the read-only system content managed by
the image, avoiding issues with `/var`. This change is also something
that’s been heavily
[https://bugzilla.redhat.com/show_bug.cgi?id=2339038 requested] by
people working with image-mode deployments, where managing everything
within `/usr` is generally preferred.
== Feedback ==
== Benefit to Fedora ==
Image-Mode is requesting this so it can make use of it since the
`/var` directory is restricted for
[https://bootc-dev.github.io/bootc/filesystem.html#var other use].
Similar approach was done in the fontconfig package (described in this
[https://fedoraproject.org/wiki/Changes/FontconfigCacheDirChange
Fedora Change].
== Scope ==
* Proposal owners: Rebuild the man-db package with the changes to the
proposed cache directory.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: YES
== Upgrade/compatibility impact ==
== How To Test ==
The /usr/lib/man/cache should exist and be used for the man-db cache.
The previously used /var/cache/man should not be used at all.
== User Experience ==
N/A (not a System Wide Change)
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
Revert the changes to place the caches at /var/cache/man.
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
N/A (not a System Wide Change)
== Release Notes ==
The place of the man-db caches has been moved from /var/cache/man to
/usr/lib/man/cache.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/DeprecateYASM
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-deprecate-yasm-s…
This is a proposed Change for Fedora Linux.
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 ==
This Change proposes to deprecate YASM and build packages with NASM instead.
== Owner ==
* Name: [[User:Rathann| Dominik Mierzejewski]]
* Email: dominik(a)greysector.net
== Detailed Description ==
YASM is [https://github.com/yasm/yasm/issues/164#issuecomment-1351844621
unmaintained] upstream currently, but it's still used to compile
assembly sources in 12 Fedora packages, including critical ones like
Firefox. Last release was in July 2019 and last commit was in June
2024. Issues are left unresolved and pull requests unreviewed. It is
getting dropped from [https://github.com/eweOS/packages/issues/4240
other distributions] already. In contrast, NASM is still maintained,
with last release in April 2024 and last commit in November 2024 with
no indication of upstream abandoning development. Most, if not all
upstreams support building using NASM already, so the proposal is to
switch their build dependency to NASM instead.
== Feedback ==
== Benefit to Fedora ==
Switching to compiling assembly sources with NASM ensures (critical)
applications are built with a maintained assembler.
== Scope ==
* Proposal owners:
** Open pull requests to switch <code>BuildRequires: yasm</code> to
<code>nasm</code> or make the changes directly where permitted.
** Mark {{package|yasm}} as deprecated by adding <code>Provides:
deprecated(yasm)</code>
** Work with affected package maintainers and upstreams to ensure they
build with <code>nasm</code> correctly.
* Other developers: Affected package maintainers are encouraged (but
not required) to ensure their packages build with <code>nasm</code>
instead of <code>yasm</code>.
* Release engineering: N/A (not a System-wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No new packages should require <code>yasm</code> to build as it will
be marked as deprecated. Existing packages will be built using
<code>nasm</code> going forward. The change should be transparent to
users.
== How To Test ==
<code>fedrq wrsrc -s yasm -F name</code> returns no packages depending
on <code>yasm</code> to build.
== User Experience ==
There should be no noticeable user impact.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Revert <code>BuildRequires:</code> back to
<code>yasm</code> and remove the deprecation.
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
YASM assembler has been deprecated and all packages that required it
to build are now built using NASM.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/HareProgrammingLanguage
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-hare-programming…
This is a proposed Change for Fedora Linux.
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 ==
Introduce packages for [https://harelang.org/ Hare], a systems
programming language designed to be simple, stable, and robust. Hare
is still under development, the language, its standard library and its
reference tool chain are still subject to breaking changes.
== Owner ==
* Name: [[User:dridi|Dridi Boukelmoune]], [[User:mroche|Mike
Rochefort]], [[User:fnux|Timothee Floure]], [[User:fed500|Benson
Muite]]
* Email: dridi dot boukelmoune at gmail, mroche at omenos dot dev,
timothee dot floure at posteo dot net, benson_muite at emailplus dot
org
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
== Detailed Description ==
Hare is a systems programming language designed to be simple, stable,
and robust. Hare uses a static type system, manual memory management,
and a minimal runtime. It is well-suited to writing operating systems,
system tools, compilers, networking software, and other low-level,
high performance tasks.
The Hare tool chain on Fedora will include:
* `hare` (build driver)
* `harec` (compiler front-end, already available in Fedora)
* `qbe` (compiler back-end, already available in Fedora)
* `binutils` (for assembly and static linking)
* `gcc` (for dynamic linking, it also works with other C compilers)
Leaving `binutils` and GCC aside, bootstrapping a Hare tool chain only
takes a few minutes. The Hare tool chain can target the `x86_64`,
`aarch64` and `riscv64` architectures, and will be configured to rely
by default on `gcc-<arch>-linux-gnu` and `binutils-<arch>-linux-gnu`
for cross compilation.
The `hare` source package will produce the following packages:
* `hare` (build driver, `haredoc` utility and manuals)
* `hare-stdlib` (standard library)
* `hare-rpm-macros` (packaging utilities)
In addition, a `hare-update` package will be provided to assist Hare
developers deal with breaking changes when a new Hare release is
available, until the language and its standard library become stable.
== Feedback ==
None.
== Benefit to Fedora ==
Developers can begin using the Hare language in their projects.
Package maintainers can ship applications written in Hare.
Unlike other language tool chains, Hare modules are meant to be the
responsibility of system package managers like DNF. Packaging Hare
modules and applications should result in little friction.
== Scope ==
* Proposal owners:
** submit `hare` and `hare-update` packages for review
** create RPM macros for Hare packaging
*** `%hare_arches` already submitted to `redhat-rpm-config`
** handle the `hare` package bootstrap
** add dependency generators for Hare modules
** draft packaging guidelines
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines:
** There ideally should be Hare packaging guidelines submitted as part
of this change, otherwise at a later point.
** See https://pagure.io/packaging-committee/pull-request/1472
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: none
== Upgrade/compatibility impact ==
The Hare specification is still a draft, so the Hare language, tool
chain and standard library are still subject to relatively frequent
breaking changes. Package updates containing breaking changes should
be limited to Fedora releases.
== How To Test ==
Once the `hare` package is available, the upstream [introduction
https://harelang.org/tutorials/introduction] to the language walks you
through the hello world below before covering language concepts.
Hello world:
<pre>$ cat >main.ha <<EOF
use fmt;
export fn main() void = {
fmt::println("Hello world!")!;
};
EOF
$ hare build -o example main.ha
4/4 tasks completed (100%)
$ ./example
Hello world!</pre>
== User Experience ==
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* https://harelang.org/documentation/
* https://harelang.org/tutorial
* https://harelang.org/specification
* https://harelang.org/blog
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Hardlink_identical_files_in_packages…
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-hardlink-identic…
This is a proposed Change for Fedora Linux.
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 post-build step is added to the package build macros to
automatically hardlink all identical files under `/usr`. Previously,
this was done in some packages and now it's done everywhere by
default.
== Owner ==
* Name: [[User:zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
== Detailed Description ==
Files can be hardlinked at the end of the `%install` step in package
builds. rpm supports this and will preserve those links in the binary
rpm and during installation. This makes the installation a bit more
efficient. Hardlinking of read-only files is generally transparent to
the user, but has some small benefits: the files are not duplicated in
the file system; backup, copy, and search programs will usually make
use of the link information and not process the same inode twice.
Thus, it's good to hardlink as many packaged files as possible.
Previously, hardlinking was done automatically for a subset of files
in Python packages (via the `%__os_install_post_python` macro), and
explicitly in some packages with lots of similar files (usually via
the `hardlink` program).
The `%__os_install_post` is extended to automatically hardlink all
identical files under `%{buildroot}%{_prefix}`, i.e. the `/usr`
directory in packages. This calls a new helper binary (part of the
`add-determinism` package) that does the linking.
Hard links may be confusing if the file is ''modified''. In
particular, all links to the same inode share the same ownership and
permissions, and obviously the same contents. Thus, we want to apply
hardlinking only to files under `/usr`, which are generally read-only
in packages.
When files are hardlinked, mtime (the modification timestamp) is taken
into account. Only files with identical mtime, owner, group, and mode
are subject to linking. The new program written to do the linking
takes `$SOURCE_DATE_EPOCH` into account, and will clamp mtimes to it
before comparing.
Note: rpm correctly handles the case where a hardlink is between files
in two different subpackages. Thus, we can hardlink everything under
`%{buildroot}`, and rpm will store the files as hardlinked if they are
in the same output package, adjusting the hardlink counts as
appropriate.
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
As mentioned in the Summary, hardlinking deduplicates the data in rpms
and in installations. Backup, copy, and search programs will usually
make use of the link information and not process the same inode twice.
Thus, by hardlinking files in the packages we make things a bit more
efficient. (The impact is small, because rpms generally don't have
large duplicated files.)
Hardlinking of files was previously done in some packages explicitly,
but it required adding a `BuildRequires` line and invoking a script,
so it wasn't done very often. By handling this automatically, we'll be
able to simplify those packages.
Another caveat that needs to be taken into account when doing
hardlinking as part of the package build is that newer `hardlink`
versions use reflinks instead of hardlinks by default. (With a
hardlink, one inode is connected to the file system tree in two or
more places. With a reflink, some blocks of an inode are shared with
another inode, ''inside'' of the file system, and the two inodes
retain their separate identities.) rpm has no knowledge of reflinks,
so those reflinks created during package build have no effect on the
binary package and the payload is duplicated. Invocations of
`hardlink` would have to be annotated with `--reflink=never` to retain
the intended effect. By removing that step from packages we avoid this
issue.
The [https://docs.fedoraproject.org/en-US/reproducible-builds/
Reproducible Builds] effort reported that some packages that use
hardlinking are not reproducible, see
[https://pagure.io/fedora-reproducible-builds/project/issue/22
irreproducibility#22]. When files are created in the package build,
depending on how fast the build machine is, some files might or might
not have identical timestamps. The tools that were used to compare
files for hardlinking were general tools that did not "know" that we'd
clamp the mtimes to `$SOURCE_DATE_EPOCH` in a subsequent step, so the
results of the mtime comparisons were unstable. The tool that is added
as part of this Change does the mtime clamping internally for
reproducible results. Fixing this issue was the initial motivation for
this change.
== Scope ==
* Proposal owners:
** extend the `add-determinism` package with a little helper that does
file comparisons and hardlinks identical files. The helper takes
`$SOURCE_DATE_EPOCH` into account.
** open pull request for `redhat-rpm-config` to insert a call to the
helper in `%__os_install_post`.
** open pull request for `python-srpm-macros` to drop their hardlinking step.
* Other developers:
** merge pull request
** report issues if the hardlinking has unforeseen consequences or
does not work correctly.
** drop explicit calls to `hardlink` in their packages.
* Release engineering:
* Policies and guidelines: not needed, AFAICT.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
No impact.
== Early Testing (Optional) ==
Build package with an invocation of the new helper.
== How To Test ==
Install packages rebuilt with the helper.
== User Experience ==
Not visible to users.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism:
** if hardlinking causes a problem in some specific packages, they can
be trivially modified to skip the hardlinking step by setting a macro.
** if there is a general problem, we can easily drop the macro in
`redhat-rpm-config`.
* Contingency deadline: any time, even after release. Any affected
packages would have to be rebuilt.
* Blocks release? No.
== Documentation ==
The invocation of the helper will be documented inline in the macros
files. Other documentation is not needed.
== Release Notes ==
Package builds automatically hardlink identical files. This reduces
the installation footprint a bit and also makes packages builds more
reproducible.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Greenboot_RS_Change_Proposal
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-release-of-green…
This is a proposed Change for Fedora Linux.
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 rewrite of Greenboot written in Rust will be released, designed for
use with bootc and rpm-ostree based systems. This Greenboot release
will have the same functionality as the original Bash release, which
was only intended for rpm-ostree based systems.
== Owner ==
* Name: [[User:saypaul| Sayan Paul]]
* Email: saypaul(a)redhat.com
* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwhalen(a)redhat.com
* Name: [[User:djachimo| David Jachimowicz]]
* Email: djachimo(a)redhat.com
== Detailed Description ==
As this release is a Rust rewrite of the Bash Greenboot version, the
functionality remains the same. It is detailed as follows:
Greenboot-RS exists to provide health check and rollback functionality
to bootc and rpm-ostree based systems. It allows a user to specify
health checks (scripts and binaries) to run every time the system
boots. These health checks can be either required or wanted, with the
difference of wanted checks not needing to succeed to allow a boot. If
any required checks fail the system will reboot, and may rollback to a
previous, working deployment if necessary.
Greenboot consists of two packages: `greenboot` and
`greenboot-default-health-checks`. The former, `greenboot` comprises
all the core functionalities of Greenboot. This includes checking
provided scripts and binaries, rebooting when required scripts or
binaries fail, and rolling back to a previous deployment if the
problem remains unsolved. The second package,
`greenboot-default-health-checks`, contains a series of optional
health checks curated and provided by the Greenboot maintainers.
A Greenboot execution begins on boot with
`greenboot-healthcheck.service`, which runs before systemd's
`boot-complete.target`. It launches `/usr/libexec/greenboot/greenboot
check`, which runs the `required.d` and `wanted.d` scripts.
If any script in `required.d` fails, greenboot run the scripts in the
`red.d` folder. Following this, a MOTD (Message of the Day) is created
specifying which scripts have failed. Checks are then performed to
determine if there's a need for manual intervention. If not, then the
system is rebooted.
If all scripts in `required.d` succeed:
* `boot-complete.target` is reached.
* The `boot_counter` GRUB env variable is unset and the `boot_success`
GRUB env variable is set to 1.
* Runs the scripts in the `green.d` folder. These are the scripts
intended to be run after a successful update.
* A MOTD with a success message is created.
== Feedback ==
Feedback from the community was positive regarding the Bash Greenboot
release, and it is now included with every Fedora IoT installation.
Various bugs and hiccups have been fixed as they have been found, and
those changes are included within this Rust rewrite. This section will
continue to be updated as more feedback is presented.
== Benefit to Fedora ==
This release is another step towards the adoption and support of bootc
systems with Fedora. Originally, the Greenboot release was written in
Bash and designed for use only with rpm-ostree based systems. This
change releases a new version of Greenboot, Greenboot-RS, written in
Rust and designed for usage with bootc and rpm-ostree based systems.
This change will allow users to utilize the advantages of a bootc
system, while still having the safety and reliability of Greenboot.
== Scope ==
* Proposal owners:
** Update with consolidation of services, such that all Greenboot
services have been collapsed into a single service.
** Update to allow seamless bootc upgrading. i.e. Upgrading from
Greenboot to Greenboot-RS using only `bootc upgrade`.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: This change aligns with Fedora's
goal of increasing contributors, as it helps further the integration
of bootc and Fedora IoT.
== Upgrade/compatibility impact ==
Current IoT users will experience a seamless transition to this new
Greenboot release, using `rpm-ostree upgrade` to grab the new version.
This new release will retain all the functionality of previous
versions.
== Early Testing (Optional) ==
N/A
Do you require 'QA Blueprint' support? No <!-- Optional Step for
System-Wide Changes only -->
== How To Test ==
Once added to the Fedora IoT compose, you can test Greenboot-RS basic
functionality by logging in via SSH. You should be greeted by this
MOTD:
`Boot Status is GREEN - Health Check SUCCESS`
Ensure that the boot status and health check are both listed as above.
== User Experience ==
Current IoT Users should notice no changes, apart from their Greenboot
version iterating after `rpm-ostree upgrade`. All functionality from
previous Greenboot versions is retained, so the health check features
they are used to will still remain.
Future IoT Users leveraging bootc will notice Greenboot support
included when setting up IoT with bootc. These Users will now have
access to the health check and rollback features Greenboot provides,
and will start to see a Greenboot MOTD when booting their systems.
== Dependencies ==
N/A
== Contingency Plan ==
In the event of unexpected issues or setbacks with Greenboot-RS
implementation, we will rollback to the previous Bash Greenboot
implementation. As the release plan for Greenboot-RS involves creating
a separate Greenboot-RS package, rollback will be accomplished by
untagging the new Greenboot-RS package in Koji.
* Contingency mechanism: Users may uninstall the Greenboot-RS package
and the Bash Greenboot package will remain in service.
* Contingency deadline: 08-12-2025
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney