On 5/24/24 11:46 AM, Sebastiaan Couwenberg wrote:
On 5/24/24 11:29 AM, Emilio Pozuelo Monfort wrote:
On 24/05/2024 11:02, Sebastiaan Couwenberg wrote:
On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote:
If that's the case, gdal should probably break older versions of
libgdal-grass so that that combination is not possible. That will
also make britney happy, otherwise it will block gdal due to the
test regression.
gdal, grass, and libgdal-grass just need to be tested together.
I'd rather drop the autopkgtest test than having to maintain the
Breaks in gdal.
*shrug*. If that's a runtime check, then there's an issue with the
dependencies/breaks, as one could have old libgdal-grass with newer
gdal (as is happening in the autopkgtest) and then libgdal-grass is
broken.
The dependencies of the rebuilt libgdal-grass correctly reflects the
required versions of gdal & grass.
If it's a check that's being done in libgdal-grass, then maybe that
check can be dropped?
That likely results in silent breakage. The situation is already better
since grass (8.2.0-3) which was patched to not include the build time in
the version check.
The autopkgtest was added to detect the breakage after grass was updated
in stable, but libgdal-grass wasn't rebuilt (#1022768).
With the information that autopkgtest has, the current situation is
broken and testing migration will be (rightly) blocked.
The autopkgtest just needs to use the affected packages from unstable
like we've done before.
I'd schedule these CI jobs myself, but britney ignores test results it
did not schedule itself.
gdal, grass, and libgdal-grass all get rebuilt during gdal transitions,
expecting libgdal-grass from testing to work with only gdal from
unstable is a broken assumption.
What are we going to do about the autopkgtest?
I've retried older jobs created by britney with gdal, grass, and
libgdal-grass from unstable which succeed, and also with only gdal and
libgdal-grass from unstable which likewise succeed as expected.
Jobs I've scheduled myself with gdal and libgdal-grass from unstable
fail because they don't actually use libgdal-grass from unstable as
requested.
Because autopkgtests are just a hindrance to testing migration dropping
the one from libgdal-grass makes sense. It doesn't resolve the blocked
testing migration however, because the new revision can't migrate
without the new gdal. We'd need an RC bug to get libgdal-grass
autoremoved from testing, make britney use the autopkgtest results which
succeed when using both gdal and libgdal-grass from unstable, or hint it
to ignore the autopkgtest failure.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
