On 06/06/25 at 09:03 +0200, Jochen Sprickerhof wrote: > Hi Lucas, > > * Nilesh Patra <nil...@riseup.net> [2025-05-23 01:49]: > > > > > > On 23/05/25 01:01, Lucas Nussbaum wrote: > > > On 21/05/25 at 01:01 +0530, Nilesh Patra wrote: > > > > > Source: munge > > > > > Version: 0.5.16-1 > > > > > Severity: serious > > > > > Justification: FTBFS > > > > > > > > I am unable to repro this in a unstable chroot. Is this still failing > > > > for you? > > > > > > It is still failing. > > > > > > Are you using the unshare sbuild backend? > > > > Yes! My .sbuildrc has > > > > | # CHROOT_MODE > > | # Type: STRING > > | # Mechanism to use for chroot virtualisation. Possible value are > > "schroot" > > | # (default), "sudo", "autopkgtest" and "unshare". > > | # See also related command line options in sbuild(1): > > | # --chroot-mode > > | $chroot_mode = 'unshare'; > > > > And I can confirm from the logs that it uses the unshare chroot for build. > > > > | Unpacking /home/nilesh/.cache/sbuild/unstable-amd64.tar.zst to > > /tmp/tmp.sbuild.atFNI6Qiyx... > > | I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' > > with '<<CHROOT>>' > > | I: NOTICE: Log filtering will replace > > 'build/munge-BOXUql/resolver-ECypss' with '<<RESOLVERDIR>>' > > I can't reproduce this either. My best guess is that it depends on how you > create the chroot tarball. Can you try it with out supplying one (sbuild > will create one by itself then).
I gave it another try: - pre-built chroot, unshare mode, build running as user: still fails - pre-built chroot, unshare mode, build running as root: builds fine So its probably fine to downgrade this bug or trixie-ignore it Lucas
