Fails with a lot of errors for Debian chroots, but it works perfectly fine with Ubuntu ones. Not sure what's going wrong here. I think this has been going on for months, but I often forget about it because I don't do much binary building anymore (mostly just letting CI pass & upload source these days). Attached is a complete log from a Debian chroot and the head of a build in an ubuntu chroot +------------------------------------------------------------------------------+ | Install build-essential | +------------------------------------------------------------------------------+ Setup apt archive ----------------- Merged Build-Depends: build-essential, fakeroot Filtered Build-Depends: build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-core-dummy' in '/<<BUILDDIR>>/resolver-jU5m8u/apt_archive/sbuild-build-depends-core-dummy.deb'. dpkg-deb: error: failed to make temporary file (control member): No such file or directory Dummy package creation failed E: Setting up apt archive failed/usr/bin/du: cannot access '/<<PKGBUILDDIR>>': No such file or directory E: read_command failed to execute du E: Cannot determine space needed for /<<PKGBUILDDIR>> (du failed) Setup apt archive ----------------- Merged Build-Depends: dose-distcheck Filtered Build-Depends: dose-distcheck dpkg-deb: building package 'sbuild-build-depends-dose3-dummy' in '/<<BUILDDIR>>/resolver-jU5m8u/apt_archive/sbuild-build-depends-dose3-dummy.deb'. dpkg-deb: error: failed to make temporary file (control member): No such file or directory Dummy package creation failed E: Setting up apt archive failedE: Failed to explain bd-uninstallable
It's libpam-tmpdir that's breaking this somehow - no idea how, but removing libpam-tmpdir from my system allows it to work again.
Hi, I tried to reproduce the problem. After having installed libpam-tmpdir I get the same errors as you do, so success! But now I wonder how to fix the problem. It seems that the package sets $TMP and $TMPDIR to /tmp/user/1000 for me. I guess the last bit is my user id. But then it fails to create that last component of that directory. This is why dpkg-deb in your log is unable to create a temporary directory. The path that $TMP and $TMPDIR are set to simply doesn't exist. At least on my system. Can you confirm that observation? Thanks! cheers, josch
I recently started seeing this behavior as well, however I don't have libpam-tmpdir installed. I have neither $TMP nor $TMPDIR set in my environment. Attached is a debug build log, in case it's of any use. Cheers,
I tried removing "libpam-tmpdir" and it works. Thanks Best Regards, Nivas Baskaran
Control: reassign -1 libpam-tmpdir I've seen this behaviour in a non-sbuild context too, thus I'm reassigning this bug to libpam-tmpdir. If it interferes with TMP/TMPDIR, it ought to make sure the target exists, and does not pollute any chroot builds etc. Chris
Can you describe exactly what you have seen and steps to reproduce? Does sbuild either clean up TMP and TMPDIR, or make sure those exist when chroot-ing? Otherwise, those directories naturally won't exist inside the chroot, and there's nothing a PAM module that runs at the session start can do about that. I suspect this is an sbuild bug, but I'm not familiar with the internals of it, so it might be somewhere else. Whatever you're seeing I suspect is something else.
https://github.com/grml/grml-debootstrap/issues/232 Well, maybe all tools need to be prepared that TMP/TMPDIR point to something that will not exist and thus need to filter them out immediately. If that is true, then please feel free to reassign to sbuild. Chris
reassign 856434 sbuild thanks ]] Chris Hofstaedtler Thank you. It's a very similar context – chroot-ing and needing to take action for TMP to be valid. Something calling chroot and running commands has to do one of: - unset TMP and TMPDIR (so things fall back to /tmp, which hopefully exists). - ensure TMP and TMPDIR exists in the chroot. - ensure libpam-tmpdir is installed and configured in the chroot, and open a new PAM session there when chroot-ing (so the PAM session hooks run). (This will ensure that TMP/TMPDIR is set appropriately and exists.) Otherwise, TMP/TMPDIR might not exist, and tools generally rely on that existing and being read- and writeable. I have no opinion on which one of those is right for sbuild. I'll reassign the bug back to sbuild, since it sounds like the adjustment needs to happen there. Happy to help or advise further if that's helpful, please cc me in that case. Cheers,