Gentoo Packages

The default local database type in mail-mta/postfix has been hash for local files and btree for caches and both file types depend on sys-libs/db. However, BerkeleyDB has not been developed sufficiently in recent years and the licensing change in 2013 made using the latest versions of BerkeleyDB problematic. Consequently, we are stuck with using ancient versions of BerkeleyDB and there is a general tendency in the Linux ecosystem to sunset BerkeleyDB support.

Postfix made switching database types easier with its latest release. We will be changing the default database type in postfix for both local databases and caches to lmdb starting with mail-mta/postfix-3.11.0.

# Timeline:

• mail-mta/postfix-3.11.0: March 2026. Both lmdb and berkdb USE flags are on by default. BerkeleyDB is still supported but the default database and cache type changes to lmdb.

• mail-mta/postfix-3.12.0: Expected Q1 2027. BerkeleyDB support will be off by default. You will need to turn it on manually if still needed. mail-mta/postfix will continue supporting BerkeleyDB until it is sunsetted in Gentoo.

Changing the default database and cache types in postfix-3.11.0 requires migration for the entries in main.cf and master.cf that do not specify a database type.

It is almost always a good idea to specify database type in main.cf and master.cf and in your postmap commands. As you are always specifying the database type, the default database and cache type settings do not come into play.

Option 1: Accept the new defaults and migrate to lmdb. The default USE flags take effect and lmdb becomes the new default when >=mail-mta/postfix-3.11.0 is installed. All local database files without a specified type and, optionally, caches need to be migrated to lmdb.

If your configuration is simple or if you are familiar with Postfix configuration, a few "grep" commands will find all the problems, and a few edits will be easy to make.

Read https://www.postfix.org/NON_BERKELEYDB_README.html#manual for a complete walk through and the commands you can run to find instances of BerkeleyDB usage in your postfix configuration.

Option 2: If your configuration is too complex for the manual migration step above or if you are not familiar with the details of your postfix configuration, postfix provides enable-redirect[1] and enable-reindex[2] options. Read the documentation for the details and their caveats. They provide valuable help in migration, especially for an operating system that do not have BerkeleyDB support anymore - which is NOT the case for Gentoo. However, these options still help in complex configuration cases.

Option 3: Turning off lmdb USE flag is not recommended but is possible. The default stays the same as previous versions of postfix, namely hash for local files and btree for caches. No further action is necessary until BerkeleyDB support is sunsetted in Gentoo when you will have to do the above migration.

For more details, please read: https://www.postfix.org/NON_BERKELEYDB_README.html



[1] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-redirect [2] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-reindex

www-client/chromium is now available as a slotted package, allowing multiple versions to be installed simultaneously.

The new slots are:

• www-client/chromium:stable - the latest 'stable' channel release
• www-client/chromium:beta - the latest 'beta' channel release
• www-client/chromium:unstable - the latest 'dev' channel release

Upstream are inconsistent with `dev` channel naming, so we've gone with 'unstable' to match www-client/google-chrome* packaging.

The biggest change to end-users is that various Chromium versions will no longer share a single profile directory, instead each slot (channel) will have its own profile directory as e.g. the various www-client/google-chrome packages work now.

This change is particularly useful for developers who need to test their applications against different versions of Chromium, and protects against incompatible profile downgrades when switching between versions.

Users on stable should not expect to see any major change, however any Progressive Web Applications (PWAs) may need to be "reinstalled" after the upgrade to update the desktop files.

Users on ~arch may wish to select a specific slot to use, as due to the nature of Chromium releases, the latest ~arch version will switch between the stable and beta slots depending on where we are in the release cycle.

The same advice applies to users of the dev/unstable channel (unkeyworded) as well - they may end up unexpectedly upgraded to beta if the dev channel is delayed during a promotion.

Impacted users should explicitly select the appropriate slot(s) to use, e.g. by selecting www-client/chromium:stable or www-client/chromium:beta:

  emerge --deselect www-client/chromium
  emerge --noreplace www-client/chromium:stable

upstream is called bandwhich not bandwidth

sssd now runs as its own user, rather than root, and uses file capabiltites for its helpers. Although it had this functionalilty for a while, it wasn't completely usable until 2.10.

sssd-2.12.0 will be the first keyworded version in Gentoo with this change, made available shortly.

