gpo.zugaina.org

Search Portage & Overlays:
RSS

Gentoo Repository News

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

Migration to GLEP-81 enabled webservers - 20/05/2022 00:00 GMT

In future, in order to complete the whole GLEP-81 migration,
the packages www-servers/apache and www-servers/nginx
will be migrated to GLEP-81.

If changes have been made to the default user and group created
by one of the both packages, the configuration needs to be updated,
as otherwise it will be overwritten.

The following configuration settings can be set
in make.conf or per package in package.env:

1. ACCT_USER__GROUPS
   for overriding all default groups.

2. ACCT_USER__GROUPS_ADD
   for adding additional groups to default groups.

3. ACCT_USER__HOME
   for overriding default home directory.

4. ACCT_USER__HOME_OWNER
   for overriding default owner of home directory.

5. ACCT_USER__HOME_PERMS
   for overriding default permissions of home directory.

6. ACCT_USER__SHELL
   for overriding default assigned shell.

If being set per package in package.env, it needs to
be set for acct-user/apache or acct-user/nginx,
depending on which user should be modified.

See [1] for more details on those variables.

** Package acct-user/apache will use username/group 'apache'.
-> ACCT_USER_APACHE_GROUPS=".."
-> ACCT_USER_APACHE_GROUPS_ADD=".."
-> ACCT_USER_APACHE_HOME=".."
-> ACCT_USER_APACHE_HOME_OWNER=".."
-> ACCT_USER_APACHE_HOME_PERMS=".."
-> ACCT_USER_APACHE_SHELL=".."

** Package acct-user/nginx will use username/group 'nginx'.
-> ACCT_USER_NGINX_GROUPS=".."
-> ACCT_USER_NGINX_GROUPS_ADD=".."
-> ACCT_USER_NGINX_HOME=".."
-> ACCT_USER_NGINX_HOME_OWNER=".."
-> ACCT_USER_NGINX_HOME_PERMS=".."
-> ACCT_USER_NGINX_SHELL=".."

Please update configuration parameters before emerging
both GLEP-81 enabled ebuilds, as otherwise configuration
will be overwritten to default.

Migration to GLEP-81 will start after 2022-07-01.

[1] https://devmanual.gentoo.org/eclass-reference/acct-user.eclass/index.html


Posted By: Conrad Kostecki

Migration to sys-apps/systemd-utils - 19/04/2022 00:00 GMT

The sys-apps/systemd-utils package was recently added to the gentoo
repository. This replaces sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, and sys-fs/udev with a single package, and is
for OpenRC users. It does not depend on sys-apps/systemd and contains
the same exact components as the split packages.

USE flags are provided to allow each component to be enabled
or disabled. This change was made to significantly ease maintenance of tools
split out from systemd.

When upgrading to sys-apps/systemd-tmpfiles-250,
sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.

When upgrading to sys-boot/systemd-boot-250,
sys-apps/systemd-utils[boot] will be pulled in as a dependency.

When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be
pulled in as a dependency.

At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
sys-fs/udev will be masked for removal once a suitable version of
sys-apps/systemd-utils has been marked stable and sufficient time has
been provided for users to migrate.

Possible problems when upgrading:

1. If sys-fs/eudev is present in the world file (@selected), emerge will
   abort the upgrade with a unsolvable blocker error. To resolve this,
   either remove sys-fs/eudev from the world file
   (emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for
   sys-apps/systemd-utils.

2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default.
   Users migrating from sys-boot/systemd-boot will need to enable the
   'boot' USE flag (in package.use) to continue receiving updates.

3. If you have package.use entries for any of sys-apps/systemd-tmpfiles,
   sys-boot/systemd-boot, or sys-fs/udev, please update the relevant lines
   to refer to sys-apps/systemd-utils instead. This might include
   ABI_X86_32 for some users!


Posted By: Mike Gilbert

sys-apps/systemd-utils update needed - 17/04/2022 00:00 GMT

The currently installed version of sys-apps/systemd-utils may cause
kernel modules to fail to load on boot.

Please upgrade to >=sys-apps/systemd-utils-250.4-r1 as soon as possible,
and certainly before rebooting your system.


Posted By: Mike Gilbert

Sandbox issue with ccache 4.6 - 12/04/2022 00:00 GMT

Users with ccache enabled for the dev-util/ccache package itself may need
to temporarily disable ccache in order to upgrade the package.

Users on an earlier version of ccache (<4.6) or newer (>=4.6-r1) are
unaffected.

For a small window (between 2022-04-09-4:30AM UTC and 2022-04-09-11:27AM UTC),
the ccache ebuild may have caused a sandbox violation [0] in some circumstances.

To resolve this issue, temporarily re-emerge dev-util/ccache with ccache
disabled:
# FEATURES="-ccache" emerge -v1 ">dev-util/ccache-4.6"

The sandbox violations occur when trying to use ccache for any package;
users who do not have ccache enabled globally (or at least not for ccache
itself) should also proactively upgrade ccache as above.

[0] https://bugs.gentoo.org/837362


Posted By: Sam James

Qt 5.15.3 version bump with binary path changes - 30/03/2022 00:00 GMT

Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt
binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 [1] such
links will be installed by each respective Qt package and '5'-version-suffixed,
e.g. qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6.

If you develop with Qt5 and rely on unversioned binaries for your workflow,
dev-qt/qtchooser as a tool for quickly switching between multiple Qt
installations (e.g. Qt3, Qt4 and Qt5) can still be manually installed. The
'default' Qt version in PATH is then controlled via config in
/etc/xdg/qtchooser.

Otherwise, dev-qt/qtchooser will be slated for cleanup on your next
emerge --depclean run.

[1] https://archives.gentoo.org/gentoo-dev/message/
5f3681b5b28dabeb5339d44e9585d29f


Posted By: Andreas Sturmlechner

Transition from sys-cluster/singularity to app-containers/apptainer - 05/03/2022 00:00 GMT

In autumn 2021 the Singularity project joined the Linux Foundation
and changed its name to Apptainer [1]. The change has been reflected
in the renaming of files and environment variables, as well as a reset
of version numbers back to 1.0.0.

Apptainer packages include compatibility symlinks to old Singularity
executables, provide bash-completion rules for both the old and the new
name, continue to honour old environment variables, and will upon
the first run import user data from Singularity directories. Therefore,
for most users it will be sufficient to deselect the old package and
install the new one, e.g.:

emerge --deselect sys-cluster/singularity
emerge app-containers/apptainer

However, customisations made to system-wide configuration
in /etc/singularity will have to be applied to /etc/apptainer by hand.

[1] https://apptainer.org/news/community-announcement-20211130/


Posted By: Marek Szuba