Gentoo Repository News
Haskell destabilization - 29/09/2024 00:00 GMT
Packaging Haskell software has proven difficult in Gentoo: many packages are outdated, unstable versions have not been stabilized in nearly a year, and stable versions are rather old. In an effort to reduce the load on the Haskell maintainers, stable keywords will be removed from dev-haskell/* packages and their reverse dependencies on October 1. Users with Haskell packages should add entries to their package.accept_keywords for these packages to avoid issues rebuilding or upgrading them in the future. This change does not preclude stabilizing Haskell packages in the future. Haskell packaging is mostly taking place in the Haskell repository [1]. [1] https://github.com/gentoo-haskell/gentoo-haskell
Posted By: Matt Turner
KDE Plasma 6.1.4 and Gear 24.05.2 Upgrade - 31/08/2024 00:00 GMT
Reasons
=======
KDE Plasma 5 has reached end of life and is no longer supported by Gentoo.
Qt5 upstream OSS support ended on 2020-12-08, and LTS releases - even with
considerable effort by KDE community's backports on top - only go so far.
It is therefore required for all users to upgrade to KDE Plasma 6[1].
At the same time, KDE Gear 24.05.2 is provided with most applications ported
over to KDE Frameworks 6. As long as KF5-based applications are being shipped
with the KDE Gear bundle, and other non-KDE Qt5-based applications still
common in ::gentoo repository, it is advised *not* to disable USE="qt5".
Changes
=======
Not many - much like Qt6, this is mostly an evolution of the existing
codebase, no disruptive feat.
Plasma Wayland support has come a long way and therefore KDE developers have
decided to make it the default login session for Plasma 6, even if some
known papercuts[2] remain. For users affected too much by those, switching
to the still existing X11 session is as easy as selecting it in the display
manager of choice. Disabling USE="wayland" is *not* changing this default,
it will yield no dependency savings, and we advise against doing so. It does
not affect users' X11 sessions.
In Gentoo:
The 32-bit ~arm/arm keyword was inconsistent across KDE Plasma, KDE
Frameworks, and KDE Gear, and has been dropped.
The situation for x86 was similar to arm and test failures often blocked
stabilization. Stable x86 has been dropped, ~x86 was dropped for KDE PIM,
dev-util/kdevelop and any other dev-qt/qtwebengine:6 reverse dependencies.
User Action Required
====================
For users of a desktop profile[3], no specific upgrade steps are necessary,
although some precautionary measures are advised before and during upgrade:
- Switch to a standard (Breeze or Oxygen) theme
- Depclean kde-misc/latte-dock, it is unfit for Plasma 6 (and masked already)
- Cleanup sets and @world from any SLOT or version pinning of KDE packages
- If possible, perform the upgrade not inside a running Plasma session
Necessary USE flag changes were already made in desktop profile, therefore
only users of other profiles should set USE="kf6compat qt6" globally[4].
Users are recommended to run the following command (pretend-only) to identify
packages in @world which have been removed, to help reduce conflicts:
emerge -pev @world --backtrack=0
Then for any "no ebuild available" messages, either resolve it by making
the needed changes, or emerge --deselect them. Then proceed to the world
upgrade below.
Once the packages become available on your arch, it should be as simple as
update @world:
emerge -avuUD @world
Run dispatch-conf (preferred) or etc-update to get updated configuration
files:
dispatch-conf
Then depclean:
emerge -ac
[1] https://kde.org/plasma-desktop/
[2] https://community.kde.org/Plasma/Wayland_Known_Significant_Issues
[3] https://wiki.gentoo.org/wiki/KDE#Profile
[4] https://wiki.gentoo.org/wiki//etc/portage/package.use
Posted By: Andreas Sturmlechner
dracut module config changes - 09/08/2024 00:00 GMT
Starting with dracut-102, cryptsetup support for systemd has been moved into a separate module "systemd-cryptsetup". Under specific conditions, this change may cause a failure to boot. [1] Users who are not using cryptsetup at all will not be affected. Users who use the "dracutmodules" config option to explicitly name all modules to be included may be affected if they fail to update their dracut configuration to include the new "systemd-cryptsetup" module. Users who have not altered the default config or who are not using the "dracutmodules" option should not be affected. The dracut.conf(5) manual page warns against using "dracutmodules". Instead, "add_dracutmodules" and "omit_dracutmodules" can be used to to alter the default module list with less risk of omiting modules by accident. [1] https://bugs.gentoo.org/937326
Posted By: Mike Gilbert
Gentoo drops IA-64 support - 07/08/2024 00:00 GMT
Following the removal of IA-64 support in the Linux kernel and glibc, and subsequent discussions on our mailing list [1], as well as a vote by the Gentoo Council [2,3], Gentoo will discontinue all ia64 profiles and keywords. The primary reason for this decision is the inability of the Gentoo IA-64 team to support this architecture without kernel support, glibc support, and a functional development box. In one month, all ia64 profiles will be removed, all ia64 keywords will be dropped from all packages, and all IA-64 related Gentoo bugs will be closed. [1] https://public-inbox.gentoo.org/gentoo-dev/75654daa-c5fc-45c8-a104-fae43b9ca490@gentoo.org/T/ [2] https://projects.gentoo.org/council/meeting-logs/20240721.txt [3] https://projects.gentoo.org/council/meeting-logs/20240721-summary.txt
Posted By: Arthur Zamarin
Upgrading to TeX Live 2023 - 05/06/2024 00:00 GMT
Upgrading to TeX Live 2023
==========================
We will soon start the stabilization of TeX Live 2023 in Gentoo.
Since TeX Live 2023 underwent a major overhaul, including TeX Live package
moves between the according Gentoo packages, there are file conflicts
between Gentoo's TeX Live 2021 and 2023 packages. To avoid those
conflicts, it is recommended to uninstall all of dev-texlive prior
updating TeX Live to version 2023.
Before uninstalling dev-texlive packages, first check if your system has
a pending texlive update (1). If this is the case, uninstall the old
dev-texlive packages (2) and emerge the update (3).
1. emerge -p '>=app-text/texlive-2023'
[only proceed if texlive update is available]
2. emerge --unmerge --deselect=n 'dev-texlive/*'
3. emerge '>=app-text/texlive-2023'
The steps above are equivalent to the following bash snippet:
if emerge -p '>=app-text/texlive-2023'; then
emerge --unmerge --deselect=n 'dev-texlive/*'
emerge '>=app-text/texlive-2023'
fi
Posted By: Florian Schmaus
Changes to dracut kernel module/microcode handling - 17/05/2024 00:00 GMT
Impact
====================
Several changes were made regarding out-of-tree kernel modules, CPU
microcode, and how these are handled in initial RAM file systems
(initramfs) generated by sys-kernel/dracut for distribution kernels.
Depending on the local Dracut and USE flag configuration, some
configuration adjustments may be required as a result of these changes.
Background (the problem)
====================
Previously Dracut implicitly included all out-of-tree kernel modules
it could find. This leads to several problems:
- It unnecessarily increases the size of the initramfs
- It creates a bit of a mess when using distribution kernels, consider
the following:
1) Distribution kernel is upgraded
2) Initramfs for the new kernel is generated, it does not include
any out-of-tree kernel modules.
3) Portage triggers rebuild of the out-of-tree kernel modules
4) If zfs is installed, its rebuild will trigger an initramfs
re-installation. Otherwise no rebuild is triggered.
Problem: What is and is not included in the initramfs is now
ambiguous. It depends on the emerge order of the kernel modules
when zfs is used. And will completely change if at some later stage
regeneration of the initramfs is triggered manually via e.g.:
emerge --config sys-kernel/gentoo-kernel
As a result, Dracut's "--reproducible" setting is not working. And
the functionality of the initramfs may change (seemingly) at random.
Background (the fix)
====================
Several things have been changed:
- Out-of-tree kernel modules installed by portage are explicitly omitted
from the initramfs generated by Dracut by default.
- Packages that install a kernel module for which it might make sense to
have it in the initramfs, have gained the "initramfs" USE flag. When
this flag is enabled, Dracut is instructed to include the installed
kernel modules. Packages for which it is essential that its kernel
modules are included in the initramfs have this new flag enabled
by default.
- When distribution kernels are used (USE=dist-kernel), and a module
that should be in the initramfs is installed (USE=initramfs) the
initramfs is always re-generated.
- The packages installing CPU microcode (sys-kernel/linux-firmware
and sys-firmware/intel-microcode) have been adjusted to mirror the
above changes for out-of-tree kernel modules. Both packages
have gained the "dist-kernel" USE flag, and the "initramfs" flag is
now enabled by default. When both flags are enabled, Dracut is
configured to include the installed microcode in the initramfs, and
then the initramfs is regenerated. When the "dist-kernel" flag is
disabled, the "initramfs" flag behaves as it previously did.
User Action Required (Dracut and/or Distribution Kernel users)
====================
Users of sys-kernel/dracut and/or Distribution Kernels should double
check two things:
1) Please ensure that you are *not* globally enabling or disabling
the "initramfs" USE flag. Enabling it globally might result in an
unnecessarily large initramfs. Disabling it globally might result
in missing functionality in the initramfs. Which could lead to boot
failure if, for example, the zfs module is missing while the root
partition is a zfs.
2) Any add_drivers, or omit_drivers lines in /etc/dracut.conf or
/etc/dracut.conf.d/* may override the Dracut configuration snippets
installed by the kernel module packages in
/usr/lib/dracut/dracut.conf.d. Please review your Dracut
configuration files to ensure that you are not unintentionally
overriding the settings set by Portage.
User Action Required (other users)
====================
Other users may wish to disable the "initramfs" USE flag on
sys-kernel/linux-firmware and/or sys-firmware/intel-microcode
if they already have other mechanisms in place for updating the CPU
microcode (such as kernel built-in CPU microcode). Users who do not
use sys-kernel/dracut or Distribution Kernels can safely disable
the "initramfs" USE flag globally.
Frequently Asked Questions
====================
A package installing a kernel module I would like in my initramfs has
not gained the "initramfs" USE flag. How do I proceed?
Please report a new bug on bugs.gentoo.org, requesting that the
package maintainer consider adding support to the package for
including the modules in the initramfs. In the meantime you can
locally override the configuration provided by the package (see
below). Note though that when distribution kernels are used,
regeneration of the initramfs must be triggered manually via e.g.:
emerge --config sys-kernel/gentoo-kernel
How do I override the provided Dracut configuration snippets to
include/exclude a custom list of modules?
To override the provided configuration snippet, create a new file
/etc/dracut.conf.d/10-PACKAGENAME.conf, replacing PACKAGENAME with
the name of the package providing the module. Add to this file:
omit_drivers+=" my list of drivers to omit "
and/or
add_drivers+=" my list of drivers to include "
Posted By: Andrew Ammerlaan
Python 3.12 to become the default on 2024-06-01 - 09/05/2024 00:00 GMT
We are planning to switch the default Python target of Gentoo systems
on 2024-06-01, from Python 3.11 to Python 3.12. If you have not changed
the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will
have immediate effect on your system and the package manager will try
to switch automatically on the next upgrade following the change.
If you did change the values, prefer a safer approach or have problems
with the update, read on.
Please note that the default upgrade method switches packages to the new
Python versions as they are rebuilt. This means that all interdependent
packages have to support the new version for the upgrade to proceed,
and that some programs may temporarily fail to find their dependencies
throughout the upgrade (although programs that are already started
are unlikely to be affected).
If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared
in make.conf, please remove these declarations as they will interfere
with the package.use samples provided below. Using make.conf for Python
targets is discouraged as it prevents package defaults from applying
when necessary. This news item assumes using /etc/portage/package.use
or your package manager's equivalent file for configuration.
At this point, you have a few configuration options to choose from:
1. If you wish Python upgrades to apply automatically, you can remove
PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When
the defaults change, your package manager should handle the upgrade
automatically. However, you may still need to run the update
commands if any problems arise.
2. If you wish to defer the upgrade for the time being, you can
explicitly set the old values in package.use.
3. If you wish to force the upgrade earlier, you can explicitly set
the new values and run the upgrade commands.
4. If you wish to use a safer approach (i.e. less likely to temporarily
break packages during the upgrade), you can perform a multi-step
upgrade as outlined below.
5. Finally, you can use an arbitrary combination of PYTHON_TARGETS
and PYTHON_SINGLE_TARGET.
Deferring the upgrade
=====================
To defer the upgrade, explicitly set the old targets:
*/* PYTHON_TARGETS: -* python3_11
*/* PYTHON_SINGLE_TARGET: -* python3_11
This will enforce Python 3.11 and block any future updates. However,
please note that this is only a temporary solution and you will
eventually need to perform the migration.
Forcing the upgrade
===================
To force the upgrade earlier, explicitly select the Python 3.12 targets:
*/* PYTHON_TARGETS: -* python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_12
However, it is important to remember to remove this after the defaults
change, as it will interfere with the automatic switch to the next
Python version in the future.
Safer upgrade procedure
=======================
A safer approach is to add Python 3.12 support to your system first,
and only then remove Python 3.11. However, note that this involves two
rebuilds of all the affected packages, so it will take noticeably
longer.
First, enable both Python 3.11 and Python 3.12, and then run the upgrade
commands:
*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_11
Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:
*/* PYTHON_TARGETS: -* python3_11 python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_12
Finally, switch to the final version and upgrade:
*/* PYTHON_TARGETS: -* python3_12
*/* PYTHON_SINGLE_TARGET: -* python3_12
You may wish to remove the target overrides after the defaults switch.
Alternatively, you can keep them to block the next automatic upgrade
to Python 3.13, and upgrade manually then.
Upgrade commands
================
The Python 3.11 cleanup requires that Python 3.11 is removed from
the complete dependency trees in batch. If some of the
installed packages using an older Python version are not triaged
for the upgrade, the package manager will throw dependency conflicts.
This makes it important that the upgrade is carried via a --deep
--changed-use @world upgrade, as well as that any stray packages
are removed prior to it, e.g.:
emerge --depclean
emerge -1vUD @world
emerge --depclean
Posted By: Michał Górny
dev-lang/perl useflags become a PERL_FEATURES use-expand - 07/05/2024 00:00 GMT
Starting with dev-lang/perl-5.38.2-r3, the three use flags "debug", "ithreads", and "quadmath" of Perl are renamed into a common use-expand variable, PERL_FEATURES, which should be set *globally* in make.conf. If you do *not* want to change the settings of your Perl, make sure that the new variable PERL_FEATURES contains the same settings that were applied to your Perl all along. I.e., if you have dev-lang/perl[ithreads] installed, make sure to now set in make.conf PERL_FEATURES="ithreads" If you *want* to change the settings of your Perl, you may have to run perl-cleaner after rebuilding dev-lang/perl: perl-cleaner --modules ; perl-cleaner --force --libperl In either case, a full world update emerge -uDNav world is recommended and should also bring your system into a consistent state. Background: This change in the structure of the useflags is intended to solve bug 930123. The three useflags influence not only how Perl itself is installed, but also all Perl modules...
Posted By: Andreas K. Huettel
media-video/wireplumber-0.5.2 may break on upgrade - 06/05/2024 00:00 GMT
As some will be aware, WirePlumber 0.5.0 introduced a significant breaking change to its entire configuration system, eliminating the use of Lua scripts for configuration purposes. This also came with a complete rework of how Lua scripts are registered with WirePlumber for execution. Most typical desktop users, including EasyEffects users, should not notice any change to their system. That said, it was not uncommon for people to suggest or implement configuration changes using the Lua API. Any custom functionality which relies on WirePlumber's Lua API will break upon upgrade. If you rely on this functionality, please review the WirePlumber documentation on porting your Lua scripts to the new API and registering them with the system before upgrading: https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/migration.html
Posted By: James Calligeros
Profile upgrade to version 23.0 available - 22/03/2024 00:00 GMT
A profile upgrade to version 23.0 is available for your architecture.
The new 23.0 profiles enable some toolchain hardening features and
performance enhancements by default, and standardize settings.
You can find the list of changes on the wiki tracking page [1].
We strongly advise to precisely follow the upgrade instructions found
below. The 17.0, 17.1, 20.0, and 22.0 profiles will be marked deprecated
in 2 months and removed a year later. The exact dates may depend on the
architecture, see [2].
Upgrade instructions
Note 1: If you have manually changed your CHOST to a value different from
what the stages and profiles set, you may have to do that in the future too.
In that case you should know what you are doing, hopefully; please read the
instructions with a critical eye then.
Note 2: In case you are already familiar with binary packages, you should be
able to add "--getbinpkg" to the emerge calls to speed things up.
The use of binary packages is completely optional though, and also not
as much tested as the source-based upgrade path yet.
1. Ensure your system backups are up to date. Please also update
your system fully and depclean before proceeding.
glibc older than 2.36 and musl older than 1.2.4 is not supported anymore.
2. If you are still using one of the long-deprecated amd64 17.0 profiles
(other than x32 or musl), then first complete the migration to the
corresponding 17.1 profile. Instructions can be found at [3].
3. If you are currently using systemd in a split-usr configuration, then first
complete the migration to the corresponding merged-usr profile of the
same profile version. Details on how to do this can be found in the news
item [4].
If you are currently using openrc, migrate to 23.0 first, keeping your disk
layout. If you want to move from split-usr to merged-usr, do that afterwards.
4. Run "emerge --info" and note down the value of the CHOST variable.
5. Edit /etc/portage/make.conf; if there is a line defining the CHOST variable,
remove it. Also delete all lines defining CHOST_... variables.
6. Select the 23.0 profile corresponding to your current profile, either using
"eselect profile" or by manually setting the profile symlink.
Note that old profiles are by default split-usr and the 23.0 profiles by
default merged-usr. Do NOT change directory scheme now, since this will
mess up your system!
Instead, make sure that the new profile has the same property: for example,
OLD default/linux/amd64/17.1
==> NEW default/linux/amd64/23.0/split-usr
(added "split-usr")
OLD default/linux/amd64/17.1/systemd/merged-usr
==> NEW default/linux/amd64/23.0/systemd
(removed "merged-usr")
A detailed table of the upgrade paths can be found at [5]. Please consult it.
In some cases (hppa, x86) the table will tell you to pick between two choices.
What you need should be obvious from your *old* CHOST value (from step 4).
7. Delete the contents of your binary package cache at $
rm -r /var/cache/binpkgs/*
8. In the file or directory /etc/portage/binrepos.conf (if existing), update
the URI in all configuration such that they point to 23.0 profile binhost
directories. The exact paths can be found in the table at [5], too.
9. Rebuild or reinstall from binary (if available) the following packages in
this order, with the same version as already active:
emerge --ask --oneshot sys-devel/binutils
(you may have to run binutils-config and re-select your binutils now)
emerge --ask --oneshot sys-devel/gcc
(IMPORTANT: If this command wants to rebuild glibc first, do *not* let it do
that; instead, abort and try again with --nodeps added to the command line.)
(you may have to run gcc-config and re-select your gcc now)
and the C library, i.e. for glibc-based systems
emerge --ask --oneshot sys-libs/glibc
or for musl-based systems
emerge --ask --oneshot sys-libs/musl
10. Re-run "emerge --info" and check if CHOST has changed compared to step 4.
If the CHOST has NOT changed, skip to step 13 (env-update). Otherwise,
11. Recheck with binutils-config and gcc-config that valid installed versions
of binutils and gcc are selected.
12. Check /etc/env.d, /etc/env.d/binutils, and /etc/env.d/gcc for files that
refer to the *OLD* CHOST value, and remove them.
Examples how to do this can be found in the similar procedure at [6].
13. Run env-update && source /etc/profile
14. Re-emerge libtool:
emerge --ask --oneshot libtool
15. Just for safety, delete the contents of your binary package cache at
$ again:
rm -r /var/cache/binpkgs/*
16. Rebuild world:
emerge --ask --emptytree @world
[1] https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_transition
[2] https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_profile_timeline
[3] https://www.gentoo.org/support/news-items/2019-06-05-amd64-17-1-profiles-are-now-stable.html
[4] https://www.gentoo.org/support/news-items/2022-12-01-systemd-usrmerge.html
[5] https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table
[6] https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable#Verifying_things_work
Posted By: Andreas K. Huettel