Is seems that build fail on Broadcom boards,
and pass on cavium and loongson.
I will run build locally to confirm this theory.
From: Markus Wanner [mar...@bluegap.ch]
Sent: Monday, October 20, 2014 8:38 AM
Cc: Debian GIS Project
Subject: frequent buildd issues with postgis
the postgis package quite frequently fails to build on mips and/or
mipsel buildd boxes. That was the case for the last two uploads, both
blocking migration to testing.
The issue clearly is intermittent and I suspect it's memory related.
However, fact is that there's a clear pattern of which buildd boxes
could and which couldn't build the package is the past. Since 2.1.1-4
, the following boxes have constantly built postgis successfully:
eberlin (mipsel, 7x)
corelli (mips, 6x)
lucatelli (mips, 4x)
eysler (mipsel, 2x)
These constantly failed:
rem (mipsel, 4x)
mayer (mipsel, 2x)
ball (mips, 2x)
swarm (mips, 1x)
I didn't find a single machine that switched between successes and
failures, since that point in time.
I'm currently unable to find any information about these machines; like
how much memory each has (db.debian.org seems down). However, maybe you
can see a pattern right away?
If so, can you establish some kind of rule to make wanna-build chose
known-good buildd machines? So that builds are more likely to succeed in
And for now: Can you please trigger a rebuild of the latest postgis
revision on mipsel, so 2.1.4 can migrate to testing (before the freeze)?
Thanks in advance.
: We had portability issues in the past. Judging from other
architecture's successes or failures, postgis-2.1.1-4 seems to be the
first reasonably portable variant, where I suspect most failures to be
Pkg-grass-devel mailing list