Gentoo Packages

net-libs/nodejs is now installed into a versioned slot, one slot per Node.js major release. Node 24 and Node 26 are available today. The old unslotted package, net-libs/nodejs:0, is masked in this overlay and can no longer be installed.

The upgrade will not happen on its own. Every slot carries a strong blocker against the unslotted package, so an ordinary world update stops and asks you to act rather than silently replacing it.



What you have to do ===================

1) Sync, so the mask and the new slots reach your tree:

     emerge --sync

2) Look at what portage intends to do. The conflict is reported here,

 during dependency resolution, before anything is written to disk:

     emerge --pretend --verbose net-libs/nodejs

 A line blocking net-libs/nodejs:0 appears, resolved by unmerging
 the unslotted package you currently have installed.

3) Migrate with a SINGLE emerge invocation:

     emerge --oneshot net-libs/nodejs

 One command, not two. Portage unmerges net-libs/nodejs:0 and merges
 the new slot within the same run, and between those two points the
 system has no /usr/bin/node at all - the new slot only restores it
 in pkg_postinst, after it has finished installing. Splitting the
 step, for instance `emerge --unmerge net-libs/nodejs` followed by a
 separate emerge, leaves the machine without node for the entire
 duration of the rebuild. That is not a short window, and anything
 that shells out to node in the meantime will fail.

 (--oneshot concerns the world file, not the number of commands: it
 means the package is not added to @world, leaving the entry you
 already have alone. The "single invocation" point above is about
 running one emerge. The two are unrelated.)

4) Check the result:

     eselect nodejs list

 The active slot is marked in the list. `eselect nodejs show` prints
 its name alone, and `eselect nodejs set node24` switches to another
 installed slot.

What changed ============

Everything version-specific now lives under a slot prefix, /usr/lib64/node-<major>/ (or whichever libdir your profile uses), rather than being spread across /usr/bin, /usr/include, /usr/lib64 and /usr/share.

/usr/bin/node, /usr/bin/npm and /usr/bin/npx are no longer owned by net-libs/nodejs. They are symlinks owned by app-eselect/eselect-nodejs and are repointed by `eselect nodejs set`. Each slot additionally installs its own versioned entry points - node26, npm26, npx26 - which always run that slot, whichever one happens to be active.

Globally installed npm packages are no longer shared between slots. `npm root -g` now resolves inside the active slot, under /usr/lib64/node-<major>/lib/node_modules, so a package installed globally while one slot was active is not visible from another. Install it once per slot you actually use.

A slot built with USE="-npm" ships neither npm nor npx. eselect skips those links instead of leaving them pointing at nothing.



Your npm configuration is not lost ==================================

/etc/npm and /etc/env.d/50npm have moved from net-libs/nodejs to app-eselect/eselect-nodejs. NPM_CONFIG_GLOBALCONFIG still points at the same single /etc/npm/npmrc, shared by every slot, with the same contents as before. Nothing needs to be copied or re-entered.

That move is also why app-eselect/eselect-nodejs itself blocks net-libs/nodejs:0: the unslotted package still lists /etc/env.d/50npm in its CONTENTS, and with FEATURES="protect-owned" a merge that touched a file another package owns would be aborted.

npm's manpages did move: they now live inside the slot prefix and are reached through MANPATH in /etc/env.d/50nodejs. As a result `man npm-install` documents the slot that is currently active. That variable only reaches a shell which has read the regenerated environment, so after your first switch either open a new shell or run:

     source /etc/profile

If you need Node 22 ===================

This overlay ships Node 24 and Node 26 only. With net-libs/nodejs:0 masked there is no source of Node 22 here, even though upstream keeps that branch in Maintenance until 2027-04-30. This is a known gap on day one, not an oversight, and it will close when a 22.x slot is added.

Unmasking net-libs/nodejs:0 is not a way around it: that package is the unslotted one, and it blocks both the slots and eselect-nodejs, so it cannot coexist with anything described above. Until a 22.x slot exists, either move the workload to Node 24 - which is the closest supported slot shipped here - or obtain Node 22 from outside portage and keep it out of /usr.



Why this overlay carries it ===========================

Slotting Node.js was proposed to Gentoo in bug #580698 and closed RESOLVED WONTFIX on 2020-11-09, as "highly non-trivial to slot NodeJS"; the package is maintainer-needed there. bentoo therefore becomes the sole provider of net-libs/nodejs for anyone using this overlay, and takes on security tracking for every slot it hosts.

  https://bugs.gentoo.org/580698

eselect nodejs reference ========================

  list      show every installed slot, marking the active one
  show      print the active slot name, or nothing when none is
            active
  set       activate a slot, by name (node26) or by list number
  update    activate the highest installed slot
  cleanup   drop links left dangling by an unmerged slot, then
            re-point at whatever is still installed

You can switch slots at any time. The ebuilds call these actions themselves on merge and unmerge, so a normal install never requires running them by hand.

