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.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
