Gentoo Repository News
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
installkernel is no longer implicitly installed - 26/02/2024 00:00 GMT
/sbin/installkernel is a script called by the kernel's "make install" as well as by the distribution kernel's post-install phase. If you are reading this then chances are you use and rely on installkernel[1] and what follows is essential for you. Previously sys-kernel/installkernel was implicitly installed on many systems via a dependency in sys-apps/debianutils. This dependency was toggled by the "installkernel" USE flag, and enabled by default. Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. However, this dependency of app-misc/ca-certificates on sys-apps/debianutils was removed[2]. As a result many users may find that sys-apps/debianutils and therefore sys-kernel/installkernel are no longer part of the dependency graph and will therefore be cleaned up by "emerge --depclean". Removing sys-kernel/installkernel from your system WILL change the way kernels are installed by "make install"! Instead of the versioned /boot/vmlinuz-x.y.z that you are used to, "make install" will simply copy bzImage (or equivalent for your arch) into /boot. This image may not be picked up by your bootloader or its configuration tools. To avoid surprises from such implicit dependencies from happening again in the future, the dependency on sys-kernel/installkernel in sys-apps/debianutils is removed. And as such, sys-kernel/installkernel is only installed on the system if it is either explicitly selected or pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)). User Action Required (users of manually managed kernels) ==================== Users who manually configure, compile, and install their kernels, i.e. users of the sys-kernel/*-sources packages, and who wish to continue to use sys-kernel/installkernel, must ensure that it is explicitly selected by emerging it: emerge --noreplace sys-kernel/installkernel Users who find that sys-kernel/installkernel has already been cleaned from their systems and are therefore affected by the change in kernel installation described above should re-install sys-kernel/installkernel and then re-install their kernel. emerge sys-kernel/installkernel cd /usr/src/linux # (or other location of the kernel sources) make install No manual action is required for users of the distribution kernels: - sys-kernel/gentoo-kernel, or - sys-kernel/gentoo-kernel-bin, or - sys-kernel/vanilla-kernel [1] https://wiki.gentoo.org/wiki/Installkernel [2] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e6ccafd58bc7401fa371d2f255d72ddae0131e6
Posted By: Andrew Ammerlaan
GRUB upgrades - 01/02/2024 00:00 GMT
When booting with GRUB, it is important that the core image and modules have matching versions. Usually, running grub-install is sufficient to ensure this. On the UEFI platform, grub-install allows the core image to be placed in two different locations: EFI/gentoo/grubx64.efi This is the location used by grub-install without options. EFI/BOOT/BOOTX64.EFI This is the location used by grub-install --removable. On upgrades, it is common for users to mismatch the grub-install options they used for the current and previous versions of grub. This will cause a stale core image to exist. For example: /boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) /boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) /boot/grub/x86_64-efi/*.mod (grub 2.12 modules) Booting this system using BOOTX64.EFI image would likely fail due to a symbol mismatch between the core image and modules. [1] Re-runing grub-install both with and without the --removable option should ensure a working GRUB installation. However, this will clobber any BOOTX64.EFI image provided by other loaders. If dual-booting using another boot loader, users must take care not to replace BOOTX64.EFI if it is not provided by GRUB. References: [1] https://bugs.gentoo.org/920708
Posted By: Mike Gilbert
installkernel new USE flag systemd-boot - 30/01/2024 00:00 GMT
/sbin/installkernel is a script called by the kernels 'make install' as well as by the distribution kernels post install phase. sys-kernel/installkernel provides two paths for installing the kernel: - the traditional installkernel, or - systemd's kernel-install In sys-kernel/installkernel versions lower then 20, systemd's kernel-install would default to the layout used for systemd-boot (layout=bls). To improve backwards compatibility with the traditional installkernel this is no longer the case in versions 20 and up. Instead the default layout setting when no other USE flags are enabled is a compatibility layout similar to the traditional installkernel (layout=compat). User Action Required (systemd-boot users) ==================== Users of systemd-boot should: - enable the "systemd-boot" USE flag when upgrading to >=sys-kernel/installkernel-20. See also: https://wiki.gentoo.org/wiki/Installkernel
Posted By: Andrew Ammerlaan
Merging of installkernel-gentoo and installkernel-systemd - 18/01/2024 00:00 GMT
/sbin/installkernel is a script called by the kernels 'make install' as well as by the distribution kernels post install phase. It was previously provided by sys-kernel/installkernel-gentoo or sys-kernel/installkernel-systemd. The functionalities of these two packages have now been merged into sys-kernel/installkernel. sys-kernel/installkernel now provides the systemd USE flag to switch between the traditional installkernel (formerly sys-kernel/installkernel-gentoo) and systemd's kernel-install (formerly sys-kernel/installkernel-systemd(-boot)). Additionally, the new sys-kernel/installkernel with the systemd flag enabled now provides a default install.conf configuration file which ensures that it will work out-of-the-box with no configuration (other then USE flag configuration) required for most setups. Details on configuration and customization can be found on the installkernel wiki page [1]. Below we provide the most important migration notes. User Action Required (GRUB users) ==================== Previously sys-kernel/installkernel-gentoo provided kernel installation automation for users of GRUB via USE=grub. The new sys-kernel/installkernel provides the same functionality, which now works with both the traditional installkernel and systemd's kernel-install. Users of GRUB should therefore: - check that the "grub" USE flag is enabled to ensure that systemd's kernel-install uses the correct layout that grub-mkconfig understands. Users of GRUB may wish to explicitly choose either the traditional installkernel or systemd's kernel-install, in which case they may do so via USE=-/+systemd. sys-kernel/installkernel is renamed from sys-kernel/installkernel-gentoo, therefore no user action is required to upgrade to the new package. User Action Required (systemd-boot users) ==================== Previously sys-kernel/installkernel-systemd provided kernel installation automation for users of systemd-boot. sys-kernel/installkernel provides the same functionality but only via systemd's kernel-install. Users of systemd-boot should therefore: - ensure that the "systemd" and "systemd-boot" USE flags are enabled when upgrading to >=sys-kernel/installkernel-14. Users who are using the distribution kernels (i.e. gentoo-kernel(-bin)) should enable the "dracut" USE flag on installkernel as well to pull in and enable the dracut initramfs generator. This is enforced by portage. Note that the automagic behaviour of the dracut kernel-install plugin is removed in sys-kernel/installkernel. Users who rely on the dracut plugin automatically generating an initramfs when installing the kernel must enable the "dracut" USE flag to retain this behaviour. The upgrade path is enforced by sys-kernel/installkernel-systemd-4, which is just a wrapper pulling in >=sys-kernel/installkernel-14 with the "systemd" flag enabled. sys-kernel/installkernel-systemd may be removed after installing >=sys-kernel/installkernel-14. emerge --noreplace sys-kernel/installkernel emerge --depclean sys-kernel/installkernel-systemd User Action Required (rEFInd users) ==================== Previously sys-kernel/installkernel-gentoo provided kernel installation automation for users of rEFInd. The new sys-kernel/installkernel provides the same functionality, which now works with both the traditional installkernel and systemd's kernel-install. Users of rEFInd should: - ensure that the "systemd-boot" and "grub" USE flags are NOT enabled when upgrading to >=sys-kernel/installkernel-20. Additionally, users of rEFInd may want to - enable the "refind" USE flag to install an icon file alongside the installed kernel image which rEFInd will pick up at runtime. Users of rEFInd may wish to explicitly choose either the traditional installkernel or systemd's kernel-install, in which case they may do so via USE=-/+systemd. sys-kernel/installkernel is renamed from sys-kernel/installkernel-gentoo, therefore no further user action is required to upgrade to the new package. User Action Required (users of other bootloaders and custom scripts) ==================== Users who have previously relied on custom installkernel or kernel-install plugins should either ensure that the same kernel installation method will be used after upgrading to >=sys-kernel/installkernel-14 (via USE=+/-systemd) or migrate these custom plugins (details are on the wiki [1]). Users of bootloaders other than GRUB, systemd-boot or refind may want to retain the traditional /boot layout. They may do so by: - ensuring that the "systemd-boot", "grub" and "refind" USE flags are disabled. Optional: Unified Kernel Images (all users) ==================== Users who wish to use Unified Kernel Images[2] (e.g. for EFI stub booting) may do so by - enabling the "ukify" and "uki" USE flags. Which will automatically install a bootable EFI executable to the EFI system partition. The UEFI firmware, as well as, Systemd-boot, GRUB and rEFInd are capable of loading Unified Kernel Images. For more details see the wiki page on Unified Kernel Images[2] [1] https://wiki.gentoo.org/wiki/Installkernel [2] https://wiki.gentoo.org/wiki/Unified_kernel_image
Posted By: Andrew Ammerlaan