Bug#931950: transition: libgeotiff

2019-09-15 Thread Adam D. Barratt
On Sun, 2019-09-15 at 08:27 +0200, Sebastiaan Couwenberg wrote:
> On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> > libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1)
> > cannot
> > be removed from testing due to gnudatalanguage, which I don't
> > understand. But this should be resolved when the package get
> > autoremoved
> > on the 14th.
> 
> gnudatalanguage was not removed yesterday, it's still marked for
> removal on 14 September.

It was removed in the 10:00 run on the 15th, which was the first run
after it was in the auto-removals hint list. You just need a little
more patience.

> Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
> testing,

Not any longer.

Regards,

Adam



Bug#931950: transition: libgeotiff

2019-09-15 Thread Sebastiaan Couwenberg
On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
> be removed from testing due to gnudatalanguage, which I don't
> understand. But this should be resolved when the package get autoremoved
> on the 14th.

gnudatalanguage was not removed yesterday, it's still marked for removal
on 14 September.

Version 0.9.9-10+b1 of the gnudatalanguage binary packages is in
testing, but 0.9.9-10+b3 is in unstable. It seems that these two NMUs
never migrated to testing.

Can gnudatalanguage (and grib-api) be hinted out of testing to unblock
the removal of libgeotiff-dfsg?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#931950: transition: libgeotiff

2019-09-10 Thread Sebastiaan Couwenberg
libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
be removed from testing due to gnudatalanguage, which I don't
understand. But this should be resolved when the package get autoremoved
on the 14th.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#931950: transition: libgeotiff

2019-07-12 Thread Bas Couwenberg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 931949

For the Debian GIS team I'd like to transition to libgeotiff 1.5. This
version is required for PROJ 6 support.

This transition goes hand in hand with the proj transition. (#931949)

All reverse depenencies built successfully with the new libgeotiff, only
xastir & metview need to apply a patch to not FTBFS with PROJ 6.

A summary of the rebuilds is included below.


Ben file:

title = "libgeotiff";
is_affected = .depends ~ "libgeotiff2" | .depends ~ "libgeotiff5";
is_good = .depends ~ "libgeotiff5";
is_bad = .depends ~ "libgeotiff2";


Transition: libgeotiff

 libgeotiff2 (1.4.3-1) -> libgeotiff5 (1.5.1-1~exp3)

The status of the most recent rebuilds is as follows.

 libgeotiff-dfsg (1.4.3-1)  SKIP (obsolete)
 libgeotiff-epsg (1.4.3-1)  SKIP (obsolete)

 gdal(2.4.2+dfsg-1) OK
 gnudatalanguage (0.9.9-9)  OK
 grads   (3:2.2.1-1)OK
 librasterlite2  (1.1.0~beta0+really1.0.0~rc0+devel1-2) OK
 libterralib (4.3.0+dfsg.2-11)  OK
 ossim   (2.6.2-1)  OK

 liblas  (1.8.1-10) OK
 magics++(3.3.1-1)  OK
 otb (6.6.1+dfsg-1) OK
 pdal(1.8.0+ds-1)   OK
 xastir  (2.1.0-5)  OK [+]

 grass   (7.6.1-1)  OK
 metview (5.3.0-2)  OK [+]


Kind Regards,

Bas