gpo.zugaina.org

Search Portage & Overlays:
RSS

Gentoo Repository News

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

Python 3.11 to become the default on 2023-05-01 - 02/04/2023 00:00 GMT

We are planning to switch the default Python target of Gentoo systems
on 2023-05-01, from Python 3.10 to Python 3.11.  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).

At the same time, the support for Python 3.9 target will be removed
from the eclasses.  The interpreter package will remain supported
for as long as feasible though.  PyPy3.9 will remain supported until
PyPy3.10 comes out and becomes stable.


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_10
    */* PYTHON_SINGLE_TARGET: -* python3_10

This will enforce Python 3.10 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.11 targets:

    */* PYTHON_TARGETS: -* python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

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.11 support to your system first,
and only then remove Python 3.10.  However, note that this involves two
rebuilds of all the affected packages, so it will take noticeably
longer.

First, enable both Python 3.10 and Python 3.11, and then run the upgrade
commands:

    */* PYTHON_TARGETS: -* python3_10 python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_10

Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:

    */* PYTHON_TARGETS: -* python3_10 python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

Finally, switch to the final version and upgrade:

    */* PYTHON_TARGETS: -* python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

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.12, and upgrade manually then.


Upgrade commands
================
The Python 3.10 cleanup requires that Python 3.10 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 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