What is Fedora?
by Philip Wyett
Hi all,
Obviously many will have seen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
and see, where EL (contributors like you of fedora/EPEL) have been knocked down:
https://bugzilla.redhat.com/show_bug.cgi?id=2215299
Let us face it our efforts with the Fedora project are not valued and it is a means nothing to the
new corporate IBM/Red Hat enterprise systems that we have to struggle to get access to srpms, to
make a community. What is community now to Red Hat?
I see an impasse here. Why contribute to fedora when Red Hat will lock it down in other products?
Regards
Phil
--
*** Playing the game for the games own sake. ***
Associations:
* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.
WWW: https://kathenas.org
Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg
Twitter: @kathenasorg
Instagram: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
4 months, 4 weeks
F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/cleanup_systemd_install
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 ==
Fedora default installs with a shim + grub bootloader on EFI
platforms, yet has been shipping systemd-boot in various forms for a
number of releases. There are a few howto's which describe how to
replace grub with systemd-boot with varying levels of functionality.
This should be easier with a formalized default method that can be
built upon. This proposal aims to complete the work started with
anaconda (inst.sdboot), kickstart (bootloader --sdboot) such that the
"everything" media can install a grub free machine.
== Owner ==
* Name: [[User:jlinton| Jeremy Linton]]
* Email: <jeremy.linton(a)arm.com>
* Name: Possibly others since it may touch -comps, systemd-boot, etc
== Detailed Description ==
As a first pass, the 'inst.sdboot' option already in anaconda should
work. As it stands, that replaces grub+shim with the systemd-boot
loader, and moves the kernel + initrd to the EFI system partition
(ESP). It doesn't attempt to create unified kernel images, so the
existing `dnf update`, `kdumpctl`, and `make install` in a kernel
source directory should all work. The vast majority of this work has
been done, leaving only two action items, removing grubby from core,
and merging a shimming package (sdubby) into the fedora repos.
Beyond that there are various enhancements which can be made to remove
the /boot partition (leaving the EFI at /boot/efi), enrolling fedora
keys if the secure boot mode is "Setup", adding options to enable
shim+systemd-boot, assuring that there is a systemd-boot-signed
package, etc.
The advantages of just enabling the systemd-boot loader without UKIs
or restructuring the /boot and /boot/efi mount points result in a
wider range of supported machines and a more familiar environment for
users and applications. AKA, by not changing the HostOnly/initrd build
process the vast majority of UEFI machines are supported.
To be clear the intention isn't to replace grub, but to co-exist
alongside as an alternative bootloader.
== Feedback ==
== Benefit to Fedora ==
Fedora is considered a forward looking distro. As systemd-boot and
UKIs gain traction it should be straightforward for users/testers to
try out this option in their own environments with a well defined
configuration.
Potentially in the future, once secure boot/etc is straightened out
the simpler/cleaner code base may prove to be more secure, or a
consistent set of measured boot PCRs may enable a simpler (for the end
user) encrypted storage environment.
== Scope ==
* Proposal owners:
At the moment two things remain open:
https://pagure.io/fedora-comps/pull-request/838
and:
https://bugzilla.redhat.com/show_bug.cgi?id=2134972
Both of which are largely in the "needs more discussion" state, but
otherwise are complete as they stand.
There is also an open kexec-tools + aarch64 zboot set that needs to be
merged in order to support kdump properly on aarch64 platforms,
although that problem is caused by zboot and affects grub as well.
Zboot is required for systemd-boot at the moment.
* Other developers:
Depending on the results of the discussion above: Its possible the
systemd maintainers, kdumpctl, etc may need changes.
* 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 Community Initiatives:
== Upgrade/compatibility impact ==
Ideally nothing as we aren't deprecating or changing the shim + grub boot paths.
== How To Test ==
# Have a VM or non critical test machine that can be reinstalled at will.
# Assure secure boot is disabled or in setup mode.
# Pass `inst.sdboot` on the kernel/grub command line presented on the
install media and install as normal.
## possibly adding additional space to the EFI system partition during
partitioning to guarantee there is sufficient space for the number of
bootable kernels active on the machine (~100MB each should be more
than sufficient)
## Alternatively `--sdboot` can be added to the bootloader command in
kickstarts, and the partitions/etc adjusted there
# Use the machine as normal.
# Report issues during upgrades, or with any packages that can't find
kernel images. Everything besides the loader entries, kernel image,
and generated initrds should remain in /boot.
== User Experience ==
Ideally, after the initial install the fedora experience should
generally remain the same. There may be slight differences in boot
timings (at least on aarch64 possibly slightly faster) and the bootctl
utility may have more information and work properly.
== Dependencies ==
Systemd-boot, described in the comps and sdubby review.
== Contingency Plan ==
== Documentation ==
*https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-sdboot
or
*https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#bootloader
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
5 months
F39 Change Proposal: Build Fedora Workstation live ISO with Image
Builder (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
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 ==
Image Builder is a set of modern tools for building operating system
images. Its goal is to make the builds reliable and reproducible.
Moreover, it's designed to give the end users a simple workflow to
build their own custom images. The aim of this change is to switch the
build tool for Fedora Workstation live ISO from livemedia-creator to
Image Builder.
== Owner ==
* Name: [[User:obudai|Ondřej Budai]]
* Email: obudai(a)redhat.com
* Name: [[User:Supakeen|Simon de Vlieger]]
* Email: supakeen(a)redhat.com
* Name: [[User:jkonecny|Jiří Konečný]]
* Email: jkonecny(a)redhat.com
== Detailed Description ==
Image builder is currently getting support for building
[https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs].
Once the PR implementing the new image type is merged,
[https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7f...
the pungi-fedora configuration] needs to be updated. This change will
ensure that pungi creates an osbuildImage task in koji instead of the
currently used livemedia one.
Pungi and Koji already support Image Builder, so no additional work is
required there (refer to the
[https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-bui...
pungi] and [https://github.com/osbuild/koji-osbuild/ koji]
documentation). The only missing part in terms of infrastructure is
provisioning ppc64le worker machines for Image Builder, see the
relevant [https://pagure.io/fedora-infrastructure/issue/11243
fedora-infra ticket].
Note that Image Builder is already used for
[https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild
building ISOs and raw disks of Fedora IoT]. Therefore, this proposal
does not introduce a new tool to the Fedora build pipeline.
== Feedback ==
Currently, Image Builder does not populate the DNF database correctly,
leading to all RPMs installed on the target system being marked as
user-installed. This is [https://github.com/osbuild/osbuild/issues/455
a known issue] that the team is planning to address as soon as the
initial support for live ISOs is merged.
== Benefit to Fedora ==
The maintainer team of Image Builder believes that the project
undergoes more comprehensive testing compared to
lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora
should experience fewer issues with the image building pipeline.
Another advantage is the project's emphasis on making Image Builder
more user-friendly. End users can easily build their own customized
version of the live ISO using a simple
[https://www.osbuild.org/guides/image-builder-on-premises/blueprint-refere...
TOML blueprint file] and a
[https://www.osbuild.org/guides/image-builder-on-premises/building-an-imag...
CLI interface]. This approach, utilizing well-known file formats, is a
positive step compared to livemedia-creator's kickstart files. More
information about building customized images can found on
[https://major.io/p/build-custom-centos-stream-cloud-image/ Major
Hayden's blog] or in
[https://www.youtube.com/watch?v=PsQySAEOeFs&t=17001s a conference
talk] given by Ondřej Budai, one of the proposal owners. Moreover,
Image Builder provides [https://github.com/osbuild/cockpit-composer/ a
graphical interface] for visually defining blueprints, further
simplifying the workflow.
We believe that Image Builder can also be beneficial to the
[https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely
aligns with their objective of providing a simple method for building
up-to-date, customizable images.
== Scope ==
* Proposal owners:
Finishing implementing support for the live ISO upstream and
collaborate with release engineering to switch the pungi config to use
Image Builder.
* Other developers:
Our focus for this change is specifically on Fedora Workstation.
Nevertheless, we are open to collaborating with all spins/SIG to
transition their build pipelines to Image Builder. However, for the
initial switch, we aim to minimize the impact by focusing on a single
artifact. We anticipate that more artifacts will be transitioned in
subsequent releases of Fedora Linux.
* Release engineering: [https://pagure.io/releng/issue/11500 #11500]
Provide ppc64le machines to Image Builder. Switch the pungi config to
use Image Builder.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
There shouldn't be any. The goal of this proposal is to build the same
images as livemedia-creator does, just using a different tooling.
== How To Test ==
Once the pungi config is changed, grab the ISO built by Image Builder
and test if there are any unexpected changes.
== User Experience ==
No change is expected.
== Dependencies ==
The Workstation SIG and the installer team are working on a change to
use the new installer web UI for the Workstation live ISO. We are
fully aware of this change and have the capability to build ISOs with
and without the new UI. As a result, these changes should be
independent of each other. Furthermore, the installer and Image
Builder teams are closely collaborating, ensuring that any issues that
may arise can be addressed with high priority.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Release
engineering to revert the change in pungi, so that the old tooling is
used instead.
* Contingency deadline: Final freeze (the change is trivially revertible)
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
Fedora Workstations ISOs are now built using Image Builder instead of
the legacy tooling used before.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
5 months
more distinct default bash prompt?
by Jens-Ulrik Petersen
In Fedora the bash prompt is not colored or highlighted by default.
I personally find this a usability issue: it makes it hard to find previous
commands between long outputs when scrolling back in a terminal. Of course
in my own host I have a custom prompt, but it means whenever I am using a
different Fedora/Centos/RHEL system or vm, the prompt is not highlighted by
default, which I miss.
Since I spent a little time thinking about and investigating this I thought
I would write to start a discussion here.
I noticed that Ubuntu has a bold green and blue prompt and NixOS has a
green one by default, though not Archlinux or OpenSuSE I think.
I think it would be nice to have a distinctive prompt by default, or at
least a very easy way to get one permanently (ie in a single command: even
if that were `dnf install bash-color-prompt` or running say `colorprompt`
once).
For example I could suggest we change the default fedora bash prompt from:
PS1="[\u@\h \W]\\$ "
to something like:
PS1="\[\e[\${PROMPT_COLOR}m\][\u@\h \W]\[\e[0m\]\\$ ".
Then the PROMPT_COLOR envvar would make it easy for users to change or
customize their prompt coloring anyway.
For example with PROMPT_COLOR="1;32" one gets a bold green prompt, which
seems readable in both dark or light terminals.
What do people think overall? Are there other pros and cons of a color
prompt?
Any better ideas or direction?
Jens
5 months
F39 Change Proposal: LLVM 17 (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/LLVM-17
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 all llvm sub-projects in Fedora Linux to version 17.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 17, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang16, llvm16, and lld16 will be added to
ensure that packages that currently depend on clang and llvm version
16 libraries will continue to work.
Other notable changes:
* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt. Package owners of
packages that read or write this directory will need to update their
packages when rebuilding against/with LLVM 17. The
%clang_resource_dir helper macro can be used to make this transition
smoother, and packages are encouraged to update to use this macro even
before the LLVM 17 update.
* Along with the Clang Resource Directory change, compiler-rt will now
install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of
/usr/lib64/clang/17/lib/
* The macros.clang file with RPM macros will be moved from the
clang-devel package to the clang-resource-filesystem package.
===LLVM Build Schedule===
We will be changing our build schedule slightly from previous Fedora
releases. We will now plan to ship a release candidate in Fedora
build prior to the Beta Freeze rather than waiting until after.
====Important Dates====
* July 28: Upstream: 17.0.0-rc1 Release
* Aug 8: Fedora: f39 branch created
* Aug 11: Upstream: 17.0.0-rc2 Release
* Aug 22: Fedora: f39 Beta Freeze
* Aug 25: Upstream: 17.0.0-rc3 Release
* Sep 8: Upstream: 17.0.0 Release
* Oct 10: Fedora: f39 Final Freeze
====Plan====
# Build LLVM 17.0.0-rc1 in COPR.
# Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc1 into a f39 side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a f39 side-tag in Koji.
# Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not
ready) prior to the Beta Freeze.
# Continue building new release candidates and pushing them to stable
until the Final Freeze.
We are not planning to push 17.0.0-rc1 into rawhide because the
library ABI is not stabilized at that point. Typically, the ABI
stabilizes after -rc2, but there are no guarantees from upstream about
this. Given the history of minimal ABI changes after -rc2, we feel
like it's safe to push -rc2 into rawhide. The worst case scenario
would be an ABI change -rc3 that we force us to patch LLVM to maintain
compatibility with the -rc2 ABI. This scenario would not require
rebuilding LLVM library uses in Fedora, so this would not require much
extra work from our team.
Updates after 17.0.0-rc2 will generally be very small and can be done
after the Final Freeze is over. If we are late packaging -rc3 or the
final release, we will not ask for a Final Freeze exception, unless
they contain a fix for a critical release blocking bug.
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Do scratch builds of Fedora packages that depend on llvm and report
issues to package maintainer.
* Other developers:
** Fix build issues found with LLVM-17 or switch their package to use
the llvm16 compat libs. The LLVM team no longer plans to block Bodhi
updates on dependent packages that fail to build or run with LLVM-17.
There should be around 6-8 weeks between when -rc1 lands in koji and
the Final Freeze for package maintainers to fix issues uncovered with
the LLVM-17 update.
* Release engineering: [https://pagure.io/releng/issues/11455]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
17.
== User Experience ==
== Dependencies ==
Packages that depend on one of the llvm packages will need to be
updated to work with LLVM17 or will need to switch to using one of the
llvm16 compat packages.
== Contingency Plan ==
* Contingency mechanism: If there are major problems with LLVM 17,
the compatibility package provide a way for other packages to continue
using LLVM 16.
* Contingency deadline: Beta Freeze
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 17:
*llvm
*clang
*lld
*lldb
*compiler-rt
*libomp
*llvm-test-suite
*libcxx
*python-lit
*flang
*mlir
*polly
*libclc
*llvm-bolt
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
5 months
Announcing fmt library soversion bump
by Vitaly Zaitsev
Hello.
fmt 10.0.x update will include a soversion bump from .9 to .10. It has
both API and ABI changes.
Changelog: https://github.com/fmtlib/fmt/releases/tag/10.0.0
The list of affected packages in Rawhide:
0ad
OpenImageIO
bear
cachelib
cantera
ceph
dnf5
dolphin-emu
domoticz
easyeffects
easyrpg-player
fb303
fbthrift
fizz
fmidi
folly
freeopcua
gerbera
giada
gnuradio
gr-funcube
libsemigroups
libsonata
luxcorerender
mcrouter
mkvtoolnix
nheko
proxygen
rstudio
sdrpp
spdlog
vcpkg
wangle
watchman
waybar
zswap-cli
I will use my proven-packager rights to rebuild all dependent packages
in a separate side tag next week.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5 months, 1 week
Red Hat & Fedora -- largely stepping out of this ecosystem
by Jeff Law
I have no illusions that this message is going to change anything at Red
Hat. But I feel I need to get this off my chest. I'm speaking strictly
for myself, not for my current or any former employer, not for the GCC
project and not for any other group/organization I might have some
affiliation with.
--
First a bit of background. I came to Red Hat via the Cygnus
acquisition. My combined service spanned nearly 30 years. During that
time I had the opportunity to be involved in the formation of Fedora,
strategic planning for RHEL while at the same time being able to spend
much of my time on optimizing compilers.
I left Red Hat in 2021 to refocus on what I really enjoy in a small
company where I can make a clear difference in the company's direction
and success. It was, by far, the most difficult decision in my
professional career. I left many friends and colleagues behind.
The point being I had a fantastic career at Cygnus/Red Hat. I got to do
and learn things I never could have imagined. I got to work with many
amazing people spanning many organizations within the company
(engineering, sales, marketing, legal, product management, executives,
etc). By no means do I consider myself a disgruntled former employee.
--
What Red Hat has done recently is depressing, but not a huge surprise to
me. Red Hat struggled repeatedly with how to deal with "the clones".
The core idea I always came back to in those discussions was that the
value isn't in the bits, but in the stability, services and ecosystem
Red Hat enables around the bits. Arguments for protecting the bits were
met with something like "if that's what we need to do to be successful,
then we're failing to provide real value".
At some point in the last 20 years (I forget exactly when) Red Hat was
looking to codify its values. Naturally the topic of open source came
up during those discussions. When open source didn't make the cut, one
could say the writing was on the wall -- open source was a means to an
end. In my mind that opened the door for numerous changes we've seen in
subsequent years.
One could see signs of where this was going with the adjustments that
were made to the exposed RHEL kernel sources some time ago. Then the
dissolution of CentOS a couple years back and most recently with the
lockdown of the RHEL sources.
What Red Hat has done may be technically legal and perhaps good for its
business. However, to me it's ethically unconscionable. Those who
know me know I'm not an zealot, but I do have a baseline set of ethical
values and Red Hat crossed that line.
--
Back in 2002 or 2003 when we were trying to figure out how to salvage
the ill-fated "Red Hat Community Linux Project" resulting in what we now
know as Fedora, one of the key concepts that we pushed to the
executive team at Red Hat was that it was strategically important for
both Fedora and Red Hat to have a strong association with each other. I
think we largely succeeded in building that close association.
I've been a Fedora user since before FC1. I run Fedora on my laptop.
When I need a docker image for something, I start with a Fedora image.
When I need to spin up a server (say to run the GCC CI/CD system) I load
it with Fedora. It's an ecosystem I'm technically comfortable in and
easiest for me to utilize.
That will change across the board this summer. That's a bit hard for me
to swallow, but I can't get past that association we built between Red
Hat and Fedora and Red Hat's recent actions.
I'll still have to deal with the RHEL/CentOS/Fedora ecosystem on a
professional level. Obviously, I'll do what I need to do to help make
my employer successful -- but when a choice exists, Fedora/CentOS/RHEL
won't be where I land going forward.
I wish it hadn't come to this, but I also can't say I'm terribly surprised.
Thanks for your time,
Jeff
5 months, 1 week
Proposal: drop delta rpms (for real this time)
by Matthew Miller
I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
priority. Last time we talked about this we didn't really get anywhere...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
... and that ticket hasn't moved, because fixing it isn't trivial.
What we're doing now — as has been the case for several years, already noted
in the previous discussion — has very little end-user value. Also as noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)
But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give DeltaRPMs a
sad, fond farewell.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5 months, 1 week
How to deal with sysusers files inside the package
by Ewoud Kohl van Wijngaarden
I'm looking at converting my package (where I'm also the upstream) to
use sysusers.d but I'd prefer shipping the sysusers.d file inside the
source tarball rather than in packaging. This allows me to use the same
definition on Debian, which I think is a huge benefit of systemd
standardizing these kinds of things.
The documentation[1] only mentions shipping it as a separate source, not
inside the tarball. Should I simply replace %{SOURCE3} in the docs with
the path from the extracted tarball? If so, is this something that the
packaging-guidelines should document?
I also noticed that %sysusers_create_compat isn't in EL8 and I'd rather
not depend on epel-rpm-macros. Today we build completely outside of EPEL
and I'd prefer to keep it that way. Is the recommended way to use
%sysusers_create_package (provided by systemd-rpm-macros) instead?
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
5 months, 1 week
