package: sbuild version: 0.91.6 severity: normal hi, the recent changes to apt-update prevents lintian starting, I set $apt_update = 0; but now --run-lintian fails with Install lintian build dependencies (apt-based resolver) ------------------------------------------------------------------------ Installing build dependencies Reading package lists... E:Building dependency tree... Reading state information... Unable to locate package sbuild-build-depends-lintian-dummy:amd64 apt-get failed. E: Package installation failed Not removing build depends: cloned chroot in use ---------------------------------------------------------------- sbuild commit 0a66217d works fine sbuild commit f0a66217d fails both are part of sbuild 0.91.6 (I expect running "sbuild hello --no-apt-update --run-lintian" would reproduce this, unless i am doing something else wrong, which is very possible!)
oops, apparently i failed to paste the commit ids: sbuild commit 0a66217d works fine sbuild commit 1652a2e019b5cd50537f0d77425637ce44c9be44 is the first that fails This commit does the following--- a/lib/Sbuild/ResolverBase.pm +++ b/lib/Sbuild/ResolverBase.pm @@ -692,6 +692,11 @@ sub update_archive { my $apt_update = shift; if ($apt_update) { + if (!$self->get_conf('APT_UPDATE')) { + print STDERR "I: skipping apt update as requested\n"; + return 1; + } +
The problem here is that by default, sbuild performs apt clean after the build. Which clears the lists. And with --no-apt-update, the lists becomes empty, so now apt does not find any package to install at all, because now it have to re-download the lists. When --no-apt-update paired with --no-apt-clean, things works as expected. It looks like --no-apt-update should imply --no-apt-clean. This way, everything works, again, as expected. I'm not sure why we need --apt-clean in the first place? Maybe get rid of it entirely? BTW, in man sbuild.conf, it is said that $APT_CLEAN defaults to 0. But it looks like it is on by default? Thanks, /mjt
Things doesn't. I think it worked once before, but not anymore, or maybe I tested the wrong combination. Either way, the prob here is that sbuild cleans up apt caches at some point which it shouldn't do, I think. Thanks, /mjt
Hi Michael, * Michael Tokarev <mjt@tls.msk.ru> [2026-09-01 11:29]: You can disable that with --no-apt-distclean Cheers Jochen
This still doesn't work (anymore). I dunno where it cleans up the
apt lists. Should be just one place, but it does not appear to
be run.
if ($self->get_conf('CLEAN_APT_CACHE')) {} in Build.pm
/mjt
I added debug stop right before sbuild installs lintian, to examine the chroot. The apt caches are intact, and I can install lintian. But I can't install sbuild-build-depends-lintian-dummy, which should be in some of these files (in /var/lib/apt/lists): _build_pkg_resolver-SMmL7r_apt%5farchive_._Packages _build_pkg_resolver-SMmL7r_apt%5farchive_._Release _build_pkg_resolver-SMmL7r_apt%5farchive_._Sources apparently these files are generated before installing actual package build dependencies, but not before installing lintian. So it looks like my very first guess was correct. /mjt
Ok, so I found the problem.
Commit 1652a2e019b5cd50537f0d77425637ce44c9be44 (which introduced this issue)
added check for --no-apt-update to ResolverBase.pm:update_archive().
However, there's a parameter $apt_update passed to that function already.
This function is only called from install_deps() method (overloaded for
different resolvers), which always passes this $apt_update from the upper
layer.
And there are just 3 callers of install_deps():
lib/Sbuild/Build.pm: if (!$resolver->install_deps(0, 'main', 'MAIN')) {
lib/Sbuild/Build.pm: $resolver->uninstall_deps();
lib/Sbuild/Build.pm: return 1 unless $resolver->install_deps(1, 'lintian', 'LINTIAN');
lib/Sbuild/Build.pm: if (!$resolver->install_deps(0, 'dose3', 'DOSE3')) {
lib/Sbuild/Build.pm: if (!$resolver->install_deps(0, 'fakeroot', 'FAKEROOT')) {
This is the first parameter - $apt_update.
As we can see, only one place - where we prepare for lintian -
alls install_deps() with apt_update being true.
Reverting 1652a2e019b5cd50 and making $apt_update=0 for lintian's
install_deps() makes everything working again -- provided we
don't clean apt caches, obviously.
But now, I don't see why we have this $apt_update parameter in the
first place - now it is always 0. I don't know what was its intended
usage.
It looks like the real fix would be
1. revert 1652a2e019b5cd50.
2. drop first parameter from install_deps() and remove quite some code
3. when --no-apt-update is given, always turn on --no-apt-distclean
(and mention this in the docs).
But since I don't understand the intention for $apt_update, I'm not
sure I should be doing #2.
Thanks,
/mjt
And this still does not work. Without that $apt_update=1 for the lintian deps run, it fails if --apt-distclean is given, which is the default is which is quite expected - since it clears the caches. Note also that --[no-]apt-distclean is not documented in the manpage, and it's a very recent addition. What was the intention when introducing this option in the first place? -- what's the problem if the available package lists will be kept during the build and later? To me, this --apt-distclean thing makes less and less sense, -- it looks like it should always be off. As I mentioned before, I don't see the logic behind all this. Thanks, /mjt
fwiw, me neither (but i think it doesnt hurt, as long as we can still run lintian), running apt clean might make more sense ie delete downloaded .deb files but leave apt able to download packages. fwiw, i think for a user there is a tension between
On 02.09.2026 15:35, Richard Lewis wrote: ... see https://bugs.debian.org/1089197 Also https://salsa.debian.org/debian/sbuild/-/merge_requests/252 Thanks, /mjt