Your message dated Tue, 10 Sep 2019 08:06:12 +0200
with message-id <34824c6f-88d7-ef08-6d4e-8e96a1690...@xs4all.nl>
and subject line Re: Bug#931949: transition: proj
has caused the Debian Bug report #931949,
regarding transition: proj
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
931949: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931949
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html
Control: block -1 by 931914 931922 931931 931935 931940 931943 931945 931941
931944 931948 931904 931908 931872
For the Debian GIS team I'd like to transition to PROJ 6.
This is a major change that affects the wider GIS ecosystem, with proj
being at the bottom of the dependency chain.
Most packages build successfully with the new version after defining
ACCEPT_USE_OF_DEPRECATED_PROJ_API_H to use the deprecated proj_api.h.
Several of the affected packages already have this change in unstable.
Others have patches available in the BTS. For yet some others have a fix
available in a new upstream release that still needs to be packaged.
Some packages that FTBFS are dead upstream for quite a while and RM bug
have been filed for those.
The vtk6 & vtk7 packages and their rdeps (ifrit & lammps) are the
biggest issue, but the VTK packages can be updated to use their embedded
copy of PROJ 4. VTK upstream also has support for PROJ 6, but this is
not packaged yet.
libgeotiff-dfsg won't need a rebuild, libgeotiff will be moved to
unstable instead. This will trigger a transition too, but it only
affects 12 packages, 6 of which are also affected by the proj
transition. All libgeotiff rdeps built successfully with the new proj &
libgeotiff.
python-pyproj also won't need a rebuild, the version in experimental
will be moved to unstable as well. This won't trigger a transition.
Transition: proj
libproj13 (5.2.0-1) -> libproj15 (6.1.1-1~exp1)
The status of the most recent rebuilds is as follows.
Packages marked with [+] have a patch available in the BTS.
josm (0.0.svn15238+dfsg-1) SKIP
gpx2shp (0.71.0-7) FTBFS
(#931904)
libgeo-proj4-perl (1.09-3) FTBFS
(#931908)
libgeotiff-dfsg (1.4.3-1) SKIP
libgeotiff (1.5.1-1~exp3) OK
mshr (2018.1.0+dfsg1-7) OK
octave-octproj (1.1.5-4) OK [+]
(#931914)
osm2pgsql (0.96.0+ds-3) OK
pdl (1:2.019-5) OK
proj-rdnap (2008-9) OK
python-cartopy (0.17.0+dfsg-4) OK
python-pyproj (1.9.6-1 / 2.2.1+ds-1~exp1) FTBFS / OK
sosi2osm (1.0.0-6) OK
spatialite (4.3.0a-6) OK
survex (1.2.40-1) OK
xygrib (1.2.2-1) OK [+]
(#931922)
gdal (2.4.2+dfsg-1) OK
magics++ (4.0.3-1) OK
spatialite-gui (2.1.0~beta0+really2.0.0~devel2-4) OK
spatialite-tools (4.3.0-3) OK
xastir (2.1.2-1) OK [+]
(#931931)
cdo (1.9.7.1-3) OK
mapnik (3.0.22+ds-2) OK
mapserver (7.4.0-1) OK
merkaartor (0.18.3+ds-6) OK
metview (5.3.0-2) OK [+]
(#931945)
ncl (6.6.2-1) OK
openorienteering-mapper (0.8.4-1) OK [+]
(#931935)
pdal (1.8.0+ds-1) OK
postgis (2.5.2+dfsg-1) OK
qmapshack (1.13.0-1) OK
r-cran-sf (0.7-6+dfsg-1) OK
saga (2.3.1+dfsg-5) FTBFS
(#931941)
sumo (1.1.0+dfsg1-1) OK [+]
(#931940)
thuban (1.2.2-14) FTBFS
(#931872)
vtk6 (6.3.0+dfsg2-2) FTBFS
(#931943)
vtk7 (7.1.1+dfsg1-12) FTBFS
(#931944)
freecad (0.18.2+dfsg1-1) SKIP
gammaray (2.9.0-2.1) SKIP
grass (7.6.1-1) OK
ifrit (4.1.2-6) FTBFS
lammps (0~20181211.gitad1b1897d+dfsg1-2) FTBFS
node-mapnik (3.7.2+dfsg-5) OK
python-mapnik (1:0.0~20180723-588fc9062-2) OK
r-cran-lwgeom (0.1-5+repack-1) FTBFS
(#931948)
therion (5.4.4ds1-1) OK
qgis (3.4.9+dfsg-1) TODO
Kind Regards,
Bas
--- End Message ---
--- Begin Message ---
On 9/3/19 2:20 PM, Emilio Pozuelo Monfort wrote:
> On 03/09/2019 05:59, Sebastiaan Couwenberg wrote:
>> On 9/2/19 11:12 AM, Sebastiaan Couwenberg wrote:
>>> On 9/2/19 10:43 AM, Emilio Pozuelo Monfort wrote:
>>>> There's also an autopkgtest regression for r-cran-sf as you can see in the
>>>> excuses at https://packages.qa.debian.org/p/proj.html. That's blocking
>>>> proj from
>>>> being a migration candidate.
>>>
>>> That's why I filed #939002.
>>>
>>> There is also the autopkgtest failure of pyresample (python-pyproj rdep)
>>> for which #939128 was filed. For this I'm considering moving proj 5.2.0
>>> & pyproj 2.3.1 from experimental to unstable if these autopkgtest
>>> failure keep blocking the testing migration for more than a week.
>>
>> The pyresample autopkgtest failure is fixed with proj 6.2.0-1 &
>> python-pyproj 2.3.1+ds-1 in unstable.
>>
>> Do we have to wait for testing autoremoval of r-cran-sf or can one of
>> you hint it out?
>>
>> If you want to get this transition done to start the perl transition,
>> several packages in this transition also need aging:
>>
>> * proj
>> * python-pyproj
>> * osm2pgsql
>> * mapnik
>> * openorienteering-mapper
>> * qgis
>> * vtk6
>
> I'm removing the R modules so that proj can migrate.
proj (6.2.0-1) is in testing, and 5.2.0-1 has been removed.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
