Gentoo Repository News
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
Separate /usr now requires an initramfs - 05/01/2024 00:00 GMT
Systems which have /usr and / on separate filesystems have always required a dedicated initramfs to bring up both partitions. Systems where both /usr and / are on the same filesystem may use an initramfs if they wish, or choose not to. Historically, Gentoo has tried to make the separate filesystems use case work anyway. Despite all our efforts, it is broken and continues to get more broken under various configurations. The only workable solution is to support separate /usr but only when an initramfs is present. For more details on why this is broken, see: - https://bugs.gentoo.org/868306#c10 - https://bugs.gentoo.org/902829 - http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken - https://bugs.gentoo.org/915379 - https://github.com/trofi/nix-guix-gentoo/commit/43d84cc00af530ef912d9c98448b64d6b5282907 - https://github.com/trofi/nix-guix-gentoo/commit/8f194519982fbfabb6b3ca84c0806b1a379b5d06 - https://bugs.gentoo.org/825078 In 2013, Gentoo policy determined that separate /usr without an initramfs was officially no longer supported: - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 - https://gitweb.gentoo.org/data/gentoo-news.git/tree/2013/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt?id=a79dd69b0cca439bc0c483c9193c79e0554819d0 11 years later, the support is being withdrawn. On 2024-02-05, we plan to begin work on decommissioning existing workarounds and will not accept any more. User Action Required ==================== If you have separate /usr and are not currently using an initramfs, you have until 2024-02-05 to set up an initramfs. If you do not, then at some point on or after this date, routine system upgrades will leave your system unbootable. For details on setting up an initramfs, see: https://wiki.gentoo.org/wiki/Initramfs/Guide
Posted By: Eli Schwartz
LXD to lose access for its image server - 28/12/2023 00:00 GMT
Earlier this year Canonical took their LXD project away from the community-run LinuxContainers and brought it under their own administration. While doing so, they removed management access from non-Canonical employees, along with other things. This caused LXD to be forked and so Incus was born. Incus would pull updates from upstream LXD to stay compatible. Recently LXD was re-licensed so Incus can't benefit from its code anymore. Therefore Incus will become a truly independent project. However it is LinuxContainers community that still hosts most LXD images for free, for Incus and LXD. With them unable to benefit or use LXD anymore, LinuxContainers have decided to stop building and hosting LXD images. Realistically they can't support LXD given these restrictions. They will start limiting access immediately in 2024 for non-LTS users which is LXD >=5.18, or "unstable" in Gentoo. LTS LXD, or "stable" (5.0) in Gentoo will be allowed to pull images until May (an estimate), or until Incus LTS will be released. Times are subject to change. What can you do? ================ 1: Switch to Incus. 2: Deploy your own image server. 3: Wait and see what Canonical does. For unstable users the matter is rather critical, while stable users have the luxury of waiting. Note that a downgrade from unstable to stable is not possible due to database schemas. Please follow or take a look at Gentoo bug #920527 with more information about this situation, and updates e.g. for timetables. Bug: https://bugs.gentoo.org/920527
Posted By: Joonas Niilola
CUPS no longer directly depends on its filters - 20/11/2023 00:00 GMT
Reasons
=======
Historically, net-print/cups has both depended on and been a dependency of
net-print/cups-filters. The latter is required for usability of a CUPS
printing setup, but also must build against the former's libraries. This
results in an ugly dependency cycle, and forcing the entire CUPS printing
setup wherever USE=cups is enabled on a framework.
Current upstream work on CUPS has focused on modularizing the codebase. There
are now several packages, and there will be more in the future. Installing
net-print/cups-filters is no longer sufficient to ensure all components are
installed.
In the future, when CUPS v3 is released, filters will be exclusive to legacy
printers, and largely replaced with IPP Everywhere.[1]
A more future-proof way to install a CUPS production printing setup is needed.
User Action Required
=======
cups-filters is required for current versions of CUPS. To prevent depcleaning
if you are a CUPS user (and it was not installed just as a dependency for
something else):
emerge net-print/cups-meta
If cups-browsed support is desired, add the following package.use:
net-print/cups-meta browsed
[1] https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning
Posted By: Eli Schwartz
Plasma Profile to enable PipeWire, Wayland support - 21/05/2023 00:00 GMT
Reasons
=======
Gentoo's Plasma profile has not had any sound server enabled since the days of
KDE's own aRts. As the way we output sound has changed dramatically in the years
since - using wireless or often several devices, dynamically connected and
shared between multiple systems, a modern desktop environment is expected to
handle this effortlessly by default.
In Wayland sessions, the video functionality of PipeWire is not only used for
screensharing but also to take screenshots and -recordings or simply to cast
window content onto task managers' window previews. This is why PipeWire and
Wayland enablement are happening at the same time.
Plasma Wayland support has come a long way and we consider it stable enough for
daily use with a lot - if not all - systems, even if some known papercuts
remain [1]. Therefore it makes sense for Plasma profile to provide sane default
settings.
Changes
=======
New global USE flags enabled: pipewire, pulseaudio, screencast, wayland
New package.use default: media-video/pipewire[sound-server]
We want broad sound server support in packages, and these settings will make
PipeWire act as our PulseAudio server where there is no native PipeWire support.
Impact On Happy X Users
=======================
Minor. Most dependencies were already required with kde-plasma/plasma-desktop
and its dependencies. Upcoming stable versions of kde-apps/spectacle and
kde-apps/krfb will depend on (K)PipeWire unconditionally.
No one will lose their X session, but will have the option to easily log in to
a working Wayland session at any time.
It is possible to set USE="-wayland" against these changes, but it will amount
to no dependency savings, just micro-optimisation in affected packages.
User Action Required
====================
In order to enact all changes:
emerge -1avUD @world
Check out how to configure PipeWire for your purpose [2][3]
In order to keep a PulseAudio or ALSA-only setup:
Invert above new USE flag settings as needed, see also [2].
In order to avoid media-video/pipewire completely:
This can only be achieved by losing basic task manager, screenshot/screen
recording/sharing functions as provided by Plasma and KDE applications.
[1] https://community.kde.org/Plasma/Wayland_Showstoppers
[2] https://www.gentoo.org/support/news-items/2022-07-29-pipewire-sound-server.
html
[3] https://wiki.gentoo.org/wiki/PipeWire
Posted By: Andreas Sturmlechner
OpenSSH directory configuration changes - 11/05/2023 00:00 GMT
Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d and /etc/ssh/ssh_config.d directories for both Gentoo default settings and use by the administrator. The default /etc/ssh/sshd_config and /etc/ssh/ssh_config files will respectively include configuration files in /etc/ssh/sshd_config.d/* and /etc/ssh/ssh_config.d/*, making it possible for all customization and configuration to be done via 'drop-in' files if desired. Most users will not need to take any action. The only action required is if specific Gentoo defaults were overridden in the past, as the new ebuilds will install them to new files in the new listed directories. Such admins will need to edit the new files in the new directories or make overrides in their own files in the new directories using a smaller number in the filename. For example, if the system administrator has commented out 'AcceptEnv COLORTERM' in /etc/ssh/sshd_config, they will need to do the same in the new /etc/ssh/sshd_config.d/9999999gentoo.conf file.
Posted By: Sam James