Because of the user change, the sssd database, logs, and configuration files must have their ownership changed.

== Systemd users == After upgrading sssd to >=2.10, stop the sssd service. Then execute the following commands:

chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd

Then restart the sssd service and verify it launched succesfully.

== openrc users ===

After upgrading sssd, stop the sssd service. Then execute the following commands:

chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd chown -R root:sssd /etc/sssd

Then restart the sssd service and verify it launched succesfully.

Reasons =======

Gentoo has had a longstanding complaint that desktop profiles do not enable a suitable working audio setting, which causes confusion for new users. An example of when this is a user can end up compiling Firefox without audio support, meaning the user will have to add the USE flags and then compile Firefox a second time. This not only wastes time for the user, but also increases support workload by the volunteers that provides it.

This change will make PipeWire the default sound server for all Gentoo desktop profiles which support it, rather than just KDE Plasma profiles as was the previous norm[1]. PipeWire has been widely adopted by Linux as a whole due to its feature to work with older standards such as PulseAudio, and means Gentoo will be less likely to need users to make any follow-up changes to their system, related to audio.

Changes =======

New global USE flags enabled: pulseaudio

  -> Enables PulseAudio support for packages as a fallback when native
  PipeWire isn't available.

New global USE flags enabled: pipewire New package.use default: media-video/pipewire[sound-server]

  -> These settings will enable PipeWire by default where available and
  also tell PipeWire to act as our PulseAudio server where there is no
  native PipeWire support.

New global USE flags enabled: screencast

  -> In Wayland sessions, the video functionality of PipeWire is not only
  used for screen sharing but also to take screenshots and recordings or
  simply to cast window content onto task managers' window previews.

  As this is basically a free and beneficial addition as it provides
  things like screenshotting and webcam access under Wayland.

Alpha and HPPA ===============

Alpha and HPPA currently do not have PipeWire support enabled so only PulseAudio is enabled.

These can be requested by users at a later date after confirming they work with the respected projects.

Users not wishing to change ===========================

For users not wanting to change from the their current desktop profile setup, then all that is required is to set

  USE="-pipewire -pulseaudio -screencast"

in their make.conf file.

User Action Required ====================

In order to enact all changes:

  emerge -avDU @world

Follow the post-installation messages printed by emerge to start the needed daemons.

If using systemd, to configure the PipeWire daemon(s), run the following commands:

  $ systemctl --user --now disable pulseaudio.service pulseaudio.socket
  $ systemctl --user --now disable pipewire-media-session.service
  $ systemctl --user --now enable pipewire.socket pipewire-pulse.socket
  $ systemctl --user --force enable wireplumber.service

OpenRC users don't need to take any action if using a desktop environment that supports XDG autostart.

Afterwards all that should be required is a reboot, however in the unlikely event of issues then check out how to configure PipeWire for your purposes. [1][2].

In order to keep a previously configured PulseAudio only system (i.e. keep using media-sound/pulseaudio-daemon), set

  USE="-pipewire -screencast" in /etc/portage/make.conf

and

  media-video/pipewire -sound-server in /etc/portage/package.use

For an ALSA only system, set

  USE="-pipewire -pulseaudio -screencast" in /etc/portage/make.conf

[1] https://www.gentoo.org/support/news-items/2022-07-29-pipewire-sound-server.html [2] https://wiki.gentoo.org/wiki/PipeWire

net-mail/dovecot-2.4.2 will be stabilized soon[1] and will be the first dovecot-2.4 release that will be stable in Gentoo.

Dovecot-2.3 configuration settings will not work with Dovecot-2.4 and manual intervention is required for the upgrade. Please read

https://doc.dovecot.org/2.4.2/installation/upgrade/overview.html

before upgrading your dovecot instance.

We strongly recommend finalizing your Dovecot 2.4 configuration on a test system before upgrading any production systems.

The following steps typically make the upgrade process easier:

1. Make a note of your current configuration by running doveconf -nP 2. Stop the dovecot daemon 3. Move ALL your configuration files to a temporary location 4. Upgrade to dovecot-2.4.2 5. Read the new configuration files and uncomment as necessary 6. Compare the new doveconf -n output with the old one and add missing configuration settings one by one while checking that the system works after each change

[1]: https://bugs.gentoo.org/967978