Debug-info tools are broken on Omarchy stable: can we make debug packages available?

[flavorjones]

On the stable channel, glibc is pinned older than any build served by Arch's debuginfod, so glibc debug info is not available from anywhere and the tools that need it break.

The stable mirror currently serves glibc 2.43+r22 (its core.db is dated 29 Jun 2026), while live Arch core is already on 2.43+r37. Arch's debuginfod only keeps debug info for the current build and prunes the rest, so requesting the pinned r22 build receives a 404 response.

The result is that anything depending on glibc debug info suffers. gdb degrades quietly, since it treats debug info as optional. Valgrind fails outright, because it must redirect functions inside a stripped ld.so and aborts at startup when it can't find the symbols:

$ valgrind /bin/ls
valgrind: Fatal error at startup: a function redirection which is mandatory ...
valgrind: A must-be-redirected function whose name matches the pattern: memcmp
valgrind: in an object with soname matching: ld-linux-x86-64.so.2 ... was not found

Is there any way to stand up a debuginfod service for Omarchy that tracks the pinned snapshot, so these tools work reliably?

[flavorjones]

I had a side chat with David and I'll do some legwork to describe more completely what would be involved in running a debuginfod server. I need to understand Omarchy package management more deeply, but I'll come back with a more detailed suggestion.

[flavorjones]

OK, I dug into omarchy-mirror and omarchy-pkgs, and I think we can address this in two incremental steps:

1. Mirror Arch's -debug packages into the Omarchy mirrors and expose them as pacman repos, so that debug symbols always match the pinned snapshot.
2. Once that content is flowing, possibly implement debuginfod as a convenience on top of those packages.

Step one is enough to solve the problem in this discussion with a bit of effort. A user on stable will be able to run pacman -S glibc-debug and then valgrind and gdb will work offline.

Step two removes the manual part. gdb and valgrind will then be able to fetch individual symbol files over HTTP automatically, the way they do on rolling Arch today, but from a server that keeps symbols for the versions Omarchy actually pins.

The mirror side is a small change.¹ A few public tier 1 mirrors, including kernel.org, MIT, and Rackspace, already carry core-debug, extra-debug, multilib-debug, and pool/packages-debug in their public rsync modules. Omarchy's current upstream does not. Because the mirror sync is an unfiltered rsync of the whole tree, pointing the sync process at one of those mirrors as its source (or adding a second, filtered rsync) means edge, rc, and stable all pick up version-matched debug repos through the existing stage-and-publish flow, with no new scripts or timers. My rough calculation is that it will add about 105 GB² (or double that if the redundant pool copy syncs too, as it does today for regular packages).

The client side is three new repo sections in the pacman configs, [core-debug], [extra-debug], and [multilib-debug], plus a migration for existing installs. The order of operations matters: pacman fails hard on pacman -Sy when a configured repo returns a 404, so the config change can only ship after every channel's bucket serves the debug databases. Signing needs no changes since the debug packages are signed with the same archlinux-keyring keys that every Omarchy install already trusts.

Step one (packaging) is a prerequisite for step two (debuginfod). A debuginfod server indexes a directory of debug packages and serves files out of them over HTTP. The pool mirrored in step one is exactly the directory an omarchy-debuginfod would index, so step two is simply standing up a server in front of the existing packages³, then shipping an /etc/debuginfod/omarchy.urls file to enable it for every system.

Two smaller things came out of the research. The edge bucket still serves debug repo databases last modified 2025-09-01, left over from when the upstream was Rackspace, but the packages behind them have since been pruned, so those databases should really be cleaned up regardless. Also, package coverage may never be complete -- Arch publishes no kernel debug packages at all, and the chromium and electron debug packages seem to be effectively empty.

Footnotes

1. One tricky bit might be the chance of a race condition. The packages and their matching symbols have to be synced at the same time, and any lag between the two could introduce a version mismatch which will prevent the debugger from working properly. Upstream carries only the current version of each debug package, and the Arch archive skips them, so a missed capture can't be backfilled. We'll need to discover what kind of lag exists upstream before older versions are pruned to understand the risk here. ↩

2. core-debug (172 packages) is 1.96 GB compressed, extra-debug (7,540 packages) is 100.03 GB, and multilib-debug (235 packages) is 1.32 GB. ↩

3. Also, the debuginfod server is cheap to run! Arch's production service is a single daemon scanning its debug package pool on one host behind nginx. ↩