Bug#859566: release.debian.org: please let postgis migrate to testing
Hi,
On Tue, Apr 04, 2017 at 11:06:37PM +0200, Markus Wanner wrote:
> a fix for postgis is currently not migrating to testing, even though it
> got unblocked. AFAIUI this is caused by missing builds on mips and mipsel.
>
> On those architectures, the dependent package sfcgal FTBFSs due to out
> of memory errors during compilation. Only sid is affected, though. The
> older version of sfcgal in stretch builds just fine even on mips{,el}.
>
> postgis-2.3.1+dfsg-1, i.e. the version just before the fix built fine on
> mips{,el}, so I'm fairly confident 2.3.1+dfsg-2 will build perfectly
> fine on stretch as well (where sfcgal is available even for those mipsen).
>
> Please help resolving that situation, thanks.
It looks like the issue is as follows:
First, there is a dak issue in unstable:
On some architectures in unstable, postgis has outdated versions. This is the
case for kfreebsd-* (2.2.2+dfsg-4) and hurd-i386 (2.3.1+dfsg-1). The binaries
for these versions on these architectures are still known in the archive. This
includes the arch-specific binaries (for kfreebsd and hurd) and the arch all
binaries.
On architectures where postgis builds fine (amd64, arm64, armel, armhf, i386,
mips64el, powerpc, ppc64el, s390x), the arch all binaries are those that are
built from the same source version. So there is no issue.
On architectures where there are no arch-specific binaries, because they were
removed (mips, mipsel), dak includes all the arch all binaries it has in the
archive. This includes the ones from the last version (2.3.1+dfsg-2), but also
those from 2.2.2+dfsg-4 and 2.3.1+dfsg-1 (and apparently there is also
postgresql-9.5-postgis-2.2-scripts version 2.2.2+dfsg-5, but I don't know
why).
So the Packages files for unstable on mips and mipsel have multiple versions
of packages like postgis-doc and postgresql-9.6-postgis-scripts. This also
isn't really in issue for britney, because she only uses the newest one.
For a package like postgresql-9.5-postgis-2.2, however, the packages files
only have outdated versions (2.2.2+dfsg-4 in this case), as the package is no
longer built from newer versions of the source.
Here comes a britney issue:
If a package has no arch-specific binaries on an architecture, but it has arch
all binaries on that architecture, and some of the are cruft (= from a
previous version), the 'ignore-cruft' logic doesn't work. The up-to-date ones
are not counted (line 1390 in britney.py), but the outdated ones are, so they
are seen as missing builds instead of cruft. The fix is probably to check for
cruft in both arch-all and arch-specific binaries separately for each
architecture.
On a related note: I'm not sure that a package which has up-to-date
arch-specific binaries on all arches but outdated arch all binaries is handled
correctly. We need testcases in the testsuite for that scenario and the one
described above.
So the real fix to allow postgis to migrate requires a britney fix (and maybe
also changes to dak). In the short run, however, there are 2 possible
workarounds:
- Ask for the removal of postgis on all the architectures in the archive where
it is outdated. This will probably get rid of the outdated binaries in the
archive, and so they will disappear from unstable on mips and mipsel as
well.
- Adding a force hint to make britney ignore the situation and try anyway.
Please hold of on both of these for a few days, to allow further investigation
of the britney issue.
Cheers,
Ivo
Reply to: