{"articles":[{"atomspec":["sec-policy\/selinux-base"],"authoremail":"nvraxn@posteo.uk","authorname":"Rahul Sandhu","body":["What Changed ============","The SELinux policy packages have all been bumped to EAPI 8.","POLICY_TYPES, which used to be an environment variable, is now a USE expand named SELINUX_POLICY_TYPES. The use of USE_EXPAND fixes some longstanding bugs and allows users to switch policy types more easily.","Whilst the POLICY_TYPES environment variable is considered deprecated going forward, it is still necessary to keep it set (and in sync with SELINUX_POLICY_TYPES) until you are certain that all installed policy packages on your system have been updated.","Please read on for further instructions.","For Users ========= Set SELINUX_POLICY_TYPES in your package.use to match what POLICY_TYPES is currently set to. To get the current value of POLICY_TYPES:","$ portageq envvar POLICY_TYPES","And to set SELINUX_POLICY_TYPES:","# echo 'SELINUX_POLICY_TYPES=\"mcs\"' >>\/etc\/portage\/make.conf","OR","# echo \"sec-policy\/* SELINUX_POLICY_TYPES: mcs\" >>\/etc\/portage\/package.use\/selinux-policy","Then, update the system to install the updated policy packages:","# emerge --verbose --ask --update --deep --newuse @world","DO NOT unset POLICY_TYPES until you are certain that all of the policy packages installed have been updated to use EAPI 8 (or above). You can use this command to find all outdated installed policy packages that have not been updated yet:","$ qgrep -eNJ 'EAPI=\"?7\"?' 'sec-policy\/*'","If the above command returns an empty list, then it is safe to remove the POLICY_TYPES variable.","For Overlay Maintainers ======================= In your SELinux policy packages, bump the EAPI variable to EAPI=8. If your packages have any form of dependency on another policy package, it is neccessary to constrain their USE flags with the new eclass variable SELINUX_POLICY_USEDEP. See selinux-policy-2.eclass(5) for more details."],"newsid":"2026-04-26-selinux-policy-eapi-8","posted":"2026-04-26","title":"SELinux Policy EAPI 8 Migration","urls":[]},{"atomspec":["dev-lang\/pypy:3.11","dev-lang\/python:3.11","dev-lang\/python:3.12","dev-lang\/python:3.13"],"authoremail":"mgorny@gentoo.org","authorname":"Michał Górny","body":["We are planning to switch the default Python target of Gentoo systems on 2026-06-01, from Python 3.13 to Python 3.14.  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.","Most users do not need to do anything and it is best to wait until the switch date, as packages are still being ported.","If you did change the values, prefer to have more control over when the switch occurs, 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_13     *\/* PYTHON_SINGLE_TARGET: -* python3_13","This will enforce Python 3.13 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.14 targets:","    *\/* PYTHON_TARGETS: -* python3_14     *\/* PYTHON_SINGLE_TARGET: -* python3_14","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.14 support to your system first, and only then remove Python 3.13.  However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer.","First, enable both Python 3.13 and Python 3.14, and then run the upgrade commands:","    *\/* PYTHON_TARGETS: -* python3_13 python3_14     *\/* PYTHON_SINGLE_TARGET: -* python3_13","Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:","    *\/* PYTHON_TARGETS: -* python3_13 python3_14     *\/* PYTHON_SINGLE_TARGET: -* python3_14","Finally, switch to the final version and upgrade:","    *\/* PYTHON_TARGETS: -* python3_14     *\/* PYTHON_SINGLE_TARGET: -* python3_14","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.15, and upgrade manually then.","Upgrade commands ================ The Python 3.13 cleanup requires that Python 3.13 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","Other Python implementations ============================ At the same time, we are also going to remove the target support for Python 3.11 (python3_11) and PyPy 3.11 (pypy3_11).  Since there are no plans to release a Python 3.12-compatible PyPy version yet, Gentoo will be removing PyPy support for the time being."],"newsid":"2026-04-16-python3-14","posted":"2026-04-16","title":"Python 3.14 to become the default on 2026-06-01","urls":[]},{"atomspec":["www-servers\/vinyl-cache"],"authoremail":"bacs@librecast.net","authorname":"Brett A C Sheffield","body":["# Varnish Renamed to Vinyl-Cache","As of version 9.0.0, www-servers\/varnish has been renamed to www-servers\/vinyl-cache in line with upstream's change of name[0][1][2][3]. The name change also affects binaries, directories, init scripts, configuration and the user and group used by the server daemon.","If you are upgrading from a previous version of www-servers\/varnish you will need to update your configuration as described in \"Upgrading\" below.","# Changes","All varnish* binaries have been renamed to their vinyl* equivalents:"," varnishd                  -> vinyld  varnishlog                -> vinyllog  varnishncsa               -> vinylncsa  varnishadm                -> vinyladm  varnishhist               -> vinylhist  varnishstat               -> vinylstat  varnishstat_help_gen      -> vinylstat_help_gen  varnishstatdiff           -> vinylstatdiff  varnishtest               -> vinyltest  varnishtop                -> vinyltop","This name change also affects all related conf.d\/* files, init scripts, systemd service files, logrotate etc.","The api library has been renamed:  libvarnishapi.so -> libvinylapi.so","In these conf.d files, all VARNISH* options are now VINYL* and you will need to update your configuration accordingly:"," \/etc\/conf.d\/varnishd      -> \/etc\/conf.d\/vinyld  \/etc\/conf.d\/varnishlog    -> \/etc\/conf.d\/vinyllog  \/etc\/conf.d\/varnishncsa   -> \/etc\/conf.d\/vinylncsa","The configuration directory has been moved:  \/etc\/varnish\/ -> \/etc\/vinyl-cache\/","Other varnish directories have also been renamed:"," \/usr\/include\/varnish      -> \/usr\/include\/vinyl-cache  \/usr\/lib\/varnish          -> \/usr\/lib\/vinyl-cache  \/usr\/lib64\/varnish        -> \/usr\/lib64\/vinyl-cache  \/usr\/share\/varnish        -> \/usr\/share\/vinyl-cache  \/var\/lib\/varnish          -> \/var\/lib\/vinyl-cache  \/var\/log\/varnish          -> \/var\/log\/vinyl-cache","# Upgrading","To upgrade from varnish 8.x to 9.x:","0) Take a backup of your existing configuration files 1) Stop all running varnish services 2) emerge --oneshot www-servers\/vinyl-cache 3) Update and install your VCL files in \/etc\/vinyl-cache\/","You can now start the new vinyld, vinyllog and vinylncsa services, remembering to add them to the appropriate runlevels as usual. Ditto systemd services.","For more details of the changes, you are encouraged to read the upstream announcement[0].","# Refs"],"newsid":"2026-03-31-varnish-renamed","posted":"2026-03-31","title":"Varnish Renamed","urls":["https:\/\/vinyl-cache.org\/docs\/9.0\/whats-new\/upgrading-9.0.html","https:\/\/vinyl-cache.org\/organization\/20-years.html","https:\/\/vinyl-cache.org\/organization\/new-identity.html","https:\/\/vinyl-cache.org\/organization\/on_vinyl_cache_and_varnish_cache.html"]},{"atomspec":["www-client\/chromium"],"authoremail":"kangie@gentoo.org","authorname":"Matt Jolly","body":["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"],"newsid":"2026-03-15-chromium-slotting","posted":"2026-03-15","title":"www-client\/chromium slotted installation","urls":[]},{"atomspec":["mail-mta\/postfix"],"authoremail":"eras@gentoo.org","authorname":"Eray Aslan","body":["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"],"newsid":"2026-03-15-postfix-database-change","posted":"2026-03-15","title":"mail-mta\/postfix-3.11.0: Default database change","urls":["https:\/\/www.postfix.org\/NON_BERKELEYDB_README.html#enable-redirect","https:\/\/www.postfix.org\/NON_BERKELEYDB_README.html#enable-reindex"]},{"atomspec":["sys-auth\/sssd"],"authoremail":"salah.coronya@gmail.com","authorname":"Christopher Byrne","body":["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\tsssd, 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."],"newsid":"2026-02-11-sssd-2_12-keywording","posted":"2026-02-11","title":"sssd to run as a dedicated user","urls":[]},{"atomspec":[],"authoremail":"immoloism@gmail.com","authorname":"Ian Jordan","body":["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"],"newsid":"2026-01-15-desktop-profile-pipewire","posted":"2026-01-15","title":"Desktop Profile to enable PipeWire support","urls":["https:\/\/www.gentoo.org\/support\/news-items\/2022-07-29-pipewire-sound-server.html","https:\/\/wiki.gentoo.org\/wiki\/PipeWire"]},{"atomspec":["net-mail\/dovecot"],"authoremail":"eras@gentoo.org","authorname":"Eray Aslan","body":["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"],"newsid":"2026-01-08-dovecot-2_4-stabilization","posted":"2026-01-08","title":"net-mail\/dovecot-2.4.2 stabilization","urls":[]},{"atomspec":["app-eselect\/eselect-blas","app-eselect\/eselect-cblas","app-eselect\/eselect-lapack","sci-libs\/blis","sci-libs\/flexiblas","sci-libs\/lapack","sci-libs\/mkl","sci-libs\/openblas","virtual\/blas","virtual\/cblas","virtual\/lapack","virtual\/lapacke"],"authoremail":"sam@gentoo.org","authorname":"Sam James","body":["Gentoo is adopting FlexiBLAS (sci-libs\/flexiblas) [0][1] as the primary way of switching BLAS implementations at runtime.","The previous eselect-based 'eselect-blas', 'eselect-cblas', and 'eselect-lapack' approach will be phased out in favor of this because of various reliability problems we hit.","The defaults in profiles will change shortly for stable users. For ~arch users, the default was changed a little while ago.","Action required ---------------","Please check your configuration for any stale references to eselect-ldso:","    $ grep -rsin eselect-ldso \/etc\/portage","and drop any reference to to it in make.conf USE or package.use.","Please also deselect the relevant packages from world:","    $ emerge --deselect app-eselect\/eselect-blas app-eselect\/eselect-cblas     $ emerge --deselect app-eselect\/eselect-lapack","Then complete a world upgrade and depclean:","    $ emerge -a -uvDU @world     $ emerge -ac","Using flexiblas ---------------","Most users do not need to worry about this and the defaults will be fine.","For users that want to, FlexiBLAS allows both system-wide and per-user configuration and supersedes the functionality from the old setup. Please refer to the flexiblas(1) man page for details."],"newsid":"2025-11-30-flexiblas-migration","posted":"2025-11-30","title":"FlexiBLAS migration imminent","urls":["https:\/\/public-inbox.gentoo.org\/gentoo-dev\/db65740b619e7b2413ac2b4b06f94db960f3e46e.camel@gentoo.org\/","https:\/\/bugs.gentoo.org\/963034"]},{"atomspec":["sys-apps\/portage"],"authoremail":"flow@gentoo.org","authorname":"Florian Schmaus","body":["Portage now implicitly enables OpenPGP verification of the \"raw\" ::gentoo repository when synchronizing using git [1]. That is, >= Portage 3.0.70 will set     sync-git-verify-commit-signature = true for the \"raw\" ::gentoo repository as default.","Note that if you have the 'rsync-verify' flag (misleading name) disabled for sys-apps\/portage, you will need to enable it, as it pulls in app-portage\/gemato which is used for verification for git repositories too. It is enabled by default.","This behavior change otherwise only requires action from users who are synchronizing the \"raw\" ::gentoo git repository, as otherwise synchronization may fail due to verification errors.","Users - synchronizing the \"sync friendly\" ::gentoo git repository, - using rsync as synchronization mechanism - or, using emerge-webrsync are *not* required to take any action.","Remotes of the \"sync friendly\" ::gentoo git repository include: - https:\/\/github.com\/gentoo-mirror\/gentoo - https:\/\/anongit.gentoo.org\/git\/repo\/sync\/gentoo.git - https:\/\/gitweb.gentoo.org\/repo\/sync\/gentoo.git","We recommend using those instead of the \"raw\" repo because the \"raw\" repo does not include news items, GLSAs, or generated metadata. No action is required when using one of these remotes listed above. For those other sync types\/repos, verification is already handled and they are unaffected by this change.","This news item is NOT instructing users to start using the raw repo, it is just a necessary change if you are already using it. Please do not start using the \"raw\" repo as a result of this news item. Stop reading if you aren't using it already!","However, advanced users who already use the \"raw\" ::gentoo remote repository need to adjust the repository configuration to verify against the \"gentoo developers\" keyfile.  Ensure that sec-keys\/openpgp-keys-gentoo-developers is installed, as it provides this keyfile.  Furthermore, the key refresh method should be set to 'keyserver' because WKD is not supported with the \"gentoo developers\" keyfile.","Remotes of this category include: - https:\/\/github.com\/gentoo\/gentoo - https:\/\/gitweb.gentoo.org\/repo\/gentoo.git\/","An typical adjusted configuration may look like the following:","[gentoo] location = \/var\/db\/repos\/gentoo sync-type = git # This is the raw git repository and it lacks news, GLSAs, and metadata. # We don't recommend using it unless you're an advanced user! # # If using this repository instead of the 'sync' repositories, please make # sure to generate news and friends yourself. sync-uri = https:\/\/github.com\/gentoo\/gentoo.git sync-openpgp-key-path = \/usr\/share\/openpgp-keys\/gentoo-developers.asc # If you experience hangs or refresh failures, try 'no' instead. sync-openpgp-key-refresh = keyserver","1: https:\/\/bugs.gentoo.org\/959831"],"newsid":"2025-11-01-portage-git-sync-verify","posted":"2025-11-01","title":"Portage to verify git-synced ::gentoo per default","urls":[]}]}