app-misc/notion has been dropped due to complexity with maintaining the ebuild. It has not been updated in a long time, so this shouldn't be a huge surprise.

As always, please give feedback/report issues on our issue tracker: https://git.rgst.io/jaredallard/overlay/issues

The gentoo-zh overlay was transferred from the personal account:

https://github.com/microcai/gentoo-zh

to the gentoo-zh organization through GitHub repository transfer, and
then renamed to its current location:

https://github.com/gentoo-zh/overlay

Both old addresses (microcai/gentoo-zh and gentoo-zh/gentoo-zh)
301-redirect to the new repository in a single hop, for both the web and
Git, so existing setups keep working. The gentoo-zh overlay is now
maintained in the new repository.

Please use the new repository for future issues, pull requests, and
maintenance discussions.

For more details, see MIGRATION.md in the repository.

Users who configured the gentoo-zh overlay manually can update to the new
address when convenient.

Re-add the overlay:

sudo eselect repository remove gentoo-zh
sudo eselect repository add gentoo-zh git https://github.com/gentoo-zh/overlay.git
sudo emaint sync -r gentoo-zh

Or edit whichever file under /etc/portage/repos.conf/ contains the [gentoo-zh]
section (eselect-repo.conf if you added it with eselect) and set its sync-uri to
the new address:

[gentoo-zh]
location = /var/db/repos/gentoo-zh
sync-type = git
sync-uri = https://github.com/gentoo-zh/overlay.git
auto-sync = yes

Then run emerge --sync gentoo-zh.

