Bug#549407: [buildd-tools-devel] Bug#549407: ivtools 1.2.6-1 FTBFS on sparc and powerpc
reassign 549407 buildd.debian.org,ivtools
2009/11/6 Roger Leigh <email@example.com>:
> On Fri, Nov 06, 2009 at 04:20:31PM +0100, Agustin Martin wrote:
>> I am looking at #549407 and noticed that both powerpc and sparc autobuilders
>> seem to use two temporary dirs at the same time,
> I think those buildds may be missing the binNMU versioning fix
> in commit 817aea8c, but I don't have access to check that.
Thanks for the hint. May that be the origin for #549407?
I have looked at all the ivtools logs and everything points to powerpc
(praetorious) and sparc
(lebrun) autobuilders having something different to all the other
similar autobuilders where
ivtools has been processed.
Build *suceeds* in amd64 (sbuild/amd64 98 on nautilus), ia64
(sbuild/ia64 98 on caballero),
mips (sbuild/mips 99.99 on ball), having what seems to be an old sbuild.
Build *suceeds* in alpha (sbuild 0.58.2 (15 Jun 2009) on goetzs),
armel (sbuild 0.58.2 (15 Jun
2009) on argento), mipsel ( sbuild 0.58.2 (15 Jun 2009) on rem), s390
(sbuild 0.58.2 (31 Jul 2009)
on debian-31), having the new sbuild.
Build *fails* in powerpc (sbuild 0.58.2 (15 Jun 2009) on praetorius),
sparc (sbuild 0.58.2 (15 Jun
2009) on lebrun), all having the new sbuild.
Is only in this last two autobuilders where I see two different
temporaty directories being used
buildd-ivtools_1.2.6-1+nmu2-1-6yM9Gd != buildd-ivtools_1.2.6-1+nmu2-sparc-6yM9G
In all of alpha, armel, mipsel and s390 autobuilders, where build
suceeds, no such behavior is
found and a single temporary dir is used consistently during all the build.
SInce there is something strange in powerpc and sparc autobuilders
that may be related to #549407
I am reassigning this bug report to both buildd.debian.org and
ivtools. If this is finally not related to
the autobuilders, please reassign it back to ivtools alone.
I have a new upload ready just to remove the -j1 stuff I added in
previous upload. I was convinced at
that time that this was a race condition where -j1 may help. Since
this seems not true, better leave
the package wihout the -j1, so changes are kept minimal and parallel
processing can be attempted.
I however will not upload this shortly. Will wait before for buildd
Thanks for your help,