Gentoo Packages

You currently have Valve's Steam client installed with its runtime disabled. Disabling the runtime traditionally told Steam to use libraries from the host instead. This has never been supported by Valve, and it is no longer very effective. It has already long been the case that the client will use host libraries anyway, only falling back to the runtime when a host library a missing. Almost all games, even very old native ones, are now run in a container by default, where it is not possible to disable the runtime.

As such, steam-overlay is now shifting to a supported setup by forcibly enabling the `steamruntime` USE flag. The intention is to keep the USE flag and the associated esteam package around for 2 months until 2026-12-04. With these gone, most of the steam-overlay packages will be largely redundant, so the steam-launcher and extest packages will migrate to the main Gentoo repository, and the overlay will be retired.

If you used esteam to remove bundled libraries from some games, then you may need to restore those libraries for each game by navigating to Properties -> Installed Files -> Verify integrity of game files.

If you want to run some games directly on the host with host libraries preferred, you can still do so by selecting Legacy Steam Runtime under Properties -> Compatibility, but it is your responsibility to install those libraries.

Do not assume that the older Steam runtimes used by older games only have ancient versions of libraries. Obviously, compatibility needs to be maintained, as that is the point of the runtime, but while writing this, I found that the "Scout" runtime had the same version of libSDL2 as Gentoo and a newer version of libSDL1.2 than Gentoo.

It is worth bearing in mind that, despite the success of the Steam Deck, relatively few games are Linux native. New native games tend to be built on large engines like Unity or Unreal, and if these do use traditional free software libraries at all, they are statically linked.

Many older native games have been left to rot while their Windows counterparts have continued to receive updates, making Proton the more sensible choice in these cases. With Wine and Proton now being able to run 32-bit binaries on a purely 64-bit Linux system, you may decide to drop 32-bit support from your system entirely once the 64-bit Steam client goes out of testing, which will hopefully be soon.

If Steam no longer meets your needs, you may want to consider Lutris instead, but it has broadly the same options, such as using host libraries, its own runtime, or Steam's "Sniper" runtime in a container. It does nothing to ensure you have the right host libraries installed.

Please give any feedback at: https://github.com/anyc/steam-overlay/issues/386

The LocalAI packages of this overlay have been renamed and recategorized. Package moves migrate installed systems and world entries automatically:

sci-ml/local-ai            -> sci-ml/localai
app-local-ai/backends-meta -> www-apps/localai-server
app-local-ai/<backend>     -> localai-backend/<backend>

The two top-level names also swap roles. sci-ml/localai - the atom your world file now holds - is a meta package: it installs the server (www-apps/localai-server) plus the inference backends selected by its USE flags, which all default to on. The server package itself no longer references any backend package. Removing sci-ml/localai from the world file lets emerge --depclean remove the server and every backend in one sweep.

If you run a full LocalAI stack, no action is needed: the next world update follows the moves and keeps everything installed.

If you run the server WITHOUT backends, pick one before your next world update:

• keep sci-ml/localai in world and disable its backend flags, e.g. echo "sci-ml/localai -*" >> /etc/portage/package.use/localai

• or anchor the server directly: emerge --deselect sci-ml/localai emerge --noreplace www-apps/localai-server

Otherwise the meta package's default USE flags will schedule every backend for installation.

If the update aborts with file collisions on the server's files (/usr/bin/local-ai and the service files), unmerge the old server install - it carries the meta's new name in the package database - while keeping the world entry, then run the update again:

emerge -C --deselect=n sci-ml/localai
emerge -uDN @world

This is safe: the update reinstalls the server and the backends immediately, and /var/lib/local-ai (models, state) is untouched.

Until now app-editors/zed in this overlay was a daily snapshot of Zed's main branch carrying the bentoo patch series: the Claude agent integrations (USE claude-agent-acp-plus, claude-agent-acp-tui, claude-code-ide) and the agent-panel changes that ride on them.

That package is split in two:

