Gentoo Repository News
Breaking changes to the RAP Prefix toolchain - 28/01/2023 00:00 GMT
We are changing the way the toolchain operates on RAP Prefix systems in order to
reduce the number of hacks we need to apply and make cross-compiling easier.
If you using a non-RAP "Prefix Guest" or "Prefix Stack" variant (e.g. macOS)
then this does not apply.
If you're not sure what kind of prefix you have, then check whether the
prefix-guest USE flag is enabled. If the following command returns nothing, then
you have a RAP prefix and this does apply.
portageq envvar USE | grep prefix-guest
If you are using a libc other than glibc (e.g. musl) then this *does* apply, but
your libc will *not* break, so you should not carry out the following procedure.
The only other package known to be affected is dev-libs/libbsd, which you can
simply update. If you find another package affected by this, then please file a
bug report.
WARNING! It is important that you carry out the following procedure, otherwise
your toolchain will break when you next update your compiler or glibc.
1. Run the following to create a temporary symlink:
EPREFIX=$(portageq envvar EPREFIX)
mkdir -p "$$"
ln -sn "$" "$$"
2. Update or rebuild all installed slots of sys-devel/gcc and sys-devel/clang
(if any). Feel free to remove any you no longer need.
3. Update or rebuild sys-libs/glibc.
4. Update sys-devel/binutils to at least 2.40-r2. This package is slotted, so
ensure at least this version is selected with binutils-config.
5. Run the following to remove the symlink:
EPREFIX=$(portageq envvar EPREFIX)
rm "$$"
6. If dev-libs/libbsd is installed, then update it to 0.11.7-r2 or later.
If you are reading this having updated glibc first and you are no longer able to
build anything, then don't panic. Simply execute the lines below and then carry
out the regular procedure above.
EPREFIX=$(portageq envvar EPREFIX)
portageq contents "$" $(portageq best_version "$" sys-libs/glibc) | xargs grep -lIF -d skip "GNU ld script" | xargs sed -i -r "s: /(usr|lib): $/\1:g"
Posted By: James Le Cuirot
Hardened profiles improvements - 01/01/2023 00:00 GMT
Gentoo's hardened profiles are adopting two new modern toolchain hardening techniques: 1. Level 3 fortification (-D_FORTIFY_SOURCE=3) [0] 2. libstdc++ assertions (-D_GLIBCXX_ASSERTIONS) [1] These will both be enabled by default with USE=hardened on sys-devel/gcc for >=sys-devel/gcc-12.2.1_p20221231. To view the existing list of hardening changes applied by the profiles, see the wiki [2]. Stable users may wish to add sys-devel/gcc-12.2.1_p20221231 into /etc/portage/package.accept_keywords if they wish to take advantage of these improvements early, before GCC 12 is marked stable. ## Migration To fully take advantage of these new settings, GCC must first be upgraded, and then all packages must be re-emerged: 1. # emerge --sync 2. # emerge --verbose --oneshot ">=sys-devel/gcc-12.2.1_p20221231" 3. # gcc-config latest 4. # emerge --verbose --emptytree @world ## Troubleshooting In the event that some packages fail at runtime, please file a bug with the full details. To temporarily workaround the problem, it should be possible to recompile broken packages with the following *FLAGS: CFLAGS="$ -D_FORTIFY_SOURCE=2" CXXFLAGS="$ -D_FORTIFY_SOURCE=2 -U_GLIBCXX_ASSERTIONS" [0] https://bugs.gentoo.org/876893 [1] https://bugs.gentoo.org/876895 [2] https://wiki.gentoo.org/wiki/Hardened/Toolchain#Changes
Posted By: Sam James
Introduction of app-alternatives ebuilds - 27/12/2022 00:00 GMT
Gentoo is introducing a new category of ebuilds called 'app-alternatives' to handle cases where a symlink for a common binary may want to be switched between different packages by a user. Traditionally, eselect was used for this, and while eselect still has its place, it's unsuitable for cases like /bin/awk and /bin/sh because it prevents immutable system directories and (more importantly from a package management perspective) relies on orphaned symlinks which means no package owns /bin/awk, /bin/sh, etc. This is not reliable and can lead to dead symlinks (or no symlink at all) in some edge cases [0]. Systems will be more robust and desired system configuration can be achieved using the package manager rather than manual steps outside of it. The initial list of packages which support alternatives is as follows: - app-alternatives/awk - app-alternatives/bzip2 - app-alternatives/bc - app-alternatives/cpio - app-alternatives/gzip - app-alternatives/lex - app-alternatives/sh - app-alternatives/tar - app-alternatives/yacc The stabilization of these new ebuilds and packages depending on them occurred on 2022-12-27 in bug 886017 [1]. ## Pre-upgrade requirements The default configuration on Gentoo systems is FEATURES="protect-owned" which works similarly to FEATURES="collision-protect" but it allows collisions between orphaned files. In this case, a one-off collision occurs as the app-alternatives/ ebuilds begin to claim once-orphaned symlinks. A similar issue occurred during the libxcrypt migration where users had upgrades interrupted by using the older, more aggressive FEATURES="collision-protect". It is recommended that users alter their configuration to remove references to 'collision-protect' in FEATURES and instead either explicitly enable 'protect-owned' in FEATURES or rely on the default (equivalent). It is also acceptable to simply disable collision-protect temporarily for the purposes of this news item. WARNING: Users with collision-protect enabled must disable FEATURES="collision-protect" in /etc/portage/make.conf by removing it or setting FEATURES="-collision-protect" if they have enabled it. collision-protect detects collisions between files including orphaned files where no package owns the file. ## Migrating When receiving this news item, please follow the step below as soon as possible to ensure a smooth transition. To migrate your system, a standard world upgrade will suffice after deselecting eselect-awk and eselect-sh: 1. # emerge --deselect app-eselect/eselect-awk app-eselect/eselect-sh 2. # emerge --depclean app-eselect/eselect-awk app-eselect/eselect-sh 3. # emerge --sync 4. # emerge -a -uvDU @world (or other similar standard world upgrade command) 5. # emerge --ask --depclean It's okay if nothing happens in Step 1 and Step 2 (no atoms to remove). ## Configuration Users who are not interested in using different implementations for various tools listed above can ignore this section. No configuration should be required by default, but users may wish to configure the new app-alternatives/ ebuilds to their tastes as they used to do via e.g. eselect-sh and eselect-awk. Going forward, /etc/portage/package.use will be used for this purpose. Users should review the USE flags available for the various app-alternatives ebuilds like app-alternatives/sh and adjust their configuration as desired. For example, to have /bin/gzip be provided by app-arch/pigz for automatic parallelization of 'gzip', one would have the following in /etc/portage/package.use: ``` # https://wiki.gentoo.org/wiki/Gzip#Parallelization # Make /bin/gzip be a symlink to pigz for a speedup in compression app-alternatives/gzip -reference pigz ``` ## Further reading For more details, please see the technical documentation on the wiki [2]. [0] https://wiki.gentoo.org/wiki/Project:Base/Alternatives#Why.3F [1] https://bugs.gentoo.org/886017 [2] https://wiki.gentoo.org/wiki/Project:Base/Alternatives
Posted By: Sam James
/usr merge for systemd users - 01/12/2022 00:00 GMT
In the latter half of 2023, systemd will drop support for
split-usr/unmerged-usr systems [1]. All Gentoo systems running systemd
will need to be migrated to merged-usr.
Migrating to merged-usr will move all data from /bin, /sbin, and /lib
into the /usr/bin and /usr/lib directories. The directories in / are
replaced with symlinks.
To facilitate this, a new set of sub-profiles has been created, and a
script is available to perform the actual migration.
To migrate a system to merged-usr, follow this procedure:
1. Ensure your system backups are up to date. Please also update
your system fully and depclean before proceeding.
2. Install sys-apps/merge-usr.
3. Run "merge-usr --dryrun" as root to check for conflicts. These will
appear with the word ERROR at the start of the line.
4. Resolve any conflicts. This may involve deleting duplicate files. If
in doubt, seek support in a Gentoo support channel.
5. Run the merge-usr script from a root shell. Avoid running it via sudo
directly to avoid locking yourself out if an unexpected error occurs.
6. Switch to a merged-usr profile.
eg. eselect profile set default/linux/amd64/17.1/systemd/merged-usr
7. Run emerge with the --newuse or --changed-use option to rebuild
any packages that have a "split-usr" USE flag.
eg. emerge -uDN @world
For new installs, new "mergedusr" stage3 tarballs are being produced for
commonly used profiles.
[1] https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html
Posted By: Mike Gilbert
systemd-tmpfiles --clean enabled by default - 21/11/2022 00:00 GMT
Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in /etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This will remove stale temp files based on settings specified in tmpfiles.d. This change is meant to mimic the behavior of systemd-tmpfiles-clean.timer from systemd on systems running OpenRC. If you wish to opt-out, simply comment out the command in /etc/cron.daily/systemd-tmpfiles-clean.
Posted By: Mike Gilbert
LVM2 default USE flag change - 19/11/2022 00:00 GMT
The Gentoo Base System team has recently switched from the disabling "device-mapper-only" flag to the enabling "lvm" (bug #718910). After considering most reverse dependencies of sys-fs/lvm2, the Base System Team has decided that the majority of Gentoo users are unlikely to use the LVM2 components of sys-fs/lvm2, instead relying solely on it providing device-mapper functionality. To this end, we will disable the default enabled flag "+lvm" on sys-fs/lvm2 on 2023-01-01. If you do not have USE=lvm somehow globally enabled, this means you will lose LVM2 (but not device-mapper!) functionality, so enable it in your config if your boot configuration depends on it or if you depend on any of the lvm2-* daemons. If you use LVM2 for any partitions, or if you use tools like 'lvchange', you should enable USE=lvm. Furthermore, we have considered other default enabled USE flags too, and have come to the conclusion that USE=+thin makes even less sense than USE=+lvm. Thin-provisioned LVM volumes are an important use case in certain VM hosting scenarios, but unlikely to be relevant for the large majority of Gentoo users. In summary: - Enable USE="lvm" if you use lvm2 (but not needed for device-mapper) as described above. This includes using LVM for any partitions. - Enable USE="lvm thin" if you use thin as described above. - If you don't know what LVM2 is, you don't need to take any action.
Posted By: David Seifert
PipeWire sound server migration - 29/07/2022 00:00 GMT
PipeWire has gained a new USE flag "sound-server" for enabling/disabling its sound server capabilities. This change is needed to avoid PipeWire and PulseAudio conflicting over control of audio devices. Before this change, OpenRC users were in some cases accidentally migrated to PipeWire which was difficult to override without manually editing launcher files. For non-audio purposes, PipeWire is installed in many configurations as more and more software depends on it for e.g. screensharing, sandboxing, and window previews, so users will need to act based on their preferred setup rather than simply avoiding installing PipeWire, as it is increasingly required as a dependency. Packages needing PulseAudio's APIs will be migrated from the now-meta package media-sound/pulseaudio to depending on media-libs/libpulse. The runtime PulseAudio server can be provided by either PipeWire (media-video/pipewire) or the original PulseAudio (media-sound/pulseaudio-daemon). The new sound-server USE flag for PipeWire allows easily controlling this behavior. There are several options available: 1. To use PipeWire for sound, users should enable USE=sound-server for PipeWire: Place the following entries in /etc/portage/package.use: ``` media-video/pipewire sound-server media-sound/pulseaudio -daemon ``` First, sync: # emerge --sync Deselect media-sound/pulseaudio-daemon: # emerge --deselect media-sound/pulseaudio-daemon Then perform a world upgrade with PipeWire on the command line to add it to the world file: # emerge --ask --update --changed-use --deep @world media-video/pipewire Then depclean: # emerge --ask --depclean OpenRC users on an XDG-compliant desktop which respects autostart files will not need to take any further action. OpenRC users using a minimal desktop which does not respect autostart files will need to run `gentoo-pipewire-launcher &` in e.g. `~/.xprofile`. Users who want to switch to PipeWire providing a PulseAudio daemon may need to `emerge --deselect` packages in their world file which hard-require media-sound/pulseaudio-daemon. There are only a handful of these. A non-exhaustive list: * media-sound/paprefs * media-sound/pasystray * media-sound/pulseaudio-modules-bt (shouldn't be needed anyway) * net-misc/pulseaudio-dlna If not using any of those packages anymore, please emerge --deselect them. If still using these, PipeWire as a PulseAudio is not an option at this time. (Note that media-libs/libpulse (which PipeWire will be using, don't emerge libpulse manually) provides 'pactl' which can be used as a replacement for e.g. media-sound/pulseaudio-ctl, so personal scripts can be adapted to this if desired.) systemd users will also need to run the following commands: $ systemctl --user --now disable pulseaudio.service pulseaudio.socket $ systemctl --user --now enable pipewire.socket pipewire-pulse.socket $ systemctl --user --now disable pipewire-media-session.service $ systemctl --user --force enable wireplumber.service Root user may replace --user with --global to change system default configuration for all of the above commands. 2. To use PulseAudio's daemon for sound, users should disable USE=sound-server for PipeWire, enable USE=daemon on media-sound/pulseaudio, and add media-sound/pulseaudio-daemon to their world file: Place the following entries in /etc/portage/package.use: ``` media-video/pipewire -sound-server media-sound/pulseaudio daemon ``` Add media-sound/pulseaudio-daemon to @world: # emerge --noreplace media-sound/pulseaudio-daemon Then perform a world upgrade: # emerge --ask --update --changed-use --deep @world Then depclean: # emerge --ask --depclean OpenRC users on an XDG-compliant desktop which respects autostart files will not need to take any further action. OpenRC users using a minimal desktop which does not respect autostart files should consider adding `gentoo-pipewire-launcher &` in e.g. `~/.xprofile` but it's not strictly required in terms of audio handling. It may be required in future for the non-audio usecases described above. systemd users will also need to run the following commands: $ systemctl --user --now enable pulseaudio.service pulseaudio.socket $ systemctl --user --now disable pipewire.socket pipewire-pulse.socket Alternatively, systemd users can run the following commands as root to change the default for all users: # systemctl --global enable pulseaudio.service pulseaudio.socket # systemctl --global --force disable pipewire.socket pipewire-pulse.socket (If taking this option, the services must be started manually as a one-off as a user.) 3. For users without sound on their system, those using JACK without PipeWire, or those using pure ALSA without PipeWire, the following steps are recommended: Place the following entries in /etc/portage/package.use: ``` media-video/pipewire -sound-server media-sound/pulseaudio -daemon ``` Then perform a world upgrade: # emerge --ask --update --changed-use --deep @world Then depclean: # emerge --ask --depclean OpenRC users on an XDG-compliant desktop which respects autostart files will not need to take any further action. OpenRC users using a minimal desktop which does not respect autostart files will need to run `gentoo-pipewire-launcher &` in e.g. `~/.xprofile`. systemd users will also likely want to run the following commands as a user, again for the purposes of non-audio PipeWire use: $ systemctl --user --now enable pipewire.socket $ systemctl --user --now --force enable wireplumber.service Alternatively, systemd users can run the following commands as root to change the default for all users, again for the purposes of non-audio PipeWire use: # systemctl --global enable pipewire.socket # systemctl --global --force enable wireplumber.service (If taking this option, the services must be started manually as a one-off as a user.) Further resources: * https://wiki.gentoo.org/wiki/PipeWire
Posted By: Sam James
Mu 1.7.23 Causing Maildir Corruption - 26/06/2022 00:00 GMT
Development versions of mu between 1.7.18 and 1.7.25 (only 1.7.23 was ever
packaged in Gentoo) have a bug causing mail file names to sometimes get mangled
after moving messages between directories. Symptoms include unread messages
never being marked as read.
Affected messages have the ':2,' flag appended multiple times. Using the
following commands, users can remove the extra flags.
find ~/Maildir -name '*:2,*:*' |
sed "s/\(\([^:]*\)\(:2,\)\\(:2,.*$\)\)/mv '\0' '\2\4'/" \
> rename.sh
# review rename.sh. empty file indicates that you are unaffected
sh rename.sh
Upstream issue: https://github.com/djcb/mu/issues/2268
Posted By: Matthew Smith
Python 3.10 to become the default on 2022-07-01 - 13/06/2022 00:00 GMT
We are planning to switch the default Python target of Gentoo systems
on 2022-07-01, from Python 3.9 to Python 3.10. 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_9
*/* PYTHON_SINGLE_TARGET: -* python3_9
This will enforce Python 3.9 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.10 targets:
*/* PYTHON_TARGETS: -* python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10
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.10 support to your system first,
and only then remove Python 3.9. However, note that this involves two
rebuilds of all the affected packages, so it will take noticeably
longer.
First, enable both Python 3.9 and Python 3.10, and then run the upgrade
commands:
*/* PYTHON_TARGETS: -* python3_9 python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_9
Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:
*/* PYTHON_TARGETS: -* python3_9 python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10
Finally, switch to the final version and upgrade:
*/* PYTHON_TARGETS: -* python3_10
*/* PYTHON_SINGLE_TARGET: -* python3_10
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.11, and upgrade manually then.
Upgrade commands
================
The Python 3.9 cleanup requires that Python 3.9 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
Breaking configuration changes in borgmatic-1.6.0 - 23/05/2022 00:00 GMT
Version 1.6.0 of app-backup/borgmatic has introduced some breaking changes to the way Borgmatic handles the merging of its configuration files and executes command hooks. If you use these features, please review your Borgmatic config files to make sure they continue to work correctly with >=app-backup/borgmatic-1.6.0. For details, see [1]. [1] https://github.com/borgmatic-collective/borgmatic/releases/tag/1.6.0
Posted By: Marek Szuba