On Thu, Jan 29, 2026 at 01:56:15PM +0000, Simon McVittie wrote: > I suspect this to be a regression in a related package (adduser, useradd or > something in that general ecosystem)
That's very likely. The reason I reported this initially against dbus-system-bus-common is that it's the same package which is failing all the time. > or a regression on the host system where you are doing the builds There is not a single "host system" where I'm doing the builds. The machines are virtual machines from AWS. I create a bunch of them when I have to build a lot of packages, and they are created from scratch from the official trixie images. No special customization of /etc/passwd is made to those machines, other than creating a user called buildd which is the one which calls sbuild. > I was unable to reproduce this with just > > $ podman run --rm -it debian:sid > # apt update && apt upgrade && apt install dbus-system-bus-common > > (which installs adduser), so there must be something in the build > environment that is causing a more complicated setup than just that. The > error message also suggests that the prior contents of /etc/passwd (on entry > to dbus' maintainer scripts) could be significant. Well, I can also reproduce the error in a directory-based chroot using schroot, doing this as root from a trixie machine: # schroot -c sid # apt-get update # apt-get build-dep gcp where "sid" is a directory-based chroot created with sbuild-createchroot. > From the build logs for the packages you marked as affected, am I correct to > think that you're using sbuild in its schroot mode (like older official > buildds), as opposed to unshare mode (like newer official buildds) or any > other backend? Yes, you guessed right. > schroot usually (configuration-dependent!) copies the /etc/passwd, > /etc/shadow and similar files from the host system into the container. Is > your schroot configured to do that? Apparently, yes. My build profile is based on the one called "sbuild", so /etc/schroot/sbuild/nssdatabases is being used. > What is the host system that these builds run on, and how/when was it > installed? (A cloud image perhaps?) Yes, virtual machines from the AWS cloud, using the images for trixie. > If the regression is being triggered by > /etc/passwd and friends being copied from the host into the chroot, then the > root cause might be a regression in the packages or configuration used on > the host, rather than in the packages inside the chroot. Well, that would be a problem indeed, because I am not aware that my trixie machines are "misconfigured" or anything like that. > What is the output of these on the host system? (run at least the last two > as root, e.g. via sudo) > > getent passwd messagebus > getent group messagebus > getent shadow messagebus > getent gshadow messagebus I get this from another system which is also a trixie VM from AWS: messagebus:x:996:996:System Message Bus:/nonexistent:/usr/sbin/nologin messagebus:x:996: messagebus:!*:20342:::::: messagebus:!*:: > For comparison, what I get on a desktop machine that was installed as trixie > is: > > messagebus:x:101:108::/nonexistent:/usr/sbin/nologin > messagebus:x:108: > messagebus:!:19814:::::: > messagebus:!:: Well, there are several differences here. It is a bug in trixie that those entries have a "*"? (My desktop system, which is running trixie as well, also has "*"). It is a bug in trixie that messagebugs user has a UID like 996? (My desktop system has 990). It is a bug in schroot at all that it copies some files via the nssdatabases mechanism? I agree there seems to be some kind of incompatility here, but I don't think that "this is a regression in the trixie images" is a good summary of the problem. This has worked flawlessly for many many years, and I'm inclined to think that the problem is in one of the packages currently in unstable. > Also, if you do a similar build but with the unshare backend instead of > schroot, does that alter the behaviour? Yes, building with the unshare backend works ok. > > Maybe this is related to this other bug in the shadow package: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124795 > > but I'm not really sure. > > It doesn't look closely related to any of the quoted errors at first glance, > but it could be a similar regression in useradd or adduser (stricter > validation or a user being created in a different state), perhaps. > > [...] > > If a build failure doesn't appear to have anything to do with nocheck, then > reporting it as "FTBFS with nocheck" without knowing whether nocheck is a > key factor seems likely to send maintainers off on a wrong track. Yes, sorry for that. When I reported this, nocheck was the difference, but only because I would not expect the schroot backend to fail in this completely unexpected way. You already retitled the bug and hopefully we are on the good track again. Thanks.