• app-editors/zed builds upstream's tagged releases from source, with no patches -- the source counterpart of app-editors/zed-bin. Stable versions (1.22.0) and pre-releases (1.23.1_pre) are both offered.
• app-editors/zeo is the snapshot plus the patch series, as it was, with Zed's identity replaced by Zeo's: the command is "zeo", settings live in ~/.config/zeo/, and it opens zeo:// links (zed:// still works). app-editors/zeo-bin is the same build, prebuilt for x86-64-v3 CPUs (Haswell, Zen 1 and newer).

Only one of zed, zed-bin, zeo and zeo-bin can be installed at a time.



Keeping the patched editor ==========================

1) Switch packages. Portage resolves the blocker by unmerging zed:

     emerge --ask app-editors/zeo      # or app-editors/zeo-bin
     emerge --ask --deselect app-editors/zed

2) Move per-package configuration from app-editors/zed to

 app-editors/zeo in /etc/portage (package.use, package.env,
 package.accept_keywords).

3) Copy your settings once, if ~/.config/zeo does not exist yet (this

 overwrites it). Zeo does not read Zed's directories:

     cp -a ~/.config/zed/. ~/.config/zeo/
     cp -a ~/.local/share/zed/. ~/.local/share/zeo/

Staying on plain Zed ====================

The installed snapshot (1.24.0_pre20261001) is numbered above the newest release, so the next world update shows a DOWNGRADE of app-editors/zed to a release. That is expected. The USE flags claude-agent-acp-plus, claude-agent-acp-tui and claude-code-ide no longer exist on zed; drop them from package.use.

Ceph 20.2.4 (Tentacle) is a hotfix release addressing four CVEs [1]. The fix for CVE-2025-30156 introduces a new CephX key type, aes256k, and cluster operators must rotate and client keys by hand as part of the upgrade.

Read the upstream announcement [1] and the CephX key upgrade procedure [2] BEFORE you start. If you deploy Ceph use cephadm or Rook you can skip key rotation instructions and only check client support.

The CVEs fixed in this release are:

CVE-2025-30156  Authentication bypass in CephX caused by misuse
                of AES-CBC.
CVE-2026-39944  Improper verification of a cryptographic
                signature in the RGW STS session tokens.
CVE-2026-50152  Improper authorization in the Ceph Monitor
                subscription handler.
CVE-2026-54330  Improper SigV4 signature verification in RGW.

Manual steps required =====================

1. If you run RGW multisite, set "rgw_sigv4_insecure" to true on

 every cluster BEFORE you begin.  The multisite REST client would
 fall back into old insecure behaviour and would emit SigV4
 requests that the fixed verifier rejects.
 After ALL clusters upgrade, set this option back to false.

2. Upgrade the daemons in the usual Ceph order: mon's, then

 mgr's, then OSDs, then MDSs, then the gateways and clients.

3. Expect six new health warnings and errors about insecure CephX

 keys after the upgrade [3].  This is normal; they clear as you
 work through the rotation.

4. Rotate the keys of all daemons and clients to aes256k, following

 the instructions [2].

5. Kernel clients (kernel CephFS and krbd) only support aes256k

 starting with Linux 7.0.  Check your kernel version before you
 rotate any key that a kernel client uses, or that client will
 lose access to the cluster.

6. Secrets kept in the mon config-key store may have been

 exposed through CVE-2026-50152.  Upstream guidance on rotating
 them is still pending; assess your own exposure and rotate what
 you can in the meantime.

A cluster left with old keys stays vulnerable to the authentication bypass, so do not stop halfway through the rotation.

[1] https://ceph.io/en/news/blog/2026/v20-2-4-v19-2-6-combo-released/ [2] https://docs.ceph.com/en/latest/rados/configuration/auth-config-ref/index.html#upgrading-and-rotating-cephx-keys [3] https://docs.ceph.com/en/latest/rados/operations/health-checks/index.html#auth-insecure-keys-creatable

The packages dev-util/codex and dev-util/codex-bin have been added to the official guru repository. They have been removed from this overlay to avoid collisions. Please make sure you have the guru overlay enabled to continue receiving updates for these packages.

Starting with dev-lang/flutter-bin-3.47.0-r1, the package-managed Flutter SDK under /opt/flutter is treated as immutable. Flutter's writable runtime cache is seeded into each user's cache directory instead of modifying /opt/flutter at runtime.

By default, the Flutter binary/artifact cache is stored under:

${XDG_CACHE_HOME:-$HOME/.cache}/flutter/<version>/bin-cache

and the pub cache is stored under:

${XDG_CACHE_HOME:-$HOME/.cache}/flutter/pub-cache

The initial run may therefore copy a substantial amount of data into the user's cache and temporarily increase disk usage. Multiple users will have separate writable caches.

Users and service environments may override these locations explicitly with FLUTTER_CACHE_DIR and PUB_CACHE. When both are set, the launcher does not require HOME or XDG_CACHE_HOME.

Old per-version Flutter cache directories may be removed manually when they are no longer needed. They will be recreated from the installed SDK if required.

The `dev-util/antigravity-bin` and `dev-util/antigravity-cli-bin` packages have been removed from this overlay because equivalent packages, `dev-util/google-antigravity`, `dev-util/google-antigravity-cli`, and `dev-util/google-antigravity-ide` are now available in the GURU repository.

Please migrate your installation to the GURU packages:

emerge --deselect dev-util/antigravity-bin dev-util/antigravity-cli-bin emerge --ask dev-util/google-antigravity dev-util/google-antigravity-cli dev-util/google-antigravity-ide emerge --depclean dev-util/antigravity-bin dev-util/antigravity-cli-bin

I am migrating RustDesk, Caprine, LocalSend, and Picocrypt from ebuild to flatpak installed version and as a result will no longer be updating ebuilds for them. The list of affected applications being removed from this overlay:

• RustDesk
• Caprine
• LocalSend
• Picocrypt

These applications have valid flatpaks in the main flatpak repo (Flathub). You can search for flatpaks using `flatpak search <name>`. Example installation commands: flatpak install flathub com.rustdesk.RustDesk flatpak install flathub com.sindresorhus.Caprine flatpak install flathub org.localsend.localsend_app flatpak install flathub io.github.picocrypt.Picocrypt

If you'd like to continue using ebuilds, you can take the workflows and config from the git history of this overlay and put them in your own overlay to continue support. Alternatively, you can log an issue on the arrans_overlay repo for assistance or requests.

As most Asahi users will be aware, m1n1 now requires Rust. More specifically, it requires the aarch64-none-softfloat target. While it is possible to build core and alloc by passing a flag to m1n1's Makefile, core and alloc have versioned dependencies which change with each minor Rust version. As such, it is logistically impossible to do this within the confines of Gentoo's Rust packaging infrastructure, which requires us to pin specific crate versions in the dependent package's ebuild.

As a user, you have two options: 1. Set RUST_CROSS_TARGETS appropriately

  If you are using dev-lang/rust, you have the option of building
  std for an arbitrary set of target triples. Create the file
  /etc/portage/env/dev-lang/rust with the contents:
      I_KNOW_WHAT_I_AM_DOING_CROSS=yes
      RUST_CROSS_TARGETS=(
              "AArch64:aarch64-unknown-none-softfloat:aarch64-unknown-linux-gnu"
      )
  and rebuild dev-lang/rust. You should now be able to build sys-boot/m1n1
  just as before.

2. Use the new sys-boot/m1n1-bin package

  If you do not wish to use dev-lang/rust, we now have sys-boot/m1n1-bin,
  which is a drop-in replacement for sys-boot/m1n1. Unmerge sys-boot/m1n1
  and then emerge sys-boot/m1n1-bin. The binary is built from each GitHub
  tag on GitHub CI runners. You may inspect the build pipeline in the m1n1
  repository.

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.

I am migrating a couple of apps from ebuilds to flatpak installed version and as a result will no longer be updating ebuilds for them. The list of affected applications being removed from this overlay:

• Anytype
• Ente Auth
• ImHex

These applications have valid flatpaks in the main flatpak repo (Flathub). You can search for flatpaks using `flatpak search <name>`. Example installation commands: flatpak install flathub io.anytype.anytype flatpak install flathub io.ente.auth flatpak install flathub net.werwolv.ImHex

If you'd like to continue using ebuilds, you can take the workflows and config from the git history of this overlay and put them in your own overlay to continue support. Alternatively, you can log an issue on the arrans_overlay repo for assistance or requests.

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