libarrow (Apache Arrow) soname bump in Rawhide
by Kaleb Keithley
Hi,
Apache Arrow 10.0.0 has been released.
At present nobody is using libarrow except Ceph. (Which I am the maintainer
of.)
I will be rebasing libarrow to 10.0.0 within the next couple of days.
--
Kaleb
9 months, 1 week
F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
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 new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny(a)redhat.com
* Name: Fedora Workstation SIG
* Email: desktop(a)lists.fedoraproject.org
== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don’t have previous experience with the Linux
operating system will be able to do the installation smoothly.
List of what is part of the new UI:
* Wizard solution instead of hub and spoke
* New welcome screen to select language (will be preselected from a
language configured in system)
* Timezone and date configuration
* Disk selection
* Guided partitioning
* Review configuration
* Installation progress
* Build-in help
Let’s go over the important sections from the UI.
==== Use of wizard ====
Anaconda was a hub&spoke solution where users entered spoke to
configure an aspect. The benefit of this solution is that you can skip
what you don’t need. However, the drawback is that it’s much more
information at once and harder to use when you are not familiar with
what you need. For that reason, the team decided to go with an easier
to use solution, the traditional wizard. See here for more details
https://communityblog.fedoraproject.org/anaconda-is-getting-a-new-suit-an...
.
==== Guided partitioning ====
The current (GTK) Anaconda UI approach is to have three types of partitioning.
* Automatic - do everything automatically
* Custom - you can do everything with top-down approach where users
work on mount points and specified what technology they want to use
and how
* Blivet-gui - added later as bottom-up approach which enables users
to create the partitioning stack themselves manually
These methods are giving great freedom but each of these has its
issues. For automatic, the issue is almost no customizations and not a
clear output. For custom and blivet-gui, you need to understand the
Linux storage really well to know what you are doing, which could be
intimidating.
Because of those issues, we decided to choose another approach, which
we are calling guided partitioning. This type of partitioning is
giving users paths with explanations of what will happen but does not
overload them with too many options at once. These paths could be then
customized. This solution was taken as the best compromise between the
automatic (no customization) and custom/blivet-gui, which was too
heavy and hard to maintain.
We will provide the recommended solution and improved customization
based on the users feedback. However, in case someone is not happy
about the recommended solution, we are going to provide a way to guide
users, to create their partitioning themselves (with a tool of their
choice) and then tell Anaconda how to use it. This method could be
also used for easy re-installation of the existing system and we are
planning to improve the experience in the future even more.
==== Build-in help ====
Another pain point of the current UI is problematic help content.
Currently, it’s a button that will show a lot of text from the
documentation, which might be misleading because it’s not part of the
feature development. To improve the state, the help side panel was
added, which will provide specific help for what the user wants to
know directly in a UI. For example, if you are in the guided
partitioning screen you can find a link (blue text) with “learn more
about the…” and after clicking on this you will find details about the
given guided path. Another benefit of the new help solution is that it
is part of the source code so it changes with the feature work and
could be localized (harder to achieve before).
==== Changes not directly related to UI ====
The Anaconda team is in contact with Fedora Workstation SIG and
actively working with them to get the best user experience for users.
Together, we agreed on building the approach with the support of Gnome
Initial Setup as part of the Fedora Workstation Live environment,
which will prompt you for language and keyboard layout. Configuration
from the system is then used by Anaconda. This way, Anaconda doesn't
need to ask a second time for language (maybe just confirmation) and
keyboard layout which will be converted from the live system into the
installed system. This should result in a much better user experience.
=== Additional information ===
* We are not planning to add support for spins with this change, they
will use the existing GTK UI.
* We don’t support remote connections to the WebUI yet.
== Feedback ==
Currently we mainly discuss this with Fedora Workstation SIG and have
their support for this change. We also have feedback from our preview
builds https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public/
. The feedback was mostly positive even though there are some
concerns.
Other than that we also reached to Fedora QE team and [[User:Mattdm|
Matthew Miller]] and more.
For more details about the feedback here are some tickets:
* https://pagure.io/fedora-workstation/issue/362
* https://pagure.io/fedora-workstation/issue/366
* https://pagure.io/fedora-workstation/issue/367
* https://pagure.io/fedora-workstation/issue/368
* https://pagure.io/fedora-workstation/issue/371
* https://pagure.io/fedora-workstation/issue/375
* https://pagure.io/fedora-workstation/issue/377
* https://github.com/rhinstaller/anaconda/discussions/categories/web-ui
== Benefit to Fedora ==
Fedora Workstation installation will have a more comfortable and
better user experience, especially for the new-to-distro users. We are
also targeting to have a consistent look and feel with Cockpit and
Image Builder projects, so that users might be more familiar with the
new Anaconda.
By this, we would be more aligned with Fedora Workstation SIG goals of
simple and easy-to-use solutions, and hide the complexities to make
the installation experience more robust.
It should be easier for users to reinstall the existing system.
It will also allow the Anaconda team to make the extensions to the UI
faster than it was before and should be less prone to errors compared
to the current UI.
== Scope ==
* Proposal owners:
** Anaconda team
** Fedora Workstation SIG
* Other developers: Should not have impact out of the Fedora
Workstation Live environment.
* Release engineering: Will be added
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: TBD
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
Standard installation testing of Live installation always before. We
already reached the Fedora QE team to discuss an impact on them and
ideally set the test day for more comprehensive testing with more
details.
Steps:
* Download the ISO image (not yet available - WIP)
* Start a VM with this ISO image
* Run the installation
* See journal log and/or browser console in case we missed error in the Anaconda
Bugs should be filed to [https://bugzilla.redhat.com/ Red Hat
Bugzilla] on the Anaconda component.
== User Experience ==
Installation of the system should provide a much better and more
polished user experience. Compared to the current UI users should be
fine without the familiarity of the complexities of OS installation.
== Dependencies ==
None packages should be impacted by this change. The current GTK UI
will still be available for other uses.
== Contingency Plan ==
* Contingency mechanism: Return back to the current GTK UI by changing
packages to build the ISO.
* Contingency deadline: Beta freeze
* Blocks release? No, we can ship without the new web UI
Another solution for the contingency plan which we would like to have
is support for the current GTK UI as a second UI on the same Live ISO.
That should be doable easily and if the new UI would be really a
blocker for someone, they can provide us feedback and until resolved
use the GTK UI instead.
== Documentation ==
Documentation will be expected especially for custom partitioning
replacement but not only that.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
9 months, 2 weeks
Towards enabling rpm sysusers integration
by Panu Matilainen
Hey all,
Now that the initial hurdle of getting rpm 4.19 into rawhide is over,
it's time to start looking towards enabling the sysusers integration:
https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
We (as in rpm-team) are not pushing for doing all this in Fedora 39,
this is more to start discussion and lay down the necessary steps. In
the 4.19 builds so far, the sysusers integration has been entirely
disabled because it needs more coordination than just drop it in. Much
of it is between systemd and rpm, but any package with non-root
ownerships will be affected in the end. At least the following, and not
necessarily exactly in this order:
1. systemd has it's own user/group provides generator which directly
conflicts (both on generated content and file level) with the new native
generator in rpm, and the feature will not work with the provides
generated by systemd.
2. systemd provides users and groups that are actually owned by the
setup package. As rpm is now turning non-root file ownership into
dependencies, systemd could end up pulled in where setup is needed (eg
early install stage) which will not end up well. So systemd will need to
stop providing users it does not actually own.
3. The various %sysuser_()* macros in systemd-rpm-macros need to be
phased out. As it'll be a long time before the sysusers feature is in
all Fedora versions, it needs a longer term plan. One simple possibility
is do what was done with all those ldconfig from %post back then: change
the %sysusers_() macros to no-ops in rawhide to let rpm handle it, and
only actually bother updating packages once all relevant versions have
the sysusers feature.
4. The sysusers "hook" in rpm needs to be enabled (uncomment
%__systemd_sysusers macro in rpm). It wont do anything at all before 1)
and 3) are done though.
6. The user/group dependencies for non-root users need to be turned into
hard requires (initially these are just recommends). I would be suprised
if this doesn't cause some disruption somewhere, although the content
that is not root:root owned is pretty scarce these days.
7. Packages creating or using non-root user/group need to be rebuilt.
7. One day a few years from now, replace
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
with "supply a sysusers file for your needs" :P
In reality, it'll need adjusting long before that and for that, it'll
need FPC recommendations and all.
8. Remove all user/group addition related macro and script fubar from
specs for good. The first commit in rpm source tree is from 1995, it'd
be a nice 30 year celebration... but I don't expect it to happen quite
that soon. Maybe in 2035 new people will start look at old specs in
horror, "What do you mean they had to deal with all this user/group
stuff manually! For 30 years!"
I've begun from 1) now:
https://src.fedoraproject.org/rpms/systemd/pull-request/109
https://src.fedoraproject.org/rpms/rpm/pull-request/45
After those have been done, people can start experimenting with the
feature. I don't remember seeing an actual Fedora Change for either
file-trigger enablement or current %sysuser_* macros so I'm not sure
it's needed here either?
Comments, thoughts etc?
- Panu -
9 months, 2 weeks
Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
by Demi Marie Obenour
I noticed that by default, Qubes OS has voluntary kernel preemption
as opposed to full preemption. I found that enabling full preemption
(preempt=full on kernel command line) makes the system significantly
more responsive under heavy I/O load. In particular, if I build a
kernel in a Qubes OS VM, it significantly degrades responsiveness
without preempt=full. With preempt=full, the system remains
responsive. The storage stack used is LVM thin provisioning on LUKS,
and I have observed significant CPU usage in dom0 kernel threads with
names that indicate they are related to dm-thin and dm-crypt.
The kernel config used by the Qubes kernel package I use (6.1.28) is
based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd)
indicated that the same arguments apply to Fedora. Therefore, I am
asking if Fedora should use full kernel preemption by default.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
9 months, 2 weeks
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
9 months, 3 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
9 months, 3 weeks
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
9 months, 4 weeks
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
10 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
10 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)
10 months