Hi Santiago,
On Thu, Nov 24, 2016 at 03:10:27PM +0100, Santiago Vila wrote:
> On Thu, Nov 24, 2016 at 02:37:46PM +0100, Andreas Tille wrote:
>
> > I do nit think that the issue can be explained by a missing
> > Build-Depends - otherwise it would fail in pbuilder as well IMHO.
>
> Not necessarily. sbuild and pbuilder are only "equivalent" if the chroots
> they use have the same packages installed.
>
> If you insist on using pbuilder, I would try to reduce the number of
> packages installed in the chroot as much as possible, there is no
> canonical chroot set in stone to be used by pbuilder, it uses whatever
> it was created by debootstrap when it was invoked for the first time.
> If you upgraded the chroot in the meantime, it may easily have some
> non-essential packages that may (and should) be removed.
OK, sounds convincing.
> But I would try using sbuild anyway, because that's the program used
> by official buildds. Setting up sbuild is quite straightforward really.
Ahem, I tried and ended up with
Unpacking sbuild-build-depends-core-dummy (0.invalid.0) ...
Setting up sbuild-build-depends-core-dummy (0.invalid.0) ...
W: No sandbox user '_apt' on the system, can not drop privileges
+------------------------------------------------------------------------------+
| Check architectures |
+------------------------------------------------------------------------------+
E: dsc: amd64 not in arch list or does not match any arch wildcards: all --
skipping
du: cannot access '/<<BUILDDIR>>/biojava4-live-4.1.0+dfsg': No such file or
directory
E: read_command failed to execute du
E: Cannot determine space needed for /<<BUILDDIR>>/biojava4-live-4.1.0+dfsg (du
failed)
+------------------------------------------------------------------------------+
| Cleanup |
+------------------------------------------------------------------------------+
Purging /<<BUILDDIR>>
Not cleaning session: cloned chroot in use
E: dsc: amd64 not in arch list or does not match any arch wildcards: all --
skipping
Sorry, I *really* can not spent any more time on this issue. I've spent
today way more than I should have done actually.
> If it still does not fail with sbuild in your machine, we can diff a
> failed build log and a successful build log to see how they differ.
I perfectly agree to your strategy - but not for today.
> Disabling the test would be the right thing to do but only as a last
> resort.
For the moment I'll go with this last resort (admitting that I'm not
really happy about it but it seems nobody else is able to care better).
Again thanks a lot for your hints and patience
Andreas.
--
http://fam-tille.de
