Control: tags -1 = forky sid ftbfs pending
On Thu, 29 Jan 2026 at 17:11:06 +0000, Simon McVittie wrote:
# apt update && apt upgrade
# apt install adduser
# adduser --system _bangstar
# echo '_bangstar:!*' | chpasswd -e
# adduser --system _bangstar
…
Actual result: on sid, the last `adduser --system _bangstar` (after
setting the password) fails with the same error message shown in the
subject line.
This appears to have been fixed in adduser git already, by commit
debian/3.154-13-gd5820ae "rework EXISTING_ and existing_user_status", so
the next adduser upload can presumably close this bug report.
For the FTBFS seen by Santiago as a result of this, it seems that the
problem scenario is:
1. install dbus-system-bus-common on a system that has
systemd-sysusers(8), so that the messagebus user is created by that;
2. remove systemd-sysusers(8) or copy /etc/shadow to a system that does
not have it;
3. install dbus-system-bus-common again, so that the messagebus user is
(re)created by adduser (which is meant to be idempotent, but this bug
makes it not idempotent in all cases)
For autobuilders, that can be avoided by using sbuild's unshare backend
in preference to its schroot backend, because it is the schroot backend
that copies /etc/shadow from the host system to the chroot.
Regarding Santiago's concerns about upgrades from one Debian release to
another, the only problematic scenario for dbus would be if
systemd-sysusers(8) was previously installed, but is subsequently
removed. This seems like it would be an unusual thing to do: bootable
systems (even with sysvinit) normally have udev, which has a hard
dependency on systemd-sysusers(8), and minimal chroots/containers
normally add packages as required but do not remove them (they might
install systemd-standalone-sysusers or systemd, but if they do, they
will most likely keep it installed).
If I switched dbus-system-bus-common to exclusively use
systemd-sysusers(8) and no longer have an adduser fallback (making it
more similar to for example udev, openssh-server, dhcpcd-base and
polkitd) then that would prevent this from affecting dbus. Given that
openssh-server now has this dependency, I think we're closer to
consensus on it being a normal thing to do than we were last time I
looked at this.
smcv
