[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#790831: marked as done (transition: spatialite)



Your message dated Tue, 21 Jul 2015 09:51:56 +0200
with message-id <55ADFA1C.8030702@debian.org>
and subject line Re: Bug#790831: transition: spatialite
has caused the Debian Bug report #790831,
regarding transition: spatialite
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 owner@bugs.debian.org
immediately.)


-- 
790831: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790831
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
Forwarded: https://release.debian.org/transitions/html/auto-spatialite.html

Dear Release Team,

To move away from the deprecated spatialite_init() method that is
causing issues since the proj 4.9.1 transition (#785091) we need to get
spatialite 4.3.0 out of experimental.

The spatialite transition is closely related to the gdal 1.11 transition
(#756867). GDAL 1.11 adds support for the spatialite_init_ex() method,
and will use it for SpatiaLite >= 4.1.2.

Because the gdal transition is currently blocked by mapnik 3, we may be
able to do the spatialite transition first. It has a much more limited
scope.

All reverse dependencies built successfully with spatialite 4.3.0 in my
last round of rebuilds, the summary is included below.

spatialite-tools (4.1.1-5) won't need a rebuild, because 4.3.0-1 will be
uploaded instead.

spatialite-gui (2.0.0~devel2-1) is intended to accompany spatialite
4.3.0, but it requires librasterlite2 which hasn't passed the NEW queue
yet. We can stick to 1.7.1-6 in unstable in case librasterlite2 remains
unavailable.


Transition: spatialite

 libspatialite5 (4.1.1-10) -> libspatialite7 (4.3.0-1)

The status of the most recent rebuilds is as follows.

 gdal              (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4)  OK / OK
 librasterlite     (1.1g-5)                              OK
 librasterlite2    (1.0.0~rc0+devel-1~exp1)              OK
 pyspatialite      (3.0.1-7)                             OK
 spatialite-tools  (4.1.1-5 / 4.3.0-1~exp1)              OK / OK

 merkaartor        (0.18.1-3)                            OK
 osmcoastline      (2.0.1-2)                             OK
 qgis              (2.8.2+dfsg-2)                        OK
 spatialite-gui    (1.7.1-6 / 2.0.0~devel2-1~exp1)       OK / OK


Kind Regards,

Bas

--- End Message ---
--- Begin Message ---
On 14/07/15 11:30, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 02/07/15 08:11, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>> Forwarded: https://release.debian.org/transitions/html/auto-spatialite.html
>>
>> Dear Release Team,
>>
>> To move away from the deprecated spatialite_init() method that is
>> causing issues since the proj 4.9.1 transition (#785091) we need to get
>> spatialite 4.3.0 out of experimental.
>>
>> The spatialite transition is closely related to the gdal 1.11 transition
>> (#756867). GDAL 1.11 adds support for the spatialite_init_ex() method,
>> and will use it for SpatiaLite >= 4.1.2.
>>
>> Because the gdal transition is currently blocked by mapnik 3, we may be
>> able to do the spatialite transition first. It has a much more limited
>> scope.
>>
>> All reverse dependencies built successfully with spatialite 4.3.0 in my
>> last round of rebuilds, the summary is included below.
>>
>> spatialite-tools (4.1.1-5) won't need a rebuild, because 4.3.0-1 will be
>> uploaded instead.
>>
>> spatialite-gui (2.0.0~devel2-1) is intended to accompany spatialite
>> 4.3.0, but it requires librasterlite2 which hasn't passed the NEW queue
>> yet. We can stick to 1.7.1-6 in unstable in case librasterlite2 remains
>> unavailable.
>>
>>
>> Transition: spatialite
>>
>>  libspatialite5 (4.1.1-10) -> libspatialite7 (4.3.0-1)
>>
>> The status of the most recent rebuilds is as follows.
>>
>>  gdal              (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4)  OK / OK
>>  librasterlite     (1.1g-5)                              OK
>>  librasterlite2    (1.0.0~rc0+devel-1~exp1)              OK
>>  pyspatialite      (3.0.1-7)                             OK
>>  spatialite-tools  (4.1.1-5 / 4.3.0-1~exp1)              OK / OK
>>
>>  merkaartor        (0.18.1-3)                            OK
>>  osmcoastline      (2.0.1-2)                             OK
>>  qgis              (2.8.2+dfsg-2)                        OK
>>  spatialite-gui    (1.7.1-6 / 2.0.0~devel2-1~exp1)       OK / OK
> 
> You can go ahead with this.

This is over. Closing.

Emilio

--- End Message ---

Reply to: