{"articles":[{"atomspec":["net-firewall\/nftables"],"authoremail":"floppym@gentoo.org","authorname":"Mike Gilbert","body":["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."],"newsid":"2025-05-24-nftables-service","posted":"2025-05-24","title":"nftables systemd service change","urls":[]},{"atomspec":["net-mail\/dovecot"],"authoremail":"eras@gentoo.org","authorname":"Eray Aslan","body":["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"],"newsid":"2025-05-23-dovecot-2_4-upgrade","posted":"2025-05-23","title":"net-mail\/dovecot-2.4.x may break on upgrade","urls":[]},{"atomspec":[],"authoremail":"dilfridge@gentoo.org","authorname":"Andreas K. Hüttel","body":["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."],"newsid":"2025-04-14-s390x-baseline-z10","posted":"2025-04-14","title":"Gentoo raises s390x baseline to z10","urls":["https:\/\/en.wikipedia.org\/wiki\/IBM_Z"]},{"atomspec":["sec-policy\/selinux-base"],"authoremail":"nvraxn@gmail.com","authorname":"Rahul Sandhu","body":["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"],"newsid":"2025-03-26-selinux-policy-types","posted":"2025-03-26","title":"SELinux default POLICY_TYPES update","urls":[]},{"atomspec":["dev-lang\/pypy:3.10","dev-lang\/python:3.10","dev-lang\/python:3.11","dev-lang\/python:3.12"],"authoremail":"mgorny@gentoo.org","authorname":"Michał Górny","body":["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."],"newsid":"2025-03-24-python3-13","posted":"2025-03-24","title":"Python 3.13 to become the default on 2025-05-01","urls":[]},{"atomspec":["app-crypt\/acme","app-crypt\/certbot","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"],"authoremail":"thican@thican.net","authorname":"Thibaud CANALE","body":["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\tcertbot-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\t~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"],"newsid":"2025-03-14-certbot-rework","posted":"2025-03-14","title":"Certbot rework and transition","urls":[]},{"atomspec":["sys-kernel\/installkernel[dracut]"],"authoremail":"nowa@gentoo.org","authorname":"Nowa Ammerlaan","body":["Dracut is an initramfs generation tool. It may be invoked via the installkernel mechanism in order to automatically generate a new initramfs when the kernel is installed. If you are reading this then sys-kernel\/installkernel is configured to use Dracut and the below is relevant for you.","What changed? ====================","Starting with version 106 of sys-kernel\/dracut the default for the \"hostonly\" setting has changed from disabled to enabled when Dracut is invoked via installkernel[1].","\"hostonly\" is a setting for Dracut that controls how much is included in the generated initramfs image. When it is disabled Dracut aims to generate an initramfs image that is bootable on any hardware. On the other hand, when this setting is enabled, Dracut aims to generate an initramfs image containing only what is needed to boot the current system. The advantage is a significantly smaller initramfs images, but this comes with the cost of losing portability.","Example: When the \"hostonly\" setting is disabled, Dracut's drm module will cause all GPU drivers to be included in the initramfs. When it is enabled, only the drivers for GPUs that are currently present in the system are included in the initramfs.","Enabling the \"hostonly\" setting was and is our recommendation for most use cases. This however was not the default behaviour in versions prior to 106.","Note, the default value for the \"hostonly\" setting has changed only when Dracut is invoked via installkernel. Disabled remains the default behaviour when Dracut is invoked directly.","User Action Required ====================","If your system is already configured to enable \"hostonly\" setting via \/etc\/dracut.conf.d\/ then effectively nothing has changed for you.","However, if Dracut has previously not been configured to enable the \"hostonly\" setting, then starting with version 106 the behaviour of Dracut will change for you. Though we do not expect major problems, we recommend ensuring a backup booting option remains available before rebooting the system after the first kernel upgrade following the upgrade of Dracut. This is usually the case unless the old kernels are manually removed by the user.","If you do experience a booting problem with the \"hostonly\" enabled initramfs images, then please report this problem to Dracut[2].","The \"hostonly\" setting may be disabled via \/etc\/dracut.conf.d\/ configuration snippets. For example:","\techo \"hostonly=no\" >> \/etc\/dracut.conf.d\/95-no-hostonly.conf"],"newsid":"2025-02-03-dracut-hostonly","posted":"2025-02-03","title":"Dracut changed default for hostonly setting","urls":["https:\/\/github.com\/dracut-ng\/dracut-ng\/pull\/1158","https:\/\/github.com\/dracut-ng\/dracut-ng\/issues"]},{"atomspec":["app-admin\/haskell-updater","app-arch\/pack","app-portage\/hackport","app-text\/pandoc","dev-lang\/ghc","dev-lang\/whitespace","dev-util\/shelltestrunner","dev-vcs\/darcs","dev-vcs\/git-annex","dev-vcs\/git-repair","net-mail\/list-remote-forwards","net-mail\/mailbox-count","net-misc\/haeredes","net-misc\/hath","x11-misc\/xmobar","x11-wm\/xmonad","x11-wm\/xmonad-contrib"],"authoremail":"mattst88@gentoo.org","authorname":"Matt Turner","body":["Packaging Haskell software has proven difficult in Gentoo: many packages are outdated, unstable versions have not been stabilized in nearly a year, and stable versions are rather old.","In an effort to reduce the load on the Haskell maintainers, stable keywords will be removed from dev-haskell\/* packages and their reverse dependencies on October 1.","Users with Haskell packages should add entries to their package.accept_keywords for these packages to avoid issues rebuilding or upgrading them in the future.","This change does not preclude stabilizing Haskell packages in the future.","Haskell packaging is mostly taking place in the Haskell repository [1]."],"newsid":"2024-09-29-haskell-destabilization","posted":"2024-09-29","title":"Haskell destabilization","urls":["https:\/\/github.com\/gentoo-haskell\/gentoo-haskell"]},{"atomspec":["kde-apps\/kio-extras:5","kde-apps\/libkgapi:5","kde-frameworks\/baloo:5","kde-frameworks\/kglobalaccel:5","kde-frameworks\/kguiaddons:5","kde-frameworks\/kuserfeedback:5","kde-frameworks\/kwallet:5","kde-misc\/kio-gdrive:5","kde-plasma\/libplasma:5","kde-plasma\/plasma-workspace:5"],"authoremail":"asturm@gentoo.org","authorname":"Andreas Sturmlechner","body":["Reasons =======","KDE Plasma 5 has reached end of life and is no longer supported by Gentoo. Qt5 upstream OSS support ended on 2020-12-08, and LTS releases - even with considerable effort by KDE community's backports on top - only go so far. It is therefore required for all users to upgrade to KDE Plasma 6[1].","At the same time, KDE Gear 24.05.2 is provided with most applications ported over to KDE Frameworks 6. As long as KF5-based applications are being shipped with the KDE Gear bundle, and other non-KDE Qt5-based applications still common in ::gentoo repository, it is advised *not* to disable USE=\"qt5\".","Changes =======","Not many - much like Qt6, this is mostly an evolution of the existing codebase, no disruptive feat.","Plasma Wayland support has come a long way and therefore KDE developers have decided to make it the default login session for Plasma 6, even if some known papercuts[2] remain. For users affected too much by those, switching to the still existing X11 session is as easy as selecting it in the display manager of choice. Disabling USE=\"wayland\" is *not* changing this default, it will yield no dependency savings, and we advise against doing so. It does not affect users' X11 sessions.","In Gentoo:","The 32-bit ~arm\/arm keyword was inconsistent across KDE Plasma, KDE Frameworks, and KDE Gear, and has been dropped.","The situation for x86 was similar to arm and test failures often blocked stabilization. Stable x86 has been dropped, ~x86 was dropped for KDE PIM, dev-util\/kdevelop and any other dev-qt\/qtwebengine:6 reverse dependencies.","User Action Required ====================","For users of a desktop profile[3], no specific upgrade steps are necessary, although some precautionary measures are advised before and during upgrade:","- Switch to a standard (Breeze or Oxygen) theme - Depclean kde-misc\/latte-dock, it is unfit for Plasma 6 (and masked already) - Cleanup sets and @world from any SLOT or version pinning of KDE packages - If possible, perform the upgrade not inside a running Plasma session","Necessary USE flag changes were already made in desktop profile, therefore only users of other profiles should set USE=\"kf6compat qt6\" globally[4].","Users are recommended to run the following command (pretend-only) to identify packages in @world which have been removed, to help reduce conflicts:","    emerge -pev @world --backtrack=0","Then for any \"no ebuild available\" messages, either resolve it by making the needed changes, or emerge --deselect them. Then proceed to the world upgrade below.","Once the packages become available on your arch, it should be as simple as update @world:","    emerge -avuUD @world","Run dispatch-conf (preferred) or etc-update to get updated configuration files:","    dispatch-conf","Then depclean:","    emerge -ac"],"newsid":"2024-08-31-kde-plasma6-gear-24-05-stable","posted":"2024-08-31","title":"KDE Plasma 6.1.4 and Gear 24.05.2 Upgrade","urls":["https:\/\/kde.org\/plasma-desktop\/","https:\/\/community.kde.org\/Plasma\/Wayland_Known_Significant_Issues","https:\/\/wiki.gentoo.org\/wiki\/KDE#Profile","https:\/\/wiki.gentoo.org\/wiki\/\/etc\/portage\/package.use"]},{"atomspec":["sys-kernel\/dracut"],"authoremail":"floppym@gentoo.org","authorname":"Mike Gilbert","body":["Starting with dracut-102, cryptsetup support for systemd has been moved into a separate module \"systemd-cryptsetup\". Under specific conditions, this change may cause a failure to boot. [1]","Users who are not using cryptsetup at all will not be affected.","Users who use the \"dracutmodules\" config option to explicitly name all modules to be included may be affected if they fail to update their dracut configuration to include the new \"systemd-cryptsetup\" module.","Users who have not altered the default config or who are not using the \"dracutmodules\" option should not be affected.","The dracut.conf(5) manual page warns against using \"dracutmodules\". Instead, \"add_dracutmodules\" and \"omit_dracutmodules\" can be used to to alter the default module list with less risk of omiting modules by accident."],"newsid":"2024-08-09-dracut-crypt","posted":"2024-08-09","title":"dracut module config changes","urls":["https:\/\/bugs.gentoo.org\/937326"]}]}