Hi Bas,
On 22-11-2023 14:59, Sebastiaan Couwenberg wrote:
On 11/22/23 14:47, Paul Gevers wrote:
To prevent that manual labor, I can drop the autopkgtest from
libgdal-grass as it just hinders testing migration.
That's not a solution to the problem I'm trying to address, that will
just hide
On 11/22/23 14:47, Paul Gevers wrote:
I mean, in the ideal situation, this class of issues is prevented by
proper package relations, but I also want to avoid manual labor that's a
PITA to maintain and prone to wrong in the future.
To prevent that manual labor, I can drop the autopkgtest from
Hi,
On 20-11-2023 12:54, Adrian Bunk wrote:
It is a case where a binary tries to load the new soversion of the
library and plugins for the old soversion of the library.
And, do we (as project) already have established processes where this is
expressed correctly in package dependencies? Can
On Sun, Nov 19, 2023 at 09:34:40AM +0100, Paul Gevers wrote:
>...
> On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
>...
> > grass-core in testing depends on the old libgdal33, hence the need to
> > also get grass and libgdal-grass from unstable when running autopkgtest
> > with gdal from
On 11/19/23 09:34, Paul Gevers wrote:
On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
britney only schedules:
gdal/3.8.0+dfsg-1
src:gdal from unstable
Likely because there is no new version for the libgdal-grass source
package, only a binNMU.
Well, because there's no relation that
Hi,
On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
britney only schedules:
gdal/3.8.0+dfsg-1
src:gdal from unstable
Likely because there is no new version for the libgdal-grass source
package, only a binNMU.
Well, because there's no relation that tells britney this combination is
On 11/19/23 08:54, Paul Gevers wrote:
On 19-11-2023 07:32, Sebastiaan Couwenberg wrote:
For the libgdal-grass autopkgtest to pass it needs to pull gdal,
grass, and libgdal-grass from unstable due to the tight coupling.
If it doesn't happen automatically and there is a tight coupling, where
Hi
On 19-11-2023 07:32, Sebastiaan Couwenberg wrote:
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass,
and libgdal-grass from unstable due to the tight coupling.
If it doesn't happen automatically and there is a tight coupling, where
is the tight coupling missing in the
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass,
and libgdal-grass from unstable due to the tight coupling.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
cmake on mips64el will also need a higher priority to unblock the
rebuilds of several rdeps.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
grass is now also built & installed on all release architectures.
libgdal-grass & qgis can be rebuilt.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
On 11/17/23 07:45, Sebastian Ramacher wrote:
On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote:
For the Debian GIS team I'd like to transition to GDAL 3.8.0.
Please go ahead.
Thanks. gdal (3.8.0+dfsg-1) has been uploaded to unstable and is now
built and installed on all release
Control: tags -1 confirmed
On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: g...@packages.debian.org
> Control: affects -1 + src:gdal
> Control: forwarded -1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gdal
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
Control: block -1 by 1051433
For
14 matches
Mail list logo
