Re: SpatiaLite transition
On 01/06/2014 09:01 AM, Andreas Tille wrote:
> On Sun, Jan 05, 2014 at 04:10:04PM +0100, Sebastiaan Couwenberg wrote:
>> The armhf buildd is stilling chugging along with its backlog, but has
>> not reached spatialite nor its reverse dependencies yet.
>
> I wonder whether it might make sense to ping armhf maintainers about
> this.
I doubt it will make a difference. I strongly suspect that the armhf
buildd admins are well aware of the issues that caused the backlog.
Being one of many people informing about the backlog won't make it go
any faster, although if everyone has this mentality they may not see the
urgency due to the lack of questions/complaints. So it may not hurt to ask.
>> Summary of the current state of affairs:
>>
>> 1) libgaiagraphics (0.5-1) available in experimental
>> 2) freexl (1.0.0f-2) available in unstable
>> 3) readosm (1.0.0b+dfsg1-2) available in unstable
>> 4) spatialite (4.1.1-5) available in experimental [-armhf]
>> 5) librasterlite (1.1g-3) available in experimental [-armhf]
>> 6) spatialite-tools (4.1.1-2) available in experimental [-armhf]
>> 7) spatialite-gui (1.7.1-2) available in experimental [-armhf]
>> 8) pyspatialite (3.0.1-4) available in experimental [-armhf]
>
> Do you consider moving from experimental to unstable?
I've requested transition slots from the Release Team for the
transition, and I was hoping that they can move the packages from
unstable to experimental without the need for new uploads.
They can also schedule the BinNMUs of GDAL, Merkaartor, but not QGIS as
long as the uninstallability of OpenSceneGraph is not resolved.
I'm not in favor of an uncoordinated SpatiaLite transition in unstable.
Although it will speed up the process as the GDAL transition shows
(which was only partially coordinated).
Kind Regards,
Bas
--
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
Reply to: