Just to followup on this abit. 6.0.2-1 was released, but we found a bug as the $pkgbase was not properly added to the /usr/src/debug/ portion of the string. We patched[1] this bug with 6.0.2-2 but it broke several debug packages, but it turns out this actually breaks packages built in sub-directories as we are ignoring some files. λ ~ » gdb /usr/bin/pacman [...] (gdb) list Downloading 0.04 MB source file /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c 1073 char *cl_text = arg_to_string(argc, argv); 1074 if(cl_text) { 1075 alpm_logaction(config->handle, PACMAN_CALLER_PREFIX, 1076 "Running '%s'\n", cl_text); 1077 free(cl_text); 1078 } 1079 } 1080 1081 /** Main function. 1082 * @param argc (gdb) info source Current source file is ../src/pacman/pacman.c Compilation directory is /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build In gdb we have this weird relative path going on: /usr/src/debug/pacman-6.0.1/pacman-6.0.1/build/../src/pacman/pacman.c Is in theory this absolute path /usr/src/debug/pacman-6.0.1/pacman-6.0.1/src/pacman/pacman.c But gdb explicitly checks for /usr/src/debug/pacman-6.0.1/build existing in the package, which means we need to retain the empty `/build` directory when we make the debug packages. Previous iterations of pacman just omits this, and other distributions has pre-defined build directories which works around this issue a bit. This issue is semi-unique to build systems where we are building in sub-directories (like meson), so things like Go and Rust is going to *probably* work without us patching this. This has been patched (properly this time) with some help from Allan, now we just create all the directories we see, empty or not, and it should hopefully work out :) I have yet to release a new package into testing as I have been travelling. But fetching 6.0.2-2 from the archive to test different ecosystem should still mostly work I think. [1]: https://gitlab.archlinux.org/pacman/pacman/-/commit/478af273dfe24ded197ec54a... -- Morten Linderud PGP: 9C02FF419FECBE16