The initial testing window from the 2026-05-29 import has closed and the package.mask on TeX Live 2025/2026 has been removed. The set -- texlive-core, the 39 dev-texlive/* collections, and the split build tools -- is now visible by default on ~amd64 and ~arm64. TL2026 is the highest version, so an ~arch `emerge -uDN @world` will upgrade TL2024 -> TL2026.

Stable amd64 users are unaffected: these ebuilds are ~amd64 and ::gentoo's TL2024 stays stable.

== Upgrade as a set ==

Some packages moved between collections across TL years. The ebuilds carry blockers that order the moves, but they resolve cleanly only when the whole set upgrades together -- use `emerge -uDN @world`. A partial merge can hit protect-owned collisions; add FEATURES="-protect-owned" if you must do one.

== Reporting problems ==

If you encounter any problem related to TeX Live -- a failed merge or a document that no longer builds -- please report it at https://github.com/istitov/stuff/issues with the exact category/pkg-version, your `emerge --info`, and the failing build log or LaTeX output.

== More ==

See the 2026-05-29 news item, "TeX Live 2025/2026 imported", for the xelatex font-by-name fontconfig note and the early opt-in background.

The legacy 32bit ABI support for IBM S390 mainframes is on the way out just about everywhere:

• Pure 32bit hardware is by now nonexistent (64bit support exists since 2002).
• Full 32bit kernel support is gone since 2014.
• The 32bit ABI userspace emulation layer has been dropped in the kernel since version 6.19.
• glibc will drop 32bit ABI support in version 2.44.
• gcc will drop 32bit ABI support in version 17.

As a consequence, Gentoo will also drop support for it, effective immediately. There will be no stage builds anymore. The 32bit profiles will be marked deprecated and experimental, no longer receive any testing, and be removed in the next profile version. Corresponding bug reports may get ignored or closed immediately. If you are still using this configuration, we urge you to find an alternative.

This does *not* affect the 64bit code ("s390x", CHOST=s390x-ibm-linux-gnu) with its profiles and stages.

Starting with version 19.1.0 GitLab recommends the pg_stat_statements PG extension. To list the current PG extensions run as the PG admin user:

psql -d <your GitLab DB> -c "\dx"

To create the extension do:

psql -d <gitlab DB> -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;"

Jackson (hi it's me) has gotten contributor access to Gentoo's GURU repository, a project under Gentoo for ebuilds maintained entirely by Gentoo users. (For more information on GURU, see [1].)

Since I have gotten access to GURU, I plan to move some (but not all) ebuilds within the jacksonchen666 repository to GURU. When moving ebuilds to GURU, they will be silently treecleaned from the jacksonchen666 repository after it appears in GURU. This news item is shown to you because you have installed one or more ebuilds that will be moved to GURU.



Required Action ===============

To make sure you don't lose ebuilds, you should add the GURU repository to your system. Please read the GURU disclaimer[2] before adding GURU to your system.

eselect way:

  eselect repository enable guru

Manual repos.conf entry: See [3].

If you already have the GURU repository enabled, you should not have to do anything.

If you reference the ::jacksonchen666 repository in your portage configuration, you should remove it, or change them to ::guru when the ebuilds move. (Note that each individual ebuild moves, now or done down the road, will not be explicitly announced.)

Portage should automatically start using the GURU repository with newer versions of ebuilds.



Differences between this repository and GURU ============================================

Bug reports for packages within GURU (including ebuilds maintained by Jackson) must be directed to bugs.gentoo.org, not jacksonchen666's repositories. You can go to [4] for creating a bug report in GURU.



[1] https://wiki.gentoo.org/wiki/Project:GURU [2] https://wiki.gentoo.org/wiki/Project:GURU#Disclaimer [3] https://wiki.gentoo.org/wiki/Project:GURU/Information_for_End_Users [4] https://bugs.gentoo.org/enter_bug.cgi?product=GURU&component=Package%20issues&format=guided

The stuff overlay now ships TeX Live 2025 and 2026 -- texlive-core, the 39 dev-texlive/* collections, and the split build tools -- ahead of ::gentoo's TL2024.

== Masked for now ==

The set is ~amd64 and package.masked for an initial testing window, so it is not pulled by default, even on ~amd64. Stable amd64 users are unaffected (::gentoo's TL2024 is stable).

UPDATE: the mask was lifted on 2026-07-03, later than the 2026-06-12 date given when this item was first posted. The TeX Live block is no longer in profiles/package.mask, so no unmasking is needed. See the news item 2026-07-03-texlive-2025-2026-unmasked.

== Upgrading ==

Some packages moved between collections across TL years. The ebuilds carry blockers that order the moves, but they resolve cleanly only when the whole set upgrades together -- use `emerge -uDN @world`. A partial merge can hit protect-owned collisions; add FEATURES="-protect-owned" if you must do one.

== Known limitation ==

xelatex font-by-name (\setmainfont{Latin Modern Roman}) needs a fontconfig snippet for the texmf font dir -- the standard upstream TeX Live step. pdflatex and lualatex are unaffected.

KDE PIM's centralised Akonadi subsystem uses a database for cached data. Three different database backends have been supported for a long time. When multiple USE flags are enabled, kde-apps/akonadi-config ebuild picks the one with the highest priority (see the table under Changes below) as default DB backend in akonadiserverrc.

This means that prior to KDE PIM 26.04.1 (with kde-apps/akonadi-config-0), mysql, when enabled, took precedence for new KDE PIM setups.



Changes =======

With kde-apps/akonadi-config-1 we are making sqlite the highest priority instead. Existing Akonadi instance settings, which are kept in home directories, will not be changed automatically.

---------!--------------------------------!-----------!----------- Backend ! kde-apps/akonadi-config[<use>] ! <=26.04.0 ! >=26.04.1 ---------!--------------------------------!-----------!-----------

       !                                !  (priority, 1 = best)

QSQLITE ! sqlite ! 2 ! 1 QMYSQL ! mysql ! 1 ! 2 QPSQL ! postgres ! 3 ! 3



Reasons =======

Running a daemon brings its own set of problems and switching to the QSQLITE backends lets us avoid those. Also, SQLite is unavoidable on most systems, while MariaDB, MySQL, or PostgreSQL may often be installed purely for Akonadi, so it saves a large package being installed.

Historically[1], the QSQLITE backend was fundamentally broken for KMail's workload, which is why QMYSQL was picked as default early on. Over the years this has come with its own share of (mostly DB upgrade handling) bugs, but QSQLITE has only in recent years become viable again through upstream's efforts, which we have been tracking[2]. Recently, the default was finally changed upstream[3].



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

In order to implement any backend change on your users' akonadi DB config, a manual migration step is necessary - in this example, from mysql to sqlite. It is necessary to have support for both database drivers enabled in dev-qt/qtbase for this to succeed.

  1) Find out which backend is currently in use:

      grep "^Driver" ~/.config/akonadi/akonadiserverrc

  2) A quick check that both DB drivers are supported by Qt:

      USE="mysql sqlite" emerge -p1 dev-qt/qtbase

      If this command indicates a USE flag change, you must at least
      temporarily rebuild dev-qt/qtbase with both old and new enabled.

  3) Migration:

      akonadi-db-migrator --newengine sqlite

  The last command will not just migrate the database but also adapt
  akonadiserverrc accordingly.

---

In order to keep using QMYSQL backend for users' existing Akonadi instances, ensure that USE=mysql is permanently[4] enabled for kde-apps/akonadi-config [and dev-qt/qtbase respectively].

---

In order to keep QMYSQL backend as default choice for new Akonadi instances, make sure that USE=sqlite is disabled for kde-apps/akonadi-config.



[1] https://bugs.gentoo.org/441596 [2] https://bugs.gentoo.org/936102 [3] https://invent.kde.org/pim/akonadi/-/merge_requests/311 [4] https://wiki.gentoo.org/wiki//etc/portage/package.use

The pf-sources ebuilds that combine a vanilla kernel.org tarball with Gentoo genpatches and a curated subset of the pf-kernel patchset (the "-r70" / "-r71" model) have been moved to a new package:

  sys-kernel/pf-sources-extended

The new package covers the same kernel branches under simplified version names — the -r70/-r71 revision suffix is dropped because the package name now differentiates the model.

== What to do ==

sys-kernel/pf-sources-extended carries KEYWORDS="" and must be explicitly accepted. Add it to /etc/portage/package.accept_keywords:

  =sys-kernel/pf-sources-extended-X.Y_pZ **

The old and new ebuilds both install to /usr/src/linux-X.Y-pfZ/, so unmerge the old atom first to avoid a file-collision abort:

  emerge --unmerge =sys-kernel/pf-sources-X.Y_pZ-rN
  emerge -av =sys-kernel/pf-sources-extended-X.Y_pZ

where X.Y_pZ matches your current pf-sources version (e.g. 7.0_p2). The ebuilds are functionally identical; only the package name changed. Your running kernel and /lib/modules/X.Y-pfZ/ are unaffected — only the source tree under /usr/src/ is briefly removed and reinstalled.

== Background ==

sys-kernel/pf-sources retains its two original models:

• active (no -rY): fetches pf-kernel's sourcetree from Codeberg (vX.Y-pfN — vanilla GA plus pf patchset; pf-kernel deliberately omits linux-stable) and layers Gentoo genpatches on top, which bring linux-stable updates into the build.

• CVE-backported (-r1/-r2): same base as the active model plus a set of hand-applied surgical CVE backports for security fixes pf-kernel hasn't picked up. Intended for slots kept in long-term use.

sys-kernel/pf-sources-extended is the curated-patchset model: vanilla kernel.org tarball + Gentoo genpatches + a hand-curated subset of natalenko's pf-kernel delta (BBRv3, x86 ISA-level helpers, v4l2loopback, AMD-pstate enhancements, and related features). See the existing news item "2026-05-06-pf-sources-r70" for the full design rationale.

== References ==

• https://pfkernel.natalenko.name/
• https://dev.gentoo.org/~alicef/genpatches/

Dracut is an initramfs generation tool. It may be invoked via the installkernel mechanism or manually after building custom kernels.

What changed? =============

In version 111 of sys-kernel/dracut the default for the hostonly_cmdline setting changed from enabled to disabled.

When enabled, this setting causes Dracut to attempt to detect which parameters are required on the kernel command line to boot the system. Examples are the root= parameter or parameters controlling partition decryption. These parameters are then included in the generated initramfs and appended to the kernel command line during boot.

Why has this setting been changed? ==================================

When enabled, Dracut's hostonly_cmdline setting may use the kernel command line of the running kernel (/proc/cmdline) to construct the kernel command line that will be embedded in the initramfs.

This can cause problems when Dracut is being executed from a live or rescue environment. In such cases an incorrect root= could be included in the embedded kernel command line which could lead to boot failure.

To prevent this behaviour from causing such unpleasant surprises, a check was added to sys-kernel/installkernel to detect whether the kernel was being installed from chroot and if Dracut was configured to include an embedded kernel command line (hostonly_cmdline=yes).

While this check prevents boot failures, it also has the unfortunate side effect of creating a hard error that is triggered by default on new Gentoo installs. This has proven to be a significant stumbling block that new users often trip over. For this reason it was decided to disable the hostonly_cmdline setting in Gentoo's default settings for Dracut.

User Action Required (all users) ================================

With >=sys-kernel/dracut-111, users need to perform a sanity check described in this news item.

This sanity check will ensure that kernel parameters required to boot successfully are still present in the kernel command line. When in doubt, ensure system rescue media is close at hand.

More specific instructions for various setups follow below, ordered from the specific to the more general as listed here:

• Systemd GPT Auto Generator
• Generic Unified Kernel Image
• Unified Kernel Image with Secure Boot
• GRUB
• systemd-boot
• rEFInd
• other/general

For each option a summarised list of relevant files that should be double checked is provided first. In general the 'lsinitrd' tool provided by sys-kernel/dracut can be used to obtain the current embedded kernel command line, these kernel parameters will be absent after (re)generating an initramfs with version 111 of dracut.

As always, do not hesitate to use our support channels to ask for clarification or assistance.

> User Action Required (Systemd GPT Auto Generator)

=================================================
Files to double check:

• /dev/gpt-auto-root (symlink must be valid)
• If absent then the auto generator is not being used.

Systems that utilise the systemd GPT Auto Generator mechanism to automatically detect and find the root partition at boot should not require any manual intervention. Though, before rebooting, users should verify that the auto generator is actually being used and is working properly. To do so, check that /dev/gpt-auto-root currently exists and points to your root partition. For example:

$ ls -l /dev/gpt-auto-root

Should produce an output similar to the below if /dev/nvme0n1p1 is the root partition:

"""Output:
lrwxrwxrwx 1 root root 4 May  2 10:33 /dev/gpt-auto-root -> nvme0n1p1
"""

If this is not the case then proceed with the instructions below that best match the setup to ensure that the root partition is set on the kernel command line using an alternative method.

> User Action Required (Generic Unified Kernel Image: "generic-uki")

==================================================================
Files to double check:

• none

Users booting with the generic Unified Kernel Image (USE=generic-uki) functionality provided by the distribution kernels (dist-kernel) do not have to take any action as the hostonly_cmdline is already disabled in these builds:

• sys-kernel/vanilla-kernel[generic-uki]
• sys-kernel/gentoo-kernel[generic-uki]
• sys-kernel/gentoo-kernel-bin[generic-uki]

> User Action Required (Unified Kernel Image with Secure Boot)

============================================================
Files to double check:

• /etc/kernel/cmdline and/or /etc/kernel/uki.conf (ukify)
• /etc/dracut.conf and/or /etc/dracut.conf.d/*.conf (dracut)

Booting a Unified Kernel Image (UKI) with Secure Boot enabled is a special case because in this situation the kernel command line supplied by the bootloader or the firmware is ignored and the built-in UKI command line, along with the parameters embedded in the initramfs, take precedence. The instructions below are also relevant if no kernel command line is set by the bootloader or the firmware.

Verify whether Secure Boot is enabled with dmesg, for example:

$ dmesg | grep -i secure
"""Output:
[    0.012418] Secure boot enabled
"""

An easy way to check the built-in kernel command line of an UKI is to use the lsinitrd tool provided by sys-kernel/dracut. For example:

$ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi

This command will produce an output that could contain for example:

"""Output:
<snip>
Command line:
quiet
splash
root=PARTUUID=7ae430c6-07e8-3b4e-a796-b2a28706b3fb
<snip>
dracut cmdline:
ro
"""

Showing that the built-in kernel command line for this UKI contains "quiet", "splash" and sets the root partition to the partition that has the partition UUID "7ae430c6-07e8-3b4e-a796-b2a28706b3fb". Additionally, the kernel command line embedded in the initramfs contains "ro".

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the "Command line" section then user intervention is required. In that case please adjust the configuration of the UKI generator to include the appropriate kernel parameters in the built-in UKI command line.

If Ukify (sys-apps/systemd[ukify] or sys-apps/systemd-utils[ukify]) is generating the UKI then adjust the "Cmdline=" setting in /etc/kernel/uki.conf. If that setting is not present in the uki.conf then adjust the kernel command line in /etc/kernel/cmdline.

If Dracut itself is generating the UKI then please set or adjust the "kernel_cmdline=" setting in a dracut configuration file in /etc/dracut.conf.d/.

If unsure which tool is generating the UKI then please inspect the current value of "uki_generator" in /usr/lib/kernel/install.conf and /etc/kernel/cmdline.

> User Action Required (GRUB)

===========================
Files to double check:

• /etc/default/grub

Users booting with GRUB should compare the GRUB_CMDLINE_LINUX setting in /etc/default/grub against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI). The lsinitrd utility provided by sys-kernel/dracut can be used for this purpose. For example, in the case of a plain initramfs:

$ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img

Or, in the case of an Unified Kernel Image:

$ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/default/grub then user intervention is required. In that case please adjust the GRUB_CMDLINE_LINUX setting in /etc/default/grub to include the missing kernel parameters. After adjustments don't forget to update the grub.cfg. For example:

$ grub-mkconfig -o /boot/grub/grub.cfg

Note that when Secure Boot is enabled the grub.cfg might reside in a different directory, for example: /efi/EFI/Gentoo/grub.cfg.

> User Action Required (systemd-boot)

===================================
Files to double check:

• /etc/kernel/cmdline

Users booting with systemd-boot should compare the contents of /etc/kernel/cmdline against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI).

If Unified Kernel Images are used and the /etc/kernel/cmdline file is empty or missing then no kernel command line is set by systemd-boot, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled.

The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs:

$ lsinitrd /efi/gentoo/x.y.z-gentoo-dist/initrd

Or, in the case of an Unified Kernel Image:

$ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/kernel/cmdline then user intervention is required. In that case please adjust /etc/kernel/cmdline to include the missing kernel parameters.

> User Action Required (rEFInd)

=============================
Files to double check:

• refind_linux.conf

Users booting with rEFInd should compare kernel command line set in the refind_linux.conf file against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI).

The refind_linux.conf configuration file usually resides in /boot but may also be found elsewhere.

If Unified Kernel Images are used and the refind_linux.conf configuration file is empty or missing then no kernel command line is set by rEFInd, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled.

The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs:

$ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img

Or, in the case of an Unified Kernel Image:

$ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi

The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example:

"""Output:
<snip>
dracut cmdline:
ro
"""

If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the refind_linux.conf then user intervention is required. In that case please adjust refind_linux.conf to include the missing kernel parameters.

> User Action Required (other/general)

====================================

For other setups please refer to the wiki page or manual of your bootloader and find where the kernel command line is set. Then compare this setting with the kernel parameters embedded in the initramfs.

If essential parameters are present in the later but not in the former, then please move those parameters to your bootloader's configuration.

When Unified Kernel Images are used then also consider the built-in UKI command line set by the UKI generator. Note that when Secure Boot is disabled, the bootloader may override the built-in UKI command line. However, when Secure Boot is enabled then any parameters set by the bootloader are ignored and the built-in UKI command line is always used.

See Also ========

[1] https://github.com/dracut-ng/dracut-ng/pull/2399 [2] https://bugs.gentoo.org/971572

You are running a pf-sources -r70 ebuild. This news item explains the -r70 design and the tracking commitment for your branch.

== Design ==

The pf-sources -r70 ebuilds in this overlay track linux-stable via Gentoo's genpatches, with a curated subset of natalenko's pf-kernel patchset on top. CVE-2026-31431 (the "Copy Fail" algif_aead LPE) and other linux-stable-fixed CVEs are picked up via the genpatches stable chain on every -r70 — no separate patch is needed. This is fundamentally different from the unrevisioned and -r1 / -r2 pf-sources ebuilds, which apply natalenko's full patchset to vanilla v6.X.0 with no linux-stable backports.

For each -r70 slot, the curated subset retains pf features that are genuinely additive (BBRv3, x86 ISA-level helpers, zstd library updates, DDCCI / DDCCI-backlight, AMD-pstate enhancements, syscall.tbl additions, mm/include hooks) and drops pf changes that conflict with linux-stable backports or that gentoo-sources has already addressed (kernel/sched core/fair/rt, top-level arch/x86/Kconfig, "minor fixes" already landed in stable).

Each -r70 ebuild's pkg_postinst message lists exactly which pf features are retained on that slot and which are dropped, with reasons.

== Tracking commitment by branch ==

• Active branches (currently 6.18, 6.19, 7.0) — while natalenko continues to ship pf releases and linux-stable continues to ship point releases, the -r70 is re-cut on each genpatches bump. The curated pf delta usually carries forward; the gentoo-sources base shifts.

• LTS branches (currently 6.1, 6.6, 6.12) — natalenko has moved on but linux-stable continues for years. The pf delta is frozen at the last pf release for the branch; the -r70 is regenerated against each new genpatches release for the lifetime of upstream's stable maintenance.

• EOL branches (the 14 non-LTS slots 6.2-6.5, 6.7-6.11, 6.13-6.17) — linux-stable has stopped. The -r70 is frozen at the last genpatches release on that branch. No further updates; future security work happens on a still-active branch.

== References ==

• Per-slot retained / dropped breakdown: each -r70 ebuild's pkg_postinst message.
• https://pfkernel.natalenko.name/
• https://dev.gentoo.org/~alicef/genpatches/

This news item is for all pf-sources users in the stuff overlay. Three further news items, displayed only to specific revision cohorts, cover the technical details:

• "pf-sources: -r70 curated patch design" — for users on -r70.
• "pf-sources: CVE-2026-31431 Copy Fail patches" — for users on the affected -r1 / -r2 ebuilds.
• "Patch tarballs now hosted on extra-stuff sister repo" — for users on -r70 ebuilds, the trunk-pinned -r1 ebuilds, and sci-visualization/gwyddion3-3.9-r1.

== Background: CVE-2026-31431 "Copy Fail" ==

Copy Fail (CVE-2026-31431, CVSS 7.8) is a local privilege escalation in the kernel's algif_aead crypto socket family. Linux 7.0 GA (General Availability — the .0 release tree, before any linux-stable point releases are applied) shipped with the upstream revert that fixes it; every released branch from 6.1 through 6.19 was vulnerable until backports landed in linux-stable. The pf-kernel patchset is GA-only by design (natalenko ships only the .0 source tree, never the subsequent linux-stable point releases), so pf-sources ebuilds at v6.X.0 + pf-only are vulnerable to this and to many other linux-stable-fixed CVEs.

== What changed in the overlay ==

Three classes of revision now exist for pf-sources:

• Unrevisioned ebuilds (e.g. pf-sources-6.18_p6) remain GA-only: natalenko's pf-kernel patchset on top of vanilla v6.X.0. For 6.16-6.19 these are still vulnerable to Copy Fail; for 7.0_p1 / 7.0_p2 they are naturally clean (Linux 7.0 GA postdates the upstream revert).

• -r1 / -r2 ebuilds add the surgical or cumulative CVE-2026-31431 patch on top of natalenko's pf patchset. -r1 carries the surgical revert (used where v6.X.0 + pf matches mainline context); -r2 is the cumulative LTS form (used on 6.1, 6.6, 6.12 where the surgical context did not match).

• -r70 ebuilds are a fundamentally different design. Instead of fetching pf-kernel's GA-only sourcetree, -r70 builds vanilla linux-X.Y.tar.xz + Gentoo's genpatches (which include the full linux-stable backport chain) and applies a *curated subset* of natalenko's pf-kernel delta on top. CVE-2026-31431 is fixed via genpatches' linux-stable chain on every -r70. Each -r70's pkg_postinst message lists which pf features are retained on that slot and which are dropped, with reasons.

== GA-only ebuild phase-out ==

The four still-vulnerable GA-only ebuilds enter a 30-day lastrite cycle:

• sys-kernel/pf-sources-6.16_p5
• sys-kernel/pf-sources-6.17_p4
• sys-kernel/pf-sources-6.18_p6
• sys-kernel/pf-sources-6.19_p5

These are unkeyworded (KEYWORDS="") as of 2026-06-05, which is what keeps them from being pulled; the package.mask entry described when this item was first posted was not used in the end. The ebuilds themselves remain in tree as a recovery path. Users currently on one of these versions should switch to the matching -r1 (verbatim natalenko + surgical CVE patch) or -r70 (curated + linux-stable tracking) ebuild before 2026-06-05.

7.0_p1 and 7.0_p2 are not in this phase-out — they are naturally CVE-clean and remain available while 7.0 is an actively-tracked branch.

== References ==

• https://www.cve.org/CVERecord?id=CVE-2026-31431
• https://copy.fail/
• https://pfkernel.natalenko.name/
• https://dev.gentoo.org/~alicef/genpatches/

After a prolonged time of dormancy, this overlay is under active maintenance again. This news item summarises about a month of work.

== What has changed ==

• Per-package audits — pkgcheck cleanups, dated rationale for suppressions, metadata.xml normalization.
• Version handling — keep last-of-each-major for rollback; drop versions whose upstream caps don't solve against ::gentoo rather than relax the cap.
• sys-kernel/pf-sources -r70 GA-based slots — see the separate news item dated 2026-05-06.
• Sister distfile repo at github.com/istitov/extra-stuff for bundled patches that would otherwise hit pkgcheck's SizeViolation in the main overlay.

== AI / LLM assistance ==

AI-assisted work begins with commit 075ff35d (2026-04-19); the last fully-human commit is d0e1aa01 (2026-04-18) — a clean before/after boundary for review or bisect.

The maintainer uses LLM tooling for mechanical work; every commit is human-reviewed before landing, and the maintainer bears responsibility for correctness. Full policy and PR disclosure expectation: CONTRIBUTING.md, "🤖 AI / LLM assistance".

Regressions, or anything that looks LLM-generated and wrong: file at github.com/istitov/stuff/issues with the failing emerge log.

== References ==

• README.md — overlay highlights and design choices.
• CONTRIBUTING.md — house-style checklist and AI/LLM policy.

You are running a pf-sources revision that carries fixes for three CVEs. This news item describes each fix, why two patch forms exist (-r1 surgical vs -r2 cumulative LTS), and what incidental coverage the cumulative form provides.

Revision 2 of this item adds documentation of CVE-2026-43037 and CVE-2026-43038, which were already in these ebuilds at first publication but were missing from revision 1.

== The three CVEs ==

CVE-2026-31431 ("Copy Fail", CVSS 7.8) — local privilege escalation in the algif_aead crypto socket family. The vulnerable code path miscopies the Authenticated Associated Data (AAD) buffer when the in-place AAD path is taken on a request whose source and destination addresses overlap in a specific way. Upstream fix reverts the commit that introduced the in-place AAD path (mainline a664bf3d603d).

CVE-2026-43037 (CVSS 9.8) — stack OOB write in ip6_tunnel.c::ip4ip6_err() via inet6_skb_parm / inet_skb_parm cb[] reuse on a cloned skb. Mainline fix 2edfa31769a4 clears IPCB(skb2) and adds minimal IPv4 header validation.

CVE-2026-43038 (CVSS 9.8) — OOB read in icmp.c::ip6_err_gen_icmpv6_unreach() via the same cb[] type-confusion pattern, reachable via a forged ICMPv4 error with a CIPSO option. Mainline fix 86ab3e55673a clears IP6CB(skb2).

Linux 7.0 GA (the .0 release before any linux-stable point releases are applied) shipped after all three fixes and is not vulnerable.

== Two patch forms ==

The choice of form is driven entirely by whether the surgical patch's context matches v6.X.0 + pf — never by ergonomics.

• Surgical (pf-sources-6.16_p5-r1, -6.17_p4-r1, -6.18_p6-r1, -6.19_p5-r1) — the three upstream patches applied directly to v6.X.0 + pf: cve-2026-31431-algif_aead-revert-out-of-place.patch cve-2026-43037-ip6_tunnel-clear-skb-cb.patch cve-2026-43038-icmpv6-clear-skb-cb.patch

• Cumulative LTS (pf-sources-6.1_p6-r2, -6.6_p6-r2, -6.12_p4-r2) — the surgical patches' context did not match v6.X.0 + pf on the LTS branches because linux-stable's pre-fix backports had diverged too much. Instead this form ships two cumulative diffs over the affected files, computed as v6.X.0 -> v6.X.{latest stable} restricted to the relevant paths: cve-2026-31431-algif_aead-cumulative-<branch>.patch cve-2026-43037-43038-cumulative-<branch>.patch

== Incidental coverage on the LTS form ==

Because the cumulative diffs carry the full linux-stable history of the affected files between v6.X.0 and the latest stable release at the time the patches were cut, the algif_aead cumulative incidentally covers two more CVEs that landed in those files:

• CVE-2026-43043 — af_alg scatterwalk NULL-deref.
• CVE-2026-23060 — authencesn NULL-deref denial-of-service.

The surgical -r1 revisions do NOT incidentally cover these; they target only the named CVE commits.

== References ==

• https://www.cve.org/CVERecord?id=CVE-2026-31431
• https://www.cve.org/CVERecord?id=CVE-2026-43037
• https://www.cve.org/CVERecord?id=CVE-2026-43038
• https://www.cve.org/CVERecord?id=CVE-2026-43043
• https://www.cve.org/CVERecord?id=CVE-2026-23060
• https://copy.fail/

You are running an ebuild from the stuff overlay whose patch tarballs are now fetched from a sister GitHub repository, "extra-stuff" (https://github.com/istitov/extra-stuff), instead of being shipped in the overlay's own files/ tree.

== Why ==

A handful of packages in the stuff overlay carry substantial patches:

• sys-kernel/pf-sources -r70 ebuilds — a curated subset of natalenko's pf-kernel patchset, ~150 KiB to ~1 MiB per slot.
• sys-kernel/pf-sources orphan-slot -r70 + -r1 ebuilds — a per-slot snapshot of alicef's genpatches trunk dir, ~700 KiB to ~1.1 MiB per slot. The trunk dir at dev.gentoo.org is a live working directory, not a release archive; the snapshot pins immutable bytes for these branches.
• sci-visualization/gwyddion3-3.9-r1 — three pygwy stage patches (~600 KiB uncompressed).

Hosting these in the overlay's files/ tree pushed pkgcheck size limits and bloated every clone. Bundled as tarballs on extra-stuff and pinned to immutable git tags, they are fetched on demand at emerge time.

== No user action required ==

extra-stuff is purely a distfile host — it is NOT a Gentoo overlay. You do not need to register it with eselect repository. Portage fetches the tarballs as part of the normal install flow, and verifies them against BLAKE2B + SHA512 hashes pinned in each affected package's Manifest. If extra-stuff bytes ever changed in place, the hash mismatch would block the install.

== Bumping patches ==

Tarball revisions are tagged with a numeric suffix (-r70-0 today, -r70-1 next time, ...). When a tarball's contents need to change, the new bundle is published under a new tag and the affected ebuild's SRC_URI is updated to point to it. Older tarballs stay reachable for users still on older ebuild revisions.

== References ==

• extra-stuff repo: https://github.com/istitov/extra-stuff
• stuff overlay: https://github.com/istitov/stuff

Newer versions of Portage are making two changes to how binary packages work: 1) binary package signatures are now verified by default [0]; 2) fetched binary packages are stored separately from locally-built binaries

 (this change is already in a recent Portage release) [1].

 Remote binary packages are now cached in /var/cache/binhost/NAME where
 NAME is given by the configuration item in /etc/portage/binrepos.conf. This
 allows clean separation of locally built binary packages vs. those with
 remote provenance, and to allow verification of fetched packages without
 forcing signing to be set up for local binpkgs.

 The cache location can be customised by setting `location` in binrepos.conf.
 gentoolkit has been updated to handle these cache locations too.

This news item only applies if you use or produce binary packages.

Official binhost users ======================

Fetched binary packages are now stored at /var/cache/binhost/gentoo (or a similar path, depending on contents of /etc/portage/binrepos.conf/*).

No action is required, for two reasons: 1) all of the documentation included FEATURES="binpkg-request-signature", and 2) attempts to install a binpkg that is signed without any configuration

 would fail early.

The only impact is that future binary package installs will need less setup. Setting FEATURES="binpkg-request-signature" is no longer needed for this case.

Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location.

Users of just the official binary host can stop reading at this point.

Custom binhosts ===============

Users who host their own binary packages and redistribute them to their machines will need to either: 1) start signing their binpkgs [2], or 2) set `verify-signature = false` in /etc/portage/binrepos.conf/* for

 the relevant configuration file for your binhost.

Otherwise, fetched binpkgs will fail verification.

To set up signing for binpkgs, a signing keyring must reside (by default) at /root/.gnupg and a verification keyring must reside (by default) at /etc/portage/gnupg. The verification keyring must mark the signing key as trusted. Signing is toggled by FEATURES="binpkg-signing".

To sign already-created binpkgs, Portage's `gpkg-sign` tool can be used.

You can opt-in to this change early by setting `verify-signature = true` in /etc/portage/binrepos.conf/* for each binary repository configured, or under the special '[DEFAULT]' section.

Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location.

This does not apply if your binhost uses the old XPAK binary package format, but we encourage switching to BINPKG_FORMAT="gpkg" if that is the case.

[0] https://bugs.gentoo.org/945384 [1] https://bugs.gentoo.org/945385 [2] https://wiki.gentoo.org/wiki/Binary_package_guide#Binary_package_OpenPGP_signing