Hi, 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 [0], 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 the future? 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. Regards Markus Wanner [0]: 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 intermittent.
Attachment:
signature.asc
Description: OpenPGP digital signature