On Tue, Nov 29, 2016 at 09:56:08PM +0100, Paul Gevers wrote:
> Control: tags -1 help
>
> Hi Santiago,
>
> On 28-11-16 18:04, Santiago Vila wrote:
> > I tried to build this package in stretch with "dpkg-buildpackage -A"
> > (which is what the "Arch: all" autobuilder would do to build it)
>
> As a data point, I always upload source-only when allowed, the buildds
> have always build the all package in one go. So I am curious to learn
> what the difference is between your build daemons and the official ones.
There is not necessarily a difference. Packages break all the time
when any of their build-dependencies change behaviour slightly.
The official build daemons only build packages once, when they are uploaded,
and I build packages all the time.
So a successful build log of an upload made 44 days ago does not mean
the package has to build ok today.
There is also the random factor. Autobuilders build packages once.
When packages fail randomly, as in this case, nobody notices about
that if the autobuilders were lucky for that particular time.
But if a package only builds successfully with probability p < 1,
chances are that it will fail in my autobuilder some day.
> > If (after trying many times, as it's random) you could not reproduce
> > this using sbuild on a single CPU virtual machine (as I did), please do
> > not downgrade or mark as unreproducible, I would then consider giving
> > you access to a virtual machine on which I can reproduce it so that
> > you can as well. (In such case, please contact me off-list for details).
>
> Do you think it may help to disable parallelism?
Do you mean, for the purposes of reproducing the error, or for the
purposes of avoiding it? :-)
I have this in my .sbuildrc
$ENV{'DEB_BUILD_OPTIONS'} = 'parallel=1';
to disable parallelism. I do this because I'm interested to know the
time it takes to build a given package, so the figures I get are always
in the "same scale" regardless of having a multi-core machine or not.
So if you want to build the packages as closely as I do (to reproduce
the bug), I would try using a single CPU and disabling parallelism that way.
> Apart from that I have
> no idea what I could test. I already had a hard time to come up with the
> work around for /usr/bin/g-ir-scanner failing without an x-session (bug
> 839397)ยน. It seems introspection isn't very robust lately.
>
> My laptop has 2 CPU's but I've never used sbuild before.
Try sbuild. It's not difficult to setup if you follow the README.
Thanks.
