Hi Bas, On 11/13/25 05:32, Sebastiaan Couwenberg wrote:
The libgdal-grass autopkgtest needs gdal, grass, and libgdal-grass from unstable to pass:https://ci.debian.net/packages/libg/libgdal-grass/testing/amd64/66167096/Please schedule the jobs with the britney credentials to make it use those results.
I think I'm missing some detail here. I'm fully aware that the testing situation with transitions isn't ideal because normally in smooth transitions with co-installable libraries we're actually not testing the rebuilt binaries from unstable, but the old binaries in testing. In this case there seems to be something going on additionally, which isn't captured in package relations. libgdal-grass in testing is built against the old library of gdal (libgdal37), which is also installed in the testbed. So why would libgdal-grass complain? Is this the problem that during a transition within one stack both the new and old library are loaded and we're having a conflict that way and libgdal-grass is intelligent enough to prevent that? But as I see it there's only one library involved here, so where does that come from, the plugins?
The following packages come from unstable in the test: gdal-data gdal-plugins libgdal38 python3-gdal gdal-bin libgdal37 PaulPS: libgdal37 is a rebuild in unstable that didn't migrate before the gdal transition.
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature