Gentoo Packages

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

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