Gentoo Repository News
Portage to verify git-synced ::gentoo per default - 01/11/2025 00:00 GMT
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.
This behavior change 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
Posted By: Florian Schmaus
OpenZFS packages merged - 14/10/2025 00:00 GMT
To simplify maintenance and system administration, sys-fs/zfs-kmod has been merged into sys-fs/zfs starting from version 2.4.0_rc2-r1. If you are using in-kernel modules from a custom built kernel you should unset the modules USE flag for sys-fs/zfs to not build and install kernel modules via sys-fs/zfs. If you were using sys-fs/zfs-kmod and sys-fs/zfs before, you have not to do anything special while upgrading as the package manager will take care of deinstalling sys-fs/zfs-kmod before upgrading to the new sys-fs/zfs version containing the modules. If you experience a blocker, you may have to remove sys-fs/zfs-kmod from your world file by running emerge --deselect sys-fs/zfs-kmod
Posted By: Marc Schiffbauer
Cache-enabled sync mirrors only for official repos - 07/10/2025 00:00 GMT
Due to increasing maintenance costs and complexities, Gentoo is going to stop providing the cache-enabled git syncing mirrors found in the gentoo-mirror GitHub organization [1], and CI services for third-party repositories. We will continue providing mirrors for a curated set of official repositories, including ::gentoo, ::guru, ::kde, and ::science. The remaining mirrors will be removed on 2025-10-30. This change does not affect users who have not used eselect-repository or users who have not used the gentoo-mirror repositories. It has no impact on syncing the Gentoo repository itself. It does not affect the availability of these repositories via >=app-eselect/eselect-repository-15 and repositories.xml -- the official upstream sync URI will be used instead. Users who have previously added repositories using=app-eselect/eselect-repository-15, in order to update their sync URIs. For example, the following can be used: eselect repository list -i # get list of repositories, and then... eselect repository remove ${repository} eselect repository enable ${repository} Once the mirrors are discontinued, we are going to remove them entirely in order to trigger sync errors for the remaining users, and ensure that they are not stuck on non-updated mirrors. This may show up as a 'username/password' prompt as GitHub does this for deleted repositories: if that happens, please follow the above instructions if not done so already! [1] https://github.com/gentoo-mirror/
Posted By: Michał Górny
app-backup/tsm changes to scheduled backups - 24/09/2025 00:00 GMT
In version 8.1.27.0 some changes were made to the way the init service scripts for systemd and openrc are distributed by app-backup/tsm. As a result some user intervention may be required. What changed? ==================== Gentoo now uses the init service scripts distributed by IBM as part of the DSM client rpm packages. Previously we used custom versions, which came with a number of drawbacks. Notably, in some configurations certain files could be skipped by the backup client during a scheduled backup operation [1]. To avoid such issues in the future it was decided to avoid straying too far from how upstream intends for this software to be used. A side effect of this is that the "dsmc" service script was removed, and only the (upstream) "dsmcad" service script remains. This affects both systemd and openrc. The DSM Client Acceptor Daemon (dsmcad) is a more lightweight and modern alternative to continuously running a "dsmc sched" process. It can be configured to manage scheduled backup operations as well as the webclient [4]. Note that the localisation option of the dsmcad service is configurable in /etc/tivoli/dsmcad.lang. Users may change this setting, but please note that IBM recommends using a single-byte character set (such as en_US) in order to ensure successful backups of all files regardless of the character set used in the filename [1]. Users who are certain that there systems do not mix filename character sets may wish to configure dsmcad to match this character set to ensure that log files and restore operations display the filenames correctly. User Action Required (systemd) ==================== Users who are using the DSM backup client with systemd and 'dsmc.service' to perform scheduled backups, should migrate to the more modern "dsmcad.service". # Verify the status of dsmc systemctl status dsmc If it is enabled, then first configure dsmcad to run the scheduler in your /etc/tivoli/dsm.sys file [4]. For example: # nano /etc/tivoli/dsm.sys ServernameManagedServices SCHEDULE # Then, disable dsmc and enable dsmcad systemctl disable --now dsmc systemctl enable --now dsmcad Note that a side-effect of this change is that the output of the scheduled backup is no longer written into the systemd journal. Instead the output of the acceptor daemon, as well as the scheduled backup operations that it runs, can be found in /var/log/tsm/. Thus additional adjustments to monitoring scripts may be required. User Action Required (OpenRC) ==================== Users who are using the DSM backup client on OpenRC systems and are currently using '/etc/init.d/dsmc' to perform scheduled backups should migrate to the more modern '/etc/init.d/dsmcad'. # Verify the status of dsmc rc-update show If it is enabled, then first configure dsmcad to run the scheduler in your /etc/tivoli/dsm.sys file [4]. For example: # nano /etc/tivoli/dsm.sys Servername ManagedServices SCHEDULE # Then, disable dsmc and enable dsmcad rc-update stop dsmc default rc-update del dsmc default rc-update start dsmcad default rc-update add dsmcad default Questions or issues? ==================== As usual, please report any issues you find in the 8.1.27.0 version on bugs.gentoo.org. And feel free to contact the author of this news item on IRC (Nowa) should you have any further questions. Further information ==================== For further information, please read the following documentation pages: [1] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=solaris-set-language-environment-variables [2] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=spso-setting-client-scheduler-process-run-as-background-task-start-automatically-startup [3] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=problems-starting-stopping-client-service [4] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=reference-managedservices [5] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=cs-comparison-between-client-acceptor-managed-services-traditional-scheduler-services
Posted By: Nowa Ammerlaan
encfs is unmaintained - 16/09/2025 00:00 GMT
sys-fs/encfs is effectively unmaintained upstream. Old archives are already hard to read without it crashing [1], and no new bugfixes are expected. Chances are data will become unreadable sooner than later. Upstream recommends migrating to newer alternatives, like app-crypt/gocryptfs [2]. Since migrating large quantities of data can take time, please consider migrating everything while it's still possible. Note: app-crypt/gocryptfs is better than encfs when used with local storage, but it may be extremly slow over sshfs or CIFS [3]. A faster alternative in such a case would be gocryptfs over rclone mount, or using rclone crypt directly. [1] https://github.com/vgough/encfs/issues/651 [2] https://github.com/vgough/encfs/?tab=readme-ov-file#status [3] https://github.com/rfjakob/gocryptfs/issues/764
Posted By: Viorel Munteanu
sys-apps/openrc user services introduction - 04/09/2025 00:00 GMT
OpenRC 0.62 (*) introduces user services as a new feature. The functionality
is documented on the wiki [0] and has a similar interface to conventional
system-wide services.
Support for user services is enabled by default via the pam_openrc module
in sys-auth/pambase, but it can be disabled via an OpenRC configuration
option as described below.
Some ebuilds already provide OpenRC user service init scripts, like
app-editors/emacs. More will follow, but use of user services is optional.
Requirements
============
User services currently require the XDG_RUNTIME_DIR environment variable to
be set, which may be done via sys-auth/elogind, sys-apps/systemd, or manually
via e.g. pam_env. In the future, pam_xdg may be packaged [1] as another option.
If the XDG_RUNTIME_DIR environment variable isn't set and user services have
not been disabled, the setup will fail gracefully but will appear in syslog
and rc-update.
Opting-out of user services
===========================
If users wish to disable OpenRC user services, they can set
rc_autostart_user="NO" in /etc/rc.conf:
...
# Set to "NO" if you don't want pam_openrc autostarting user services. This
# effectively disables the pam module, without the need of removing it from
# the pam configuration files.
rc_autostart_user="NO"
...
~/.profile and friends
======================
After stabilization, some users reported hangs when logging in [2]. None
were reported during the extensive period of testing in ~arch or by other
distributions who deployed newer versions of OpenRC. User services require
that ~/.profile, ~/.bash_profile run safely under a non-interactive
shell.
Commands in these shell startup files may be executed by a non-interactive
shell so commands that require a TTY, reading from stdin, and so on should
be guarded with a check for TTY like:
if [ -t 0 ] ; then
# Interactive commands here
...
fi
Please make sure to check your shell startup files for suspicious constructs
like the following:
...
if [ -x /usr/bin/keychain ] ; then # BAD
keychain ...
fi
...
... replacing them with:
...
if [ -t 0 ] && [ -x /usr/bin/keychain ] ; then # GOOD
keychain ...
fi
...
(*) User services were originally in sys-apps/openrc-navi and later as
part of >= OpenRC 0.62. The functionality was declared stable with 0.62.6
which was the first version with User Services stabled in Gentoo.
[0] https://wiki.gentoo.org/wiki/OpenRC#User_services
[1] https://bugs.gentoo.org/908431
[2] https://bugs.gentoo.org/962214
Posted By: Sam James
Stable hppa keywords removed - 01/09/2025 00:00 GMT
The Gentoo/HPPA team has decided that the time invested in package stabilization is no longer justified by the small number of users on the Hewlett Packard Precision Architecture (hppa). In addition, Gentoo currently lacks a working stable development machine. As a result, all "hppa" keywords will be changed to "~hppa" on 2025-09-01, with the "~hppa" keyword added to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/HPPA team does not currently plan to remove support for the architecture.
Posted By: Arthur Zamarin
Stable sparc keywords removed - 01/09/2025 00:00 GMT
The Gentoo/SPARC team has decided that the time invested in package stabilization is no longer justified by the small number of users on the SPARC architecture. In addition, Gentoo currently lacks a working stable development machine. As a result, all "sparc" keywords will be changed to "~sparc" on 2025-09-01, with the "~sparc" keyword added to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/SPARC team does not currently plan to remove support for the architecture.
Posted By: Arthur Zamarin
Breaking changes in nginx packaging in Gentoo - 05/07/2025 00:00 GMT
NGINX is a web server and a reverse proxy. Following a year-long effort, its
packaging in Gentoo has undergone a major revamp[1]. Starting from the mainline
version 1.29.0 the changes will come into force.
On 2025-09-05, the stable version will also have the changes
described below in the "What changed?" section. This enables more thorough
testing before user-facing changes are applied to the stable NGINX version.
If you are reading this NEWS item, the information below is relevant for you.
What changed?
====================
There are a few user-facing changes with the updated packaging.
1. Third-party modules.
Third-party modules, which were previously part of the NGINX package,
www-servers/nginx, are now separate packages in the www-nginx/ category. The
Lua, Brotli, headers-more and upload-progress are examples of the modules that
are now separate packages. Some of the modules have been removed completely.
The following is a list of modules that have been removed. If you rely
on any of the modules outlined below, please file a bug on Gentoo
Bugzilla[2][3] asking the module to be added. The recommended summary
for a bug is "www-servers/nginx: please add module MODULE_NAME", where
MODULE_NAME is the name of the module you would like to see added.
Removed modules:
- ngx_cache_purge/http_cache_purge_module
- nginx_ngx_slowfs_cache/http_slowfs_cache_module
- ngx_http_auth_pam_module/http_authpam_module
- nginx_upstream_check_module/http_upstream_check_module
- ngx_metrics/http_metrics_module
- naxsi/http_naxsi_module
- nginx-rtmp-module/rtmp_module
- nginx-push-stream-module/http_push_stream_module
- nginx-sticky-module-ng/http_sticky_module
- nginx-mogilefs-module/http_mogilefs_module
- nginx-auth-ldap/http_auth_ldap_module
2. USE flags.
Some USE flags, like "http-cache", "ktls", "pcre", "pcre-jit" and so on,
have been removed. They did not have any effect or served no purpose,
thus you need not worry about them.
The "http2", "http3" use flags have been renamed to
nginx_modules_http_v2 and nginx_modules_http_v3 respectively. They
correspond to NGINX_MODULES_HTTP "v2" and "v3" USE_EXPAND flags
accordingly. "ssl" use flag has been changed into individual "ssl"
USE_EXPAND flags for the mail, stream and HTTP servers.
Thread pool support[4], previously toggled by the "threads" USE flag, is
now enabled unconditionally. Vim syntax files are now provided by the
main www-servers/nginx package, instead of app-vim/nginx-syntax.
3. Default log files.
Default log filenames are now error.log and access.log, instead of
error_log and access_log.
User Action Required
====================
To upgrade to the new NGINX version, use the following command.
emerge --deselect app-vim/nginx-syntax
emerge --oneshot --update --deep www-servers/nginx
If you use any third-party modules, install the new separate package.
For instance, if you previously enabled the nginx_modules_http_lua USE
flag on www-servers/nginx, here is how you install the new Lua module
package.
emerge www-nginx/ngx-lua-module
To list all the available module packages, use
emerge --search @www-nginx | less
or
qlist --installed --tree www-nginx/
If you use the "http2" or "http3" USE flags, enable the corresponding
USE_EXPAND flags. To enable http2 only:
echo 'www-servers/nginx NGINX_MODULES_HTTP: v2' >> \
/etc/portage/package.use/nginx.use
To enable http3:
echo 'www-servers/nginx NGINX_MODULES_HTTP: v3' >> \
/etc/portage/package.use/nginx.use
To enable both http2 and http3:
echo 'www-servers/nginx NGINX_MODULES_HTTP: v2 v3' >> \
/etc/portage/package.use/nginx.use
SSL/TLS modules are enabled by default. If you wish to disable them, use
the following command.
echo www-servers/nginx NGINX_MODULES_HTTP: -ssl \
NGINX_MODULES_STREAM: -ssl \
NGINX_MODULES_MAIL: -ssl >> \
/etc/portage/package.use/nginx.use
The updated NGINX comes with a new logrotate file that points to the new
log filenames. If any of your scripts rely on the old log files, change
them accordingly as needed.
[1]: https://github.com/gentoo/gentoo/pull/37590
[2]: https://bugs.gentoo.org/
[3]: https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide
[4]: https://nginx.org/en/docs/ngx_core_module.html#thread_pool
Posted By: Zurab Kvachadze
nftables systemd service change - 24/05/2025 00:00 GMT
net-firewall/nftables-1.1.1-r1 made some changes to the provided systemd units. Prior to this version, nftables-restore.service was responsible for both loading rules on system startup and for saving them on system shutdown. The service has now been split in two: nftables-load.service is responsible for loading rules at startup. Users who relied on nftables-restore.service to load firewall rules must now enable nftables-load.service instead. nftables-store.service may be used to save the current ruleset by starting it at any time. It may also be enabled to store the ruleset at shutdown. Use of this service is not mandatory if the user chooses to maintain the saved ruleset manually.
Posted By: Mike Gilbert