Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
Hi, Quoting Vagrant Cascadian (2023-02-03 00:18:58) > On 2023-02-01, Jérôme Charaoui wrote: > > I don't know how common that is in build environments, but it's not > > something that I have or think I should have in my build (sbuild) or > > test (autopkgtest) environments. > > I was able to reproduce the issue with sbuild. > > This appears to be because sbuild copies the host's /etc/passwd and > /etc/group into the chroot when it builds... and presumably the buildd > environment does this as well (and all DSA machines have the puppet user > available?)... and so the puppet user is in fact available in those cases, > but not others... > > I was able to workaround the issue with: > > sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password > puppet' ... > > Is there an option in sbuild to not copy the passwd/group information into > the chroot? What are the implications of that? I think we are not so much talking about a limitation of sbuild but about a limitation of the sbuild schroot backend. When above you say that sbuild copies /etc/passwd and /etc/group into the chroot, what you probably mean is that sbuild-createchroot appends the output of `getent passwd sbuild` and `getent group sbuild` to /etc/passwd and /etc/group, respectively? It would be news to me if sbuild at any point copies all of /etc/passwd or /etc/group into the chroot at any point. Do you see this somewhere happening in the code? Remember that the sbuild-createchroot utility is only really useful if you use the sbuild schroot backend (which is also the default backend and also the backend that is used on the buildds). Since you are asking whether passwd/group information can somehow not be copied into the chroot, you probably are not interested in a change in the buildd infrastructure but just a local change? In that case, maybe consider not using the schroot backend but the unshare backend. The latter has the advantage that you do not need any special setup of the chroot at all. Any chroot tarball that contains apt can be used by the unshare backend. Quick introduction (assuming you are on amd64): $ mkdir -p ~/.cache/sbuild $ mmdebstrap --variant=buildd unstable ~/.cache/sbuild/unstable-amd64.tar.xz $ sbuild --chroot-mode=unshare ... Note that in contrast to the schroot backend, you do not need to become the superuser at any point. Thanks! cheers, josch
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
On 2023-02-02, Vagrant Cascadian wrote: > On 2023-02-01, Jérôme Charaoui wrote: >> Perhaps an alternative would be to add "puppet-agent" as a build >> dependency, because that package will create a "puppet" user in the >> environment. And for completeness, this also worked for me: sbuild --add-depends puppet-agent ... live well, vagrant signature.asc Description: PGP signature
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
On 2023-02-01, Jérôme Charaoui wrote: > I don't know how common that is in build environments, but it's not > something that I have or think I should have in my build (sbuild) or > test (autopkgtest) environments. I was able to reproduce the issue with sbuild. This appears to be because sbuild copies the host's /etc/passwd and /etc/group into the chroot when it builds... and presumably the buildd environment does this as well (and all DSA machines have the puppet user available?)... and so the puppet user is in fact available in those cases, but not others... I was able to workaround the issue with: sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password puppet' ... Is there an option in sbuild to not copy the passwd/group information into the chroot? What are the implications of that? > Is there some flag we could use to tell reproducible-builds to build > this package as a regular user instead of root? It typically builds as two different users, pbuilder1 and pbuilder2, not as root. > If not I might have to patch the test suite to work around some of the > logic in there, which I'm not too excited about. > > Perhaps an alternative would be to add "puppet-agent" as a build > dependency, because that package will create a "puppet" user in the > environment. That seems like a viable option, though obviously a bit ugly if that package does a bunch of other things or has many other dependencies. Would it make sense to have a package that just creates a user and nothing else? live well, vagrant signature.asc Description: PGP signature
Bug#1030256: [Pkg-puppet-devel] Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
I think this is occurring because the test is being run as "root". I don't know how common that is in build environments, but it's not something that I have or think I should have in my build (sbuild) or test (autopkgtest) environments. Is there some flag we could use to tell reproducible-builds to build this package as a regular user instead of root? If not I might have to patch the test suite to work around some of the logic in there, which I'm not too excited about. Perhaps an alternative would be to add "puppet-agent" as a build dependency, because that package will create a "puppet" user in the environment. Thanks, -- Jérôme
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
Source: ruby-puppetserver-ca-cli Version: 2.4.0-1 Severity: serious Tag: ftbfs Dear Maintainer, ruby-puppetserver-ca-cli currently fails to build from source with test failures. Example: 1) Puppetserver::Ca::Action::Enable infracrl does not print the help output if called correctly Failure/Error: FileUtils.chown(@user, @group, path) ArgumentError: can't find user for puppet # ./lib/puppetserver/ca/utils/file_system.rb:96:in `write_file' # ./lib/puppetserver/ca/utils/file_system.rb:23:in `write_file' # ./lib/puppetserver/ca/action/enable.rb:109:in `create_infra_crl_chain' # ./lib/puppetserver/ca/action/enable.rb:75:in `enable_infra_crl' # ./lib/puppetserver/ca/action/enable.rb:53:in `run' # ./spec/puppetserver/ca/action/enable_spec.rb:34:in `block (5 levels) in ' # ./spec/utils/ssl.rb:248:in `with_ca_in' # ./spec/puppetserver/ca/action/enable_spec.rb:28:in `block (4 levels) in ' # ./spec/puppetserver/ca/action/enable_spec.rb:27:in `block (3 levels) in ' For more details see the log from reproducible builds https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-puppetserver-ca-cli.html (I have also verified the issue with pbuilder on my local Sid system) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/3 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- mvh / best regards Hans Joachim Desserud http://desserud.org
