Gentoo Repository News
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
net-mail/dovecot-2.4.x may break on upgrade - 23/05/2025 00:00 GMT
Dovecot-2.4 introduced breaking change to its entire configuration system and Dovecot-2.3 configuration files will NOT work after upgrade. Please read https://doc.dovecot.org/2.4.1/installation/upgrade/2.3-to-2.4.html before upgrading. 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 -n 2. Stop the dovecot daemon 3. Move ALL your configuration files to a temporary location 4. Upgrade to dovecot-2.4.x 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
Posted By: Eray Aslan
Gentoo raises s390x baseline to z10 - 14/04/2025 00:00 GMT
Since more and more software for s390x assumes the presence of a more recent processor, we will raise the ISA baseline in 64bit s390x profiles for the catalyst stage builds and the published binary packages from z900 to z10 (i.e., -march=z10). * If you are running an installation and emerge locally from source, this does not affect you. * If you are running an installation and use our binary packages, please make sure you have compatibility for z10 or switch to building from source. * The 64bit s390x stages will only work with machines compatible with z10. * This does not affect the 31bit s390 stages or packages. The z10 Enterprise Class (2097 series) was introduced in February 2008 [1], which essentially means everyone except hardware archaeologists should be fine. Note that z10 is still a very conservative setting; on modern machines a newer ISA is strongly recommended. [1] https://en.wikipedia.org/wiki/IBM_Z
Posted By: Andreas K. Hüttel
SELinux default POLICY_TYPES update - 26/03/2025 00:00 GMT
In line with our wiki recommendations, the default SELINUXTYPE set in /etc/selinux/config is now the mcs policy type. Hence, POLICY_TYPES has been updated to build all policy types by default if none are selected in make.conf. If a user does not explicitly have an override set for POLICY_TYPES, a full rebuild of selinux policy packages will be required: emerge --ask --oneshot @selinux-rebuild
Posted By: Rahul Sandhu
Python 3.13 to become the default on 2025-05-01 - 24/03/2025 00:00 GMT
We are planning to switch the default Python target of Gentoo systems on 2025-05-01, from Python 3.12 to Python 3.13. 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_12 */* PYTHON_SINGLE_TARGET: -* python3_12 This will enforce Python 3.12 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.13 targets: */* PYTHON_TARGETS: -* python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 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.13 support to your system first, and only then remove Python 3.12. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.12 and Python 3.13, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_12 python3_13 */* PYTHON_SINGLE_TARGET: -* python3_12 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_12 python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 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.14, and upgrade manually then. Upgrade commands ================ The Python 3.12 cleanup requires that Python 3.12 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.10 (python3_10) and PyPy 3.10 (pypy3). If you were using the pypy3 target before, now you will need to explicitly enable per-version targets, such as: */* PYTHON_TARGETS: pypy3_11 Note that PyPy support is available only for systems accepting ~arch keywords.
Posted By: Michał Górny
Certbot rework and transition - 14/03/2025 00:00 GMT
Certbot and its modules have been reworked into a single package; this should ease maintenance and make delivery faster and more reliable. Starting from app-crypt/certbot-3.2.0-r100, only this package is necessary to install Certbot and its modules thanks to the help of USE flags. Some block statements are enforced for modules packages to avoid collisions. However actions from users are required: @world set and package.use changes. Temporary transition metapackages call for the appropriate USE flags, but users still have to change their package.use and later they must update their @world set to complete the transition before 2025-06-10 (around three months from publication), after which these temporary transition packages will be removed. As a reminder, there is a Wiki page for Certbot: https://wiki.gentoo.org/wiki/Let%27s_Encrypt Step by step: 1. In /etc/portage/package.use: Add an entry for the modules of your choice based on the USE flags of the new unified package. Example: app-crypt/certbot certbot-apache certbot-dns-rfc2136 If you wish to stick with stable you may stop here. The below steps (skipping step 2) will be completed later once the unified package stabilizes. Should you wish to complete the transition now: 2. In /etc/portage/package.accept_keywords: (skip this step and continue with step 3 if completing after the unified package stabilizes): Add a keyword entry for the new unified package. Example: ~app-crypt/certbot-3.2.0 ~amd64 3. Clean the old module packages out of your @world or other sets: emerge --ask --deselect app-crypt/acme app-crypt/certbot-apache \ app-crypt/certbot-dns-cloudflare app-crypt/certbot-dns-desec \ app-crypt/certbot-dns-dnsimple app-crypt/certbot-dns-nsone \ app-crypt/certbot-dns-rfc2136 app-crypt/certbot-nginx 4. Emerge or update app-crypt/certbot if necessary. This should remove previous packages: emerge --verbose --ask --changed-use --noreplace app-crypt/certbot
Posted By: Thibaud CANALE