RFS: postgis-2.0.3-3

2013-07-22 Thread Markus Wanner
Hi,

unfortunately, the postgis package uploaded recently run into a FTBFS. I
didn't take arch-only builds into account. That, among a couple of other
things got fixed in the mean time. Most notably, the test suite now runs
through just fine.

The current postgis-2.0.3-3 works fine on sid, wheezy and precise,
against Postgres versions 8.4 - 9.2, as per the pgapt build bot.

Please see the postgis alioth repository here:
http://anonscm.debian.org/gitweb/?p=pkg-grass/postgis.git

As a DM, I'd also appreciate upload permissions for postgis.

Regards

Markus Wanner

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel


Re: RFS: postgis-2.0.3

2013-06-26 Thread Francesco P. Lovergine
On Wed, Jun 26, 2013 at 11:18:25AM +0200, Markus Wanner wrote:
> Francesco,
> 
> On 06/26/2013 11:11 AM, Francesco P. Lovergine wrote:
> > please provide the correct required tags to upstream/debian branches at 
> > every
> > new release.
> 
> Thanks, good point. I simply didn't think about that.
> 
> In a similar vein: is it okay to create beta branches? Maybe
> 'upstream-beta' and 'beta' to start packaging on postgis-2.1 (or any
> other beta release in the future)?
> 

Yes, what ever branch can be created, the only condition is creating
a clear and evident namespace for all of them.

> > About libgdal-dev versus libgdal1-dev, the proper dependency is libgdal-dev,
> > the old libgdal1-dev should be considered only for back-compatibility.
> > In this specific case I would use something like
> > 
> > libgdal-dev | libgdal1-dev
> > 
> > until the old releases still will be considered for backports.
> 
> The reasoning behind that was that postgis-2.0 will hardly ever be
> compatible to a libgdal2-dev.
> 

What ever will be the new API, we will have to prepare a proper transition
plan, and using a different -dev package will hardly be the right answer.
The old name with versioning is still around since time when a few third
parties programs used the C++ interface.

> > Ratio: we will neve provide multiple versions of gdal development packages,
> > so using a versioned name is pointless and inconsistent.
> 
> I see. Will change to the proposed variant above.
> 
> Regards
> 
> Markus
> 
> ___
> Pkg-grass-devel mailing list
> Pkg-grass-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

-- 
Francesco P. Lovergine

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel


Re: RFS: postgis-2.0.3

2013-06-26 Thread Markus Wanner
Francesco,

On 06/26/2013 11:11 AM, Francesco P. Lovergine wrote:
> please provide the correct required tags to upstream/debian branches at every
> new release.

Thanks, good point. I simply didn't think about that.

In a similar vein: is it okay to create beta branches? Maybe
'upstream-beta' and 'beta' to start packaging on postgis-2.1 (or any
other beta release in the future)?

> About libgdal-dev versus libgdal1-dev, the proper dependency is libgdal-dev,
> the old libgdal1-dev should be considered only for back-compatibility.
> In this specific case I would use something like
> 
> libgdal-dev | libgdal1-dev
> 
> until the old releases still will be considered for backports.

The reasoning behind that was that postgis-2.0 will hardly ever be
compatible to a libgdal2-dev.

> Ratio: we will neve provide multiple versions of gdal development packages,
> so using a versioned name is pointless and inconsistent.

I see. Will change to the proposed variant above.

Regards

Markus

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel


Re: RFS: postgis-2.0.3

2013-06-26 Thread Francesco P. Lovergine
Markus and possibly others

please provide the correct required tags to upstream/debian branches at every
new release. I just had to add a couple of them onto the postgis repo.
About libgdal-dev versus libgdal1-dev, the proper dependency is libgdal-dev,
the old libgdal1-dev should be considered only for back-compatibility.
In this specific case I would use something like

libgdal-dev | libgdal1-dev

until the old releases still will be considered for backports. 

Ratio: we will neve provide multiple versions of gdal development packages,
so using a versioned name is pointless and inconsistent.

-- 
Francesco P. Lovergine

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel


RFS: postgis-2.0.3

2013-06-07 Thread Markus Wanner
Hi,

recently, I've been working on packaging PostGIS 2.0 for Debian and now
consider it ready for uploading to unstable. I'm a DM and would also
appreciate upload rights for that package.

Some notes: I took great care to ensure postgis-2.0.3 won't break
existing installations of postgis-1.x. For that reason, the binary
package names now include a version, i.e. 'postgis-2.0'. Effective
upgrade from 1.x to 2.0 requires a dump/restore cycle and is left to the
user.

Upstream is mixed about liblwgeom. Basically, at the moment, there is no
backwards-compatibility guarantee. Taking a conservative approach, I
thus added the full version to the binary package name, i.e.
liblwgeom-2.0.3. As postgis itself is currently the only user of that
library in Debian, that shouldn't be much of an issue. However,
spatialite for example may eventually use it as well.

See upstream bugs on component liblwgeom:
http://trac.osgeo.org/postgis/query?status=assigned&status=new&status=reopened&component=liblwgeom

Please see the postgis alioth repository here:
http://anonscm.debian.org/gitweb/?p=pkg-grass/postgis.git

Regards

Markus Wanner



signature.asc
Description: OpenPGP digital signature
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel