On 11/06/25 at 21:36 +0200, Jochen Sprickerhof wrote:
> Hi Lucas,
>
> * Lucas Nussbaum <[email protected]> [2025-06-11 10:43]:
> > On 06/06/25 at 09:03 +0200, Jochen Sprickerhof wrote:
> > > Hi Lucas,
> > >
> > > * Nilesh Patra <[email protected]> [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
>
> I am pretty sure that's not the real reason, at least the package builds
> fine for me as a normal user. Can you write how you create the chroot or
> give me access to a system to try?
> Also, can you try with the automatic created chroot, as I wrote?
>
> I am pretty sure this bug is unrelated to the package.
Got it:
I configured /tmp as a bind mount in sbuild's config, with:
$unshare_bind_mounts = [ { directory => '/tmp', mountpoint => '/tmp' } ];
that breaks munge, because it wants /tmp to be either owned by root, or
by euid.
Because of the bind mount, /tmp is owned by nobody:nobody.
Removing the bind mount makes the build pass.
Lucas
