[Pkg-shadow-devel] Bug#1126595: dbus-system-bus-common: Many packages FTBFS with the nocheck build profile due to weird dbus/adduser error

[Santiago Vila]

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.