two -debug packages fighting over a build-id file

k4lizen · 2026-09-27 21:13:38

maybe consider disabling them by default https://wiki.archlinux.org/title/Makepk … es_and_LTO

Skim the thread a bit

There's a bunch of these btw:

Go packages are especially funky because it seems that go strips the gnu buildid and puts its own, but the file-system path is based on the stripped buildid so
lots of unrelated binaries cause conflicts.

seth · 2026-09-27 21:39:59

You'll run into something like that everytime specific builds of libraries get bundled w/ <bloat> (electron, go, …) because the build/debug id is a hash of the binary.
If the same binary gets bundled w/ severaly <bloat> builds (invariant against changes of the system library sane software uses) you'll run into an unresolvable conflict (the concerned files are symlinks to library and debug data, but the name is derived from a hash)

I have no idea what the idea behind that repo is and would simply advice to use debug packages only when actually required resp. prefer debuginfod.
If the bug doesn't exist in the latest version it's moot from a users perspective anyway (caveat being hard to reproduce bugs and then you randomly run into one and can no longer get the debuginfod because you've not updated this year…)
Maybe it's meant as exclusively arch-dev team shared resource.

As far as "official" goes, they're not archived in https://archive.archlinux.org/repos/last/ and not provided by almost any mirror - the only thing "official" there are the signature files

k4lizen · 2026-09-27 22:43:46

I see where you're coming from, but I'd like to ping the person who handles / has set up the -debug repos, do you know how I could contact them?

seth · Yesterday 06:18:30

https://lists.archlinux.org/archives/li … K7EFT7J2K/

DevOps - the wiki is (ofcourse) correct about that.
https://mirrors.edge.kernel.org/archlinux/ also has those repos

There's also https://bbs.archlinux.org/viewtopic.php?id=303960
Since the debug stuff isn't particularly large I'd keep a local mirror (formal or informal for pacman -U) of those repos - I don't see how this can be fully conflict-free w/o breaking debuginfod compatibility.

Lone_Wolf · Yesterday 09:36:12

Debuginfod often doesn't have the exact version of the debug packages for archlinux official repo-packages that are needed by gdb and other debuggers .

No idea how it works, but if those debug repos are enabled in pacman.conf gdb / debuginfod can install the needed debug packages from those repos on demand and remove them after.

Without those repos there is a big chance the backtrace will lack the info needed to troubleshoot. Since crashes are sometime hard to reproduce getting useful info in the backtrace helps a lot, especially when the crash is in a 3rd party project.

I've had those repos enabled for years now without issues .

$ pacman -Ss debug | wc -l
16126
$ pacman -Qs debug
local/debugedit 5.3-2
    Tool to mangle source locations in .debug files
local/debuginfod 0.196-1
    Handle ELF object files and DWARF debugging information (debuginfod)
local/elfutils 0.196-1
    Handle ELF object files and DWARF debugging information (utilities)
local/gdb 17.2-1
    The GNU Debugger
local/gdb-common 17.2-1
    The GNU Debugger
local/libelf 0.196-1
    Handle ELF object files and DWARF debugging information (libraries)
local/oolite-debug-console-bin 2.14.205-0.1
    Debug console for Oolite.
local/python-pyelftools 0.33-1
    Python library for analyzing ELF files and DWARF debugging information
local/strace 7.2-1
    A diagnostic, debugging and instructional userspace tracer
$

EDIT :
a local mirror of the debug repos will need to be updated atleast every time pacman -Syu installs a newer version of something .

Last edited by Lone_Wolf (Yesterday 10:07:39)

k4lizen · Yesterday 11:19:08

I'm 99% sure that what you observed was incidental. If you have the repos enabled but don't explicitly download from them (as you haven't, judging
from your command output), it has no effect. GDB does not read pacman.conf etc.

seth · Yesterday 13:13:34

Just adding the repos does nothing - and the lonesome puppy does not seem to have any -debug packages installed

gdb will use https://wiki.archlinux.org/title/Debuginfod - the servers do only provide the files for the most recent package(s) so it's true that you can fail to obtain them if you've not updated in a while but
1. the mirror doesn't provide any older packages either (and they're not in the ALA)
2. I doubt that anything will temporarily install packages to run a debug for an unprivileged user.
(I suppose you could set that up but would be baffled if that was somehow the case by default)

You do NOT need to add those repos to use debuginfod in general.

Lone_Wolf · Today 10:25:32

I didn't need older versions , but the exact installed versions of archlinux repo packages which were not present on the debuginfod server.

I agree gdb/debuginfod are unliklely to install packages but the debug symbols are stored in tarballs that can be extracted by any user.
Maybe debuginfod on archlinux can fallback to downloading -debug packages and extract them ?

Arch Linux

#26 2026-09-27 21:13:38

Re: two -debug packages fighting over a build-id file

#27 2026-09-27 21:39:59

Re: two -debug packages fighting over a build-id file

#28 2026-09-27 22:43:46

Re: two -debug packages fighting over a build-id file

#29 Yesterday 06:18:30

Re: two -debug packages fighting over a build-id file

#30 Yesterday 09:36:12

Re: two -debug packages fighting over a build-id file

#31 Yesterday 11:19:08

Re: two -debug packages fighting over a build-id file

#32 Yesterday 13:13:34

Re: two -debug packages fighting over a build-id file

#33 Today 10:25:32

Re: two -debug packages fighting over a build-id file

Board footer