Bug#761629: spatialite-gui crash reported upstream

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Ross,

Thanks for looking into this issue. It's much appreciated.

On 09/30/2014 08:59 PM, Ross Gammon wrote:
 Due to the upstream ticket tracker not accepting new tickets
 (problem with website), I have emailed a.furi...@lqt.it with the
 problem.

This has been broken in the upstream Fossil tracking for a while now.
Another option to report issues is the SpatiaLite Users lists, which
I've used to discuss issues with SpatiaLite 4.2.0 because of the
Fossil breakage.

https://groups.google.com/forum/#!forum/spatialite-users

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUKwBaAAoJEGdQ8QrojUrxkREQAI1z3DmxVh+XWNEMxQ6tigHj
qBNvXqnt+1tj3y9alVFI6pcriSMv3+HyFpXyl5Uk6+WUbrCBmr5BNnhd9KCVSSR2
ZHDCaFN65QBNROsNq59zM777NtogimsHBdnv08jfiCLjEuYVGr/zgJJNVwyBeuF7
vuTXCuk2zRL86iGG64cbt8JzpB18PGPRulu2L6r3oNz4/wRosWK+nH6AQMQnjFZd
14G0aRybo9pRiqJpJ/d7Sie1k5i4s0qoBG2K2JR4clA0hGg4gSCHY/yqJLwtYPlN
3gwSTdg5gJwueIhf6eTfG+0BSl5jVxNJ8oHVjoRiS8J0HyPi7kh9ynGPTvb/nlU7
0Vw0uBInbzoyEe9m1DrrLmUpNUjz7U2ahpZJVYNABzoCfxvO41I1seteit3G7ZoS
Ay0dBguZtWGszAP+WwfzS9K4decWsi7mdom0M/dCgRl3+pRlZRVNwLKK2U+L71iq
mX+IgTMNmiSH4+ce8pbLzE4UeEEBw3rBXeP4QliSyrK1q6ifliegHoHNgenjwQZH
aPi7xtrWR5++qHQvVFyt00exFTv6rmmZNXNkb33NCdPz5qQxwqs4LimC5FGB9Zwu
6W7m8HDGLrbOvdzwiEM4Wm7Ym+L2OLOEbLnNJR0G/HvJxkEIIAyN4K9QOtsgHMq1
mktda+6dlhNNOqnHSknI
=DRlF
-END PGP 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

Re: RFS: sosi2osm/1.0.0-1 [ITP]

[Sebastiaan Couwenberg]

On 10/13/2014 11:19 PM, Ruben Undheim wrote:
 I've already made Andreas upload one package for me today, but I
 thought that since this package is a new one, I would spare Andreas
 from some work. But if I tell him that you've reviewed it, it will
 probably make his job a bit easier.

That's very considerate, but I don't expect any problems with small
packages like these.

 Regarding override_dh_auto_install: It is actually used. It prevents
 the broken make install from running and lets sosi2osm.install take
 care of which files should be installed. If I remove it, I will have
 to create a patch that fixes the make install target. I could do that,
 or I could add a comment to the rules file stating why it's there..
 Which one ?

That's a good reason to keep it, adding a comment explaining that `make
install` is explicitly skipped is a good idea.

Kind Regards,

Bas

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


___
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: otb_4.2.1-1_amd64.changes REJECTED

[Sebastiaan Couwenberg]

 Paolo,

 You can use licensecheck in the package devscripts to check which
 licenses are used and update the debian/copyright file.

 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

See also the debian/copyright documentation in the Debian GIS Policy:

http://pkg-grass.alioth.debian.org/policy/policy.html#debian-copyright

 Just running it myself I wonder if you are using the copies of
 libraries (eg boost, zlib, ...)

Whether or not the embedded libraries are used, the code is included
upstream and needs to be documented in debian/copyright.

Kind Regards,

Bas


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

Bug#765421: jmapviewer/josm issue

[Sebastiaan Couwenberg]

Hi Felix,

On 10/15/2014 06:22 PM, Felix Natter wrote:
 since we removed bing_maps.png from jmapviewer in the Debian package,
 jmapviewer does not work with bing sat images in JOSM:
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421
 
 If you agree with this patch, then I can prepare an updated package
 (including the patch) tomorrow and hopefully it will make it in time
 for jessie.

According to the Bing license [1] removing the Bing logo is a violation.

[1] http://wiki.openstreetmap.org/wiki/File:Bing_license.pdf

One of the restrictions for use is:


Restrictions on your use:
We do have some restrictions on your use of the service. You may not:
[...]
change, obscure or remove any search box or any portion of the results,
including, without limitation, any logo, trademark, copyright or other
notice of Microsoft or its suppliers, digital watermarks, or any
advertisement; and if the required logos and copyright notices are not
included in the service generated content, you shall add the logos and
copyright notices provided by Microsoft to the service generated content
as described in the SDKs;


Regarding attribution it further states:


Content Attribution Restrictions outside of the United States:
To the extent applicable local law prohibits you from attributing
content sources by displaying their logos with the service, you must
prominently display the source of the Microsoft Bing Maps Platform data
as a text string with the service at all times. Please refer to the
image below as an example of an acceptable way to attribute source data
with a text string:


The image shows the Bing logo and textual copyright strings for the data
sources.

A compromise to prevent jmapviewer and its rdeps forced into non-free
when the logo is included, may be to use a text string. Although the
quoted clause only applies to jurisdictions outside the US.

It's probably wise to contact map...@microsoft.com and ask them about
the requirements for the Bing logo.

Kind Regards,

Bas

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

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

Bug#765421: jmapviewer: Resolution for missing Bing logo

[Sebastiaan Couwenberg]

On 10/18/2014 12:12 PM, Felix Natter wrote:
 the good news is I have received a mail from a Microsoft employee
 (unfortunately late on Friday) inviting me on a call regarding
 use of the Bing logo in jmapviewer.
 
 I will make that call on Monday morning and maybe we will be able to
 agree on a free license that I can put in debian/copyright and thus I
 can re-include bing_maps.png

If they license the logo under a DFSG compatible license that would be
great. And making our lives much easier.

 But if MS decides the logo must not be included in jmapviewer
 then I'm afraid I *must* remove BingAerialTileSource.java from
 jmapviewer and apply the attached patch [1] to 0.0.svn7480+dfsg1-2,
 removing Bing support from JOSM. Otherwise jmapviewer may be moved to
 non-free because it contains Bing support but not the logo [2].

I'm not sure that the alternative is that you *must* remove the Bing
support from jmapviewer.

The logo referenced by the BrandLogoUri in the attribution REST-call be
fine the use instead of the bing_map.png included in jmapviewer. As
mentioned by Martin Krüger:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421#30

The Bing license says:


and if the required logos and copyright notices are not
included in the service generated content, you shall add the logos and
copyright notices provided by Microsoft to the service generated content
as described in the SDKs


Since the attribution REST-call includes the logo in its generated
content, downloading and using that instead of adding it in jmapviewer
itself seems to comply with the license.

 -- can we agree on this?

In the interest of our JOSM users, doing our best to prevent the removal
of Bing support in jmapviewer should be our priority.

Please discuss the BrandLogoUri solution with Microsoft in your call,
that seems to be the preferred solution to keep jmapviewer and its rdeps
in main, while also complying with the Bing license terms.

While my brief tests with your patch show that JOSM works fine without
Bing support, it's a major loss of functionality. MapBox Satellite and
other freely usable satellite imagery is not on par with the Bing imagery.

Kind Regards,

Bas

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

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

Bug#765421: jmapviewer: Download bing logo via attribution XML at runtime?

[Sebastiaan Couwenberg]

On 10/20/2014 11:17 PM, Felix Natter wrote:
 Felix Natter fnat...@gmx.net writes:
 = I think we need to investigate that for jessie+1, but now I think we
 should parse the attribution data and use the included link to
 download the logo at runtime (many thanks to the patch [1] from Marcus
 Lundblad m...@update.uu.se and Martin Krüger martin.krue...@gmx.com)?
 We should really agree on something now ;-)
 
 -- Can we all agree on this solution for jessie?
 (which is probably legal if JMapViewer itself is legal)
 
 I'd suggest to apply this patch now to make sure it's fixed for jessie!

Yes, until we hear otherwise it seems to me the best solution to the
Bing logo license problem.

I've cleaned up the patch a little and added DEP3 headers for inclusion
in the jmapviewer package. When the patch is forwarded upstream we have
a nice opportunity to get the upstream point of view on this issue.

Kind Regards,

Bas

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

Description: Download the Bing logo when it's not installed.
 The Bing logo is required for attribution when using the imagery, but the
 license terms covering the image are unclear. JMapViewer is licesed under
 the GPL, but the Bing logo is mostly likely not.
 .
 To not require the inclusion of the bing_maps.png file in the jmapviewer
 package, the image is downloaded using the URL provided in the BrandLogoUri
 attribute of the attribution response.
 .
Author: Marcus Lundblad m...@update.uu.se  Martin Krüger martin.krue...@gmx.com
Bug-Debian: https://bugs.debian.org/765421

--- a/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java
+++ b/src/org/openstreetmap/gui/jmapviewer/tilesources/BingAerialTileSource.java
@@ -3,6 +3,7 @@ package org.openstreetmap.gui.jmapviewer
 
 import java.awt.Image;
 import java.io.IOException;
+import java.io.InputStream;
 import java.net.MalformedURLException;
 import java.net.URL;
 import java.util.ArrayList;
@@ -45,6 +46,7 @@ public class BingAerialTileSource extend
 private static final Pattern subdomainPattern = Pattern.compile(\\{subdomain\\});
 private static final Pattern quadkeyPattern = Pattern.compile(\\{quadkey\\});
 private static final Pattern culturePattern = Pattern.compile(\\{culture\\});
+private String BrandLogoUri = null;
 
 public BingAerialTileSource() {
 super(Bing Aerial Maps, http://example.com/;);
@@ -97,6 +99,9 @@ public class BingAerialTileSource extend
 subdomains[i] = subdomainTxt.item(i).getNodeValue();
 }
 
+XPathExpression BrandLogoUriXpath = xpath.compile(/Response/BrandLogoUri/text());
+this.BrandLogoUri = BrandLogoUriXpath.evaluate(document);
+
 XPathExpression attributionXpath = xpath.compile(Attribution/text());
 XPathExpression coverageAreaXpath = xpath.compile(CoverageArea);
 XPathExpression zoomMinXpath = xpath.compile(ZoomMin/text());
@@ -173,8 +178,17 @@ public class BingAerialTileSource extend
 
 @Override
 public Image getAttributionImage() {
+	for( int i=0 ; i5  getAttribution()==null ; i++ ) ;
 try {
-return ImageIO.read(JMapViewer.class.getResourceAsStream(images/bing_maps.png));
+final InputStream imageResource = JMapViewer.class.getResourceAsStream(images/bing_maps.png);
+if (imageResource != null) {
+return ImageIO.read(imageResource);
+} else {
+if (this.BrandLogoUri != null)
+return ImageIO.read(new URL(this.BrandLogoUri));
+else
+return null;
+}
 } catch (IOException e) {
 return null;
 }
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#765421: jmapviewer: Download bing logo via attribution XML at runtime?

[Sebastiaan Couwenberg]

Hi Felix,

 Sebastiaan Couwenberg sebas...@xs4all.nl writes:
 On 10/20/2014 11:17 PM, Felix Natter wrote:
 Felix Natter fnat...@gmx.net writes:
 = I think we need to investigate that for jessie+1, but now I think
 we
 should parse the attribution data and use the included link to
 download the logo at runtime (many thanks to the patch [1] from Marcus
 Lundblad m...@update.uu.se and Martin Krüger
 martin.krue...@gmx.com)?
 We should really agree on something now ;-)

 -- Can we all agree on this solution for jessie?
 (which is probably legal if JMapViewer itself is legal)

 I'd suggest to apply this patch now to make sure it's fixed for jessie!

 Yes, until we hear otherwise it seems to me the best solution to the
 Bing logo license problem.

 I've cleaned up the patch a little and added DEP3 headers for inclusion
 in the jmapviewer package. When the patch is forwarded upstream we have
 a nice opportunity to get the upstream point of view on this issue.

 Thanks for your help! I pushed the change to jmapviewer git and tested
 with josm (and freeplane).

Do you intent to update the package with the 1.04 upstream release?

JMapViewer 1.04 contains the patch in slightly modified form, more in line
with the upstream coding convention.

 Don Armstrong wrote:
 At the very least, I'd stick a note in NEWS.Debian.gz.

 = Do we really want to do this? I think that problematic
 bing support is not quite new for this package?

Documenting the problems with the Bing logo is a good idea in general.

I'm inclined to document it in README.Debian instead of in a NEWS item,
because the logo was never part of the package. But NEWS items are more
visible thanks to apt-listchanges.

 @Andreas: Could you sponsor this tomorrow?

Would it make sense to sponsor the new upstream version instead of the
patches 1.03?

Kind Regards,

Bas

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

Bug#765421: jmapviewer: Download bing logo via attribution XML at runtime?

[Sebastiaan Couwenberg]

On 10/21/2014 08:52 PM, Felix Natter wrote:
 Sebastiaan Couwenberg sebas...@xs4all.nl writes:
 JMapViewer 1.04 contains the patch in slightly modified form, more in line
 with the upstream coding convention.
 
 I would rather not like to do this, because i.e. from 1.02 to 1.03 they
 introduced incompatibilies and I had to fix freeplane, and I might
 not have enough time to fix freeplane (and josm) before the freeze :-/

That's entirely reasonable with only two weeks left until the freeze.

I mostly asked in case you missed the message by Vincent Privat in his
role as JOSM  JMapViewer upstream, who asked if it was possible to get
the new upstream version into jessie. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765421#95

I've reviewed the changes between 1.03 and 1.04, and they are very
minimal (if you exclude whitespace changes), but two weeks may not be
enough to test the rdeps and have the updated package(s) migrate to testing.

 Would it make sense to sponsor the new upstream version instead of the
 patches 1.03?
 
 I appreciate that you reported the patch upstream so quickly, but I
 would prefer to stick with 1.03 for jessie.

Just for the record, I didn't forward the patch, Vincent Privat was
apparently following the bug report and/or mailinglist(s).

It's your call to update to 1.04 or not. I would update the packaging
and upload it to experimental at least if you have the time.

Kind Regards,

Bas

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

___
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: Libjpeg trouble in jmapviewer

[Sebastiaan Couwenberg]

On 10/23/2014 08:20 PM, Andreas Tille wrote:
 unfortunately there is some conflict in the Build-Depends:
 
 
 0 packages upgraded, 132 newly installed, 0 to remove and 0 not upgraded.
 Need to get 62.8 MB/92.4 MB of archives. After unpacking 210 MB will be used.
 The following packages have unmet dependencies:
  libjpeg62-turbo : Conflicts: libjpeg62 but 1:1.3.1-8 is to be installed.
  libjpeg62 : Depends: libjpeg62-turbo (= 1:1.3.1-8) but 1:1.3.1-10 is to be 
 installed.
 Unable to resolve dependencies!  Giving up...
 The following NEW packages will be installed:

This is caused by the build-dependency on default-jdk which needed an
update for the jpeg-turbo transition. It was earlier today reported on
debian-release in the gettext is BD-Uninstallable thread:

https://lists.debian.org/debian-release/2014/10/msg00445.html

It should be fixed with the latest openjdk-7 upload, but it hasn't hit
the mirrors yet.

 Kind regards
 
  Andreas.

Kind Regards,

Bas

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


___
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: Bug#764951: RFS: libgdal-grass/1.11.1-1~exp1

[Sebastiaan Couwenberg]

Hi Andreas,

On 10/23/2014 10:22 PM, Andreas Tille wrote:
 On Thu, Oct 23, 2014 at 10:11:59PM +0200, Sebastiaan Couwenberg wrote:

 It looks like your experimental branch is outdated, gdal-grass 1.11.1
 build depends on libgdal-dev (= 1.11.1-1~).

 Pulling the experimental branch should suffice to fix this specific issue:

  git fetch origin
  git checkout experimental
  git pull
 
 I did so:
 
 $ git log
 commit 4b4b0f7a63c8d35f86489e9ed515372dc35ef650
 Author: Bas Couwenberg sebas...@xs4all.nl
 Date:   Sun Oct 12 16:17:07 2014 +0200
 
 Set distribution to experimental.
 
 [...]
 
 Unfortunately this packages also suffers from the libjpeg62-turbo unmet
 build dependency, so it cannot be built at the moment.
 
 ... so we can keep on sorting out since the problem seems to remain.
 
 0 packages upgraded, 228 newly installed, 0 to remove and 0 not upgraded.
 Need to get 36.9 MB/115 MB of archives. After unpacking 491 MB will be used.
 The following packages have unmet dependencies:
  pbuilder-satisfydepends-dummy : Depends: libgdal-dev (= 1.11.1-1~) but 
 1.10.1+dfsg-8+b3 is to be installed.
 Unable to resolve dependencies!  Giving up...
 The following NEW packages will be installed:
 
 
 I even fetched a fresh clone via gbp-clone and did the steps you
 suggested above. :-(

The git repo looks good, and the version in the unmet Depends too.

I cannot reproduce this problem with my sid+experimental chroot which is
setup like yours as described in:

http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-September/021973.html

Interestingly here apt reports 229 newly installed, yours one less. I've
attached my build log for comparison.

 Thanks for your all your sponsorship efforts.
 
 I admit I'm waiting for the time when three or four of you new activists
 in Debian GIS will become DM.  I also tried to encourage Ross and Johan
 to apply.  You all do pretty good work and it is time to gain the
 official status.

I just pinged my AM again to see if we can get moving again.

 Kind regards
 
Andreas.

Kind Regards,

Bas

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



libgdal-grass_1.11.1-1~exp1_amd64.build.gz
Description: application/gzip
___
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: Bug#764951: RFS: libgdal-grass/1.11.1-1~exp1

[Sebastiaan Couwenberg]

On 10/23/2014 11:36 PM, Sebastiaan Couwenberg wrote:
 On 10/23/2014 10:22 PM, Andreas Tille wrote:
 On Thu, Oct 23, 2014 at 10:11:59PM +0200, Sebastiaan Couwenberg wrote:
 Unfortunately this packages also suffers from the libjpeg62-turbo unmet
 build dependency, so it cannot be built at the moment.

 ... so we can keep on sorting out since the problem seems to remain.

 0 packages upgraded, 228 newly installed, 0 to remove and 0 not upgraded.
 Need to get 36.9 MB/115 MB of archives. After unpacking 491 MB will be used.
 The following packages have unmet dependencies:
  pbuilder-satisfydepends-dummy : Depends: libgdal-dev (= 1.11.1-1~) but 
 1.10.1+dfsg-8+b3 is to be installed.
 Unable to resolve dependencies!  Giving up...
 The following NEW packages will be installed:


 I even fetched a fresh clone via gbp-clone and did the steps you
 suggested above. :-(
 
 The git repo looks good, and the version in the unmet Depends too.
 
 I cannot reproduce this problem with my sid+experimental chroot which is
 setup like yours as described in:
 
 http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-September/021973.html
 
 Interestingly here apt reports 229 newly installed, yours one less. I've
 attached my build log for comparison.

Did you find out what the missing package on your build was?

Kind Regards,

Bas

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


___
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: libgeotiff-dfsg_1.4.0-3_amd64.changes ACCEPTED into unstable

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/24/2014 09:06 AM, Debian FTP Masters wrote:
 * Install manfile for listgeo.1

This causes a problem on upgrade:

Unpacking geotiff-bin (1.4.0-3) over (1.4.0-2) ...
dpkg: error processing archive
/var/cache/apt/archives/geotiff-bin_1.4.0-3_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/listgeo.1.gz', which is also
in package libgeotiff-dev 1.4.0-3


I've pushed some changes fix this and some other lintian issues.

Can you prepare a new upload or should I?

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUSlEaAAoJEGdQ8QrojUrx2hUQAMxAo5ZvqYCfmy4NZcszyfVb
xCuVP1OrztYZY3mD9NwyXn+bM03JMk7YILh3Zpg2nycwAnhc+5Ty+JhFpMB6YW6t
VL1wQQ2OzRg4Pcfd/uDWrgYfz337yUkjPqZCqJrlHy2aC89gKECVEUpPOCM2jBxf
VkclrdnUZhteYcMSGvJMHbOo8KNlTCVBTCkBwdsEIaI7hTqj/zeMPQoB4kKTlXXt
yZ93eh8r5MvKWm3oO4Two+GUxSd7XsTl7mCV1Tsw6ms3q/tSTxuWAMsm3LFokB3T
tCUyx+LN1qpuuows7GpuENBojnSRG0rVO0PWdobqdfOBDK37AEfeK+/id2qwOHBQ
h7/uczjlxLm1Ch0kuHsDw6kl06/3uwYHnHlrHHXv4qUk2ZCwiiPFz0HGRHHOibIV
FvImVTNjblKKwJZ9P1R51DDJ1U+/8v1pPdlRV7NhLrdSJRDnzQ1X1vGXfNAb/Jds
iulswJd9OPCNzVocmIDt6fgHtxmeX8PVQlbg+oTZgclvXFRL6me3XvVMj9mGgEJ9
GbGwG44Z5vS/y1juojdOkznAJ+SRG8n73OOYsdMhYY75pkkRDDRRSej/K+IlQHz0
I+7V9SOC7HVJw24yrZr+PZq5ajoo8af/oqkuGP396o8wXMBjmKitMVz2VI5IlvNM
s/D5ooYrPaxhyE8neafW
=4JBQ
-END PGP 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

Re: Bug#764951: RFS: libgdal-grass/1.11.1-1~exp1

[Sebastiaan Couwenberg]

On 10/24/2014 11:34 AM, Andreas Tille wrote:
 On Fri, Oct 24, 2014 at 11:15:43AM +0200, Sebastiaan Couwenberg wrote:
 On 10/23/2014 11:36 PM, Sebastiaan Couwenberg wrote:
 I cannot reproduce this problem with my sid+experimental chroot which is
 setup like yours as described in:

 http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2014-September/021973.html

 Interestingly here apt reports 229 newly installed, yours one less. I've
 attached my build log for comparison.

 Did you find out what the missing package on your build was?
 
 No, I need to find the diff of the build log (since lacking a better idea)
 but I can't do this right now.  Hope to manage this later this afternoon.

I can reproduce the problem using a sid-only pbuilder chroot. With a
sid+experimental or plain experimental chroot the jpeg-turbo unmet
dependency prevents the build.

Kind Regards,

Bas

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


___
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: Bug#764951: RFS: libgdal-grass/1.11.1-1~exp1

[Sebastiaan Couwenberg]

On 10/24/2014 11:03 PM, Andreas Tille wrote:
 -Need to get 35.1 MB/116 MB of archives. After unpacking 494 MB will be used.
 -The following packages have unmet dependencies:
 - libjpeg62-turbo : Conflicts: libjpeg62 but 1:1.3.1-8 is to be installed.
 - libjpeg62 : Depends: libjpeg62-turbo (= 1:1.3.1-8) but 1:1.3.1-10 is to be 
 installed.
 -Unable to resolve dependencies!  Giving up...

This seems to be caused by gdal 1.11.1 in experimental not having been
rebuilt for the jpeg-turbo transition.

I've just filed a binnmu bug to have it rebuilt (#766694).

Kind Regards,

Bas

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


___
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: [website] 01/01: Add a title to task installation sub-section

[Sebastiaan Couwenberg]

Hi Ross,

Thanks for your policy contributions!

On 10/26/2014 06:24 PM, Ross Gammon wrote:
 ---
  policy.xml | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/policy.xml b/policy.xml
 index 833c549..5bceff8 100644
 --- a/policy.xml
 +++ b/policy.xml
 @@ -1675,6 +1675,8 @@ lintian ../build-area/*changes
  commanddebcheckout/command option-a/option 
 literaldebian-gis/literal
  /programlisting
  /para
 +  sect2 id=installing-tasks
 +titleInstalling Debian GIS Blend tasks/title  
  para
The syntax of the tasks files is very similar to Debian control files,
and described on the

You need to close the sect2 tag, just like the itemizedlist in your
previous commit.

After making changes to the policy.xml file it's highly recommended to
run `make` which will validate the XML syntax using xmllint before
generating the HTML.

If there are no errors, commit your changes and push them to the Alioth
git repository.

Check the git status if there are no stray files, after which you can
update the policy included in pkg-grass website on Alioth using `make
publish`. This will rsync the current working directory to the team
webspace on Alioth and fix the group permissions. It will complain about
the icons directory on Alioth which is owned by frankie but the
pkg-grass group cannot write.

Kind Regards,

Bas

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


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

Bug#767738: FTBFS: hardcoded path to libgeotiff.so missing Multi-Arch component

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 pending

Hi Ondřej,

Thanks for reporting this issue.

On 11/02/2014 11:14 AM, Ondřej Surý wrote:
 libgeotiff-dfsg has switched to Multi-Arch in 1.4.0-3 and this 
 breaks ossim build as it has a hardcoded path (why?).  You should 
 either add support for M-A paths or don't use hardcoded path[1]
 and let the linker pick the correct path itself.

I've fixed debian/rules to use the Multi-Arch path which seems the
most targeted fix.

During the jessie+1 development cycle we should tweak the CMake build
system to find the library instead of hardcoding the path.

I'll request an unblock from the Release Team after the package is
uploaded.

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUVkJKAAoJEGdQ8QrojUrxEL0P/RA6LS5WlGsxt6kG2d26jXis
X5Uuc6lyfXmiPYvLzstzJ4qbJ9+u9cwytNGEaYtX0SCLs2TnoGQln2GIB37b8jpQ
ZnLcWdf1auOl4RA3WzE8gvlqk0f91DPFZ7+AKlDZsUSGKbOgXoCZXnCcHm7KaOzV
tV5BLMb8w/JXBpCKfEfMHl2c+gJnuLVbUlM1/itI4YSGsrkYQXYw8gwMgou4pHcA
ZzX3QilehJ/UV6+RwrjrpdYQ+nP5UAaCPGmz2DqOxbtbxrx1XiaGknycGjHXs6Ma
L1KbeILlkXvxbMXwACv34xP2FainlTBcx0rmV87I9fxCI7EfpKY1LIV9CKGUNook
zowvu5NR6D43n4LXQwVUopMxDJv/mlthHTr7h9oxPeeVxTKSXiyG9ZLGGQ/8dI+F
r0s2a0bQDP+1mqK01Oa174N9Yps65cu0BSUX01zpAhFjV5zGzigzBKCs9hFwKQfc
xwL5nRF+I1vBqdlyvGNV/4uYIAqiZmOeCWAL5Qsjen4lfSGl9poHZ3dxQJgnWFaq
xtVK1jneq6Ez0Py4Obz2/gX3dqJDp3iRgUyfZ7XyQBfnkWvulI0kObph8Lz2OX0R
QXqt7AVMGGpMPLvNN452AXmDaFV0R7fk2Z+JPoVK4Ce2zS00gLmRQ+6epa15qJ73
XFdNaQHbGitFDTbS7RIK
=ZBku
-END PGP 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

Bug#768141: geotiff-bin: fails to upgrade from 'wheezy' - trying to overwrite /usr/share/man/man1/listgeo.1.gz

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Andreas,

Thanks for reporting this issue.

 during a test with piuparts I noticed your package fails to upgrade from
 'wheezy'.
 It installed fine in 'wheezy', then the upgrade to 'jessie' fails
 because it tries to overwrite other packages files without declaring a
 Breaks+Replaces relation.

The package is fixed in git and will be uploaded to mentors later today.
After it's uploaded I'll file an unblock bug to get it into jessie.

Kind Regards,

Bas

___
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: Bug#764951: RFS: libgdal-grass/1.11.1-1~exp1

[Sebastiaan Couwenberg]

Hi Andreas,

On 10/25/2014 09:58 AM, Andreas Tille wrote:
 On Sat, Oct 25, 2014 at 12:25:21AM +0200, Sebastiaan Couwenberg wrote:
 I've just filed a binnmu bug to have it rebuilt (#766694).
 
 As usual ping me once I should retry the build (even if stuff in
 experimental should not be that urgent). 

While the binnmu by the Release Team was sufficient to build
libgdal-grass, the recent upload of gdal/1.11.1+dfsg-1~exp2 is even
better due to the updated symbols.

Can you try libgdal-grass/1.11.1-1~exp1 once more now that the buildds
are done with gdal?

Kind Regards,

Bas

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


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

Bug#768887: FTBFS: Could not copy file .../osmosis-plugins.conf

[Sebastiaan Couwenberg]

Control: tags -1 unreproducible

Hi Adam,

Thanks for reporting this issue.

On 11/09/2014 10:33 PM, Adam Borowski wrote:
 I'm afraid that during a rebuild of jessie on armhf your package failed to
 build:

 A build on amd64 succeeded, though.
 This is not the first package using gradle that failed during this rebuild:
 #768835 in groovy2 failed with a similar error.

My build on amd64 succeeded too, so I'll have to request a guest account
on an armhf porterbox to reproduce it there.

Since I cannot upload a new revision to experimental with debugging
enabled to trigger a build on armhf, I hope that the underlying issue
with gradle can be found and fixed before its rdeps are autoremoved from
jessie.

Kind Regards,

Bas

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

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

Bug#768887: FTBFS: Could not copy file .../osmosis-plugins.conf

[Sebastiaan Couwenberg]

Control: severity -1 important

On 11/10/2014 12:46 AM, Adam Borowski wrote:
 As this is an arch:all package, FTBFS bugs are far less important (as at
 least one architecture where osmosis builds exists).  I guess it can be
 downgraded if it can't be solved easily.

Agreed. I'm downgrading the severity to important because it doesn't
render the package completely unusable to everyone.

Kind Regards,

Bas

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

___
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: pycsw_1.10.0+dfsg-1_amd64.changes REJECTED

[Sebastiaan Couwenberg]

 One result of the discussion about tinyows was that OGC schemas don't fall
 under the Software Notice but the Document Notice. This makes them
 non-free
 (no modification) and tinyows had to move to non-free.
 I am afraid that pycsw has to do this as well.

That seems to be the wrong way around.

The OGC schemas fall under the Software Notice as documented in the OGC
LegalFAQ [1], the testcases appear to fall under the Document Notices
(although the CITE test may have a different license than Document or
Software Notice, I've never received feedback from OGC on my questions).

To adress the TinyOWS issue, upstream has moved the testcases to a
separate repository and won't include it in tarball at the next release.

This should allow TinyOWS to move to main after the package is updated to
strip the testcases as is done in the upstream git repo.

If the FTP masters consider the OGC schemas to fall under the Document
Notice despite what the OGC LegalFAQ says, then we need to move a lot of
GIS packages to non-free because they also contain the schemas.

[1] http://www.opengeospatial.org/ogc/legalfaq#DTD

Kind Regards,

Bas


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

Bug#770881: josm: JOSM package doesn't install the appstream appdata.xml file

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Markus,

Thanks for your patch, I've applied it to the josm package in git, only
adjusting the source path to:

 $(CURDIR)/linux/tested/usr/share/appdata/josm.appdata.xml

It will be included in the next upload of JOSM with the new tested snapshot.

Kind Regards,

Bas

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

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

Bug#770931: osmctools: new upstream version of osmconvert - adds alternative granularity support

[Sebastiaan Couwenberg]

Control: severity -1 wishlist

 Markus has added support for PBF plant dumps with non-standard
 granularity, it
 would be great to have his new version of osmconvert in Debian.

Once a new osm-c-tools release is published we'll update the Debian package.

We could include a patch for the commit in the package, but it won't make
it into the jessie release anyway, so there is no hurry. Unless the next
osm-c-tools release is not due for a long time, then we should consider
adding a patch for the commit.

Kind Regards,

Bas

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

OGC schemas, licensing non-free [Was: pycsw_1.10.0+dfsg-1_amd64.changes REJECTED]

[Sebastiaan Couwenberg]

Hi Johan,

On 11/19/2014 10:08 PM, Johan Van de Wauw wrote:
 Just for clarity, pycsw only contains the schemas, and not the
 testcases mentioned for tinyOWS.
 
 I would like to point out that regarding these schemas there is
 actually no difference between the licenses used by W3C and OGC (apart
 from the copyrightholders). Indeed, the OGC software license [2] is
 identical to the W3C license [3] (OSGI approved [4]).
 
 The document license for OGC [5] is again identical to the document
 license for W3C [6]. W3C schemas (eg xml.xsd) are used by *many*
 debian packages. Is there an exemption in W3C which I missed (and
 which we could suggest to OGC), or is there a more general problem
 here? I think standards are one of the cases where I find the DFSG #4
 exemption is defendable.

Regarding the above, and what you wrote on #osgeo-live:

23:09  johanvdw I actually talked about it with Bart Delathouwer from OGC
23:09  johanvdw just earlier today
23:10  johanvdw I'll try to convince the ftp-masters that it can fall
under DFSG 4 exemption
23:10  johanvdw In the mean time upload to non-free

Do know if Bart is planning to come to FOSDEM? I would love to have a
face to face conversation about the OGC licensing and Debian. I asked
around last year if any of the Geo people knew if any OGC folks were
around, but it didn't seem to be the case.

Kind Regards,

Bas

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


___
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: OGC schemas, licensing non-free [Was: pycsw_1.10.0+dfsg-1_amd64.changes REJECTED]

[Sebastiaan Couwenberg]

On 11/28/2014 10:14 PM, Johan Van de Wauw wrote:
 On Fri, Nov 28, 2014 at 5:24 PM, Sebastiaan Couwenberg
 sebas...@xs4all.nl wrote:
 Hi Johan,

 On 11/19/2014 10:08 PM, Johan Van de Wauw wrote:
 Just for clarity, pycsw only contains the schemas, and not the
 testcases mentioned for tinyOWS.

 I would like to point out that regarding these schemas there is
 actually no difference between the licenses used by W3C and OGC (apart
 from the copyrightholders). Indeed, the OGC software license [2] is
 identical to the W3C license [3] (OSGI approved [4]).

 The document license for OGC [5] is again identical to the document
 license for W3C [6]. W3C schemas (eg xml.xsd) are used by *many*
 debian packages. Is there an exemption in W3C which I missed (and
 which we could suggest to OGC), or is there a more general problem
 here? I think standards are one of the cases where I find the DFSG #4
 exemption is defendable.

 Regarding the above, and what you wrote on #osgeo-live:

 23:09  johanvdw I actually talked about it with Bart Delathouwer from OGC
 23:09  johanvdw just earlier today
 23:10  johanvdw I'll try to convince the ftp-masters that it can fall
 under DFSG 4 exemption
 23:10  johanvdw In the mean time upload to non-free

 Do know if Bart is planning to come to FOSDEM? I would love to have a
 face to face conversation about the OGC licensing and Debian. I asked
 around last year if any of the Geo people knew if any OGC folks were
 around, but it didn't seem to be the case.
 
 I'll invite him, but I don't know what his plans are. At least he
 knows since yesterday that we are organizing this track. For the
 record, he likes tinkering
 with debian on this raspberry pi - you have conversation starter :-)

I'd skip the smalltalk and get straight to the point, asking about his
views on the OGC {Document,Software} Notice vs DFSG issues. And if he
could join the thread and state the OGC position to the FTP masters.

 Anyway: it will be hard to convince him that it is useful to allow
 modifications of the XSD's (Why on earth would you want to do that).
 And I actually think that the license exemption in the their FAQ
 allowing it given that you use a different namespace is not
 unreasonable, and very close to DFSG #4 exemption.

I also think that limiting modification for the OGC schemas is not
unreasonable in the context of standards. Allowing modification would
just make it easier to include the software in Debian.

 If we propose a wording to OGC which both covers their concerns (don't
 just change an XSD and distritbute it as if it is the original
 standard) and which is acceptable to the FTP masters, I think OGC may
 confirm this interpretation.
 
 For me the ball is in their (FTP-masters) camp.

I'm also waiting for a reply from FTP master regarding the OGC schemas.
But please note that I removed FTP masters from the recipients of this
subthread.

 If I read the original mail for tinyows [1] they have a few concerns:
 1) questions whether the Software license is DFSG free
 
 I think the correct answer is it is free. At least according to OSI
 and Fedora it is. It is used by many other packages in debian (as the
 W3C software license).

I also think the OGC Software Notice complies with the DFSG, but only
the FTP masters can give a final word on that.

 2) Whether the license FAQ is really part of the license:
 
 I think it clearly is, it is linked from the page and mentioned in the
 license. Question: Do the FTP-master agree? Do we need a seperate
 statement from OGC that it really is part of the license?

To clarify these questions I'd love for someone from OGC to join the
conversation with the FTP masters.

I also think that the license FAQ clearly confirms that the OGC schemas
are licensed under the terms of the OGC Software Notice.

 The first sentence says that schemas are covered by the Document
 Notice (= no modifications allowed = non-free). Only if you use a
 different namespace, you may apply the Software Notice and do
 modifications. I think this is against DFSG#3 and not covered by the
 compromise in DFSG#4.
 
 I think is not a clear signal here. Can we get a clear answer from
 the FRP masters? If it is not covered by the compromise, can the FTP
 masters suggest a wording that would be covered by the exemption? So
 we can propose it to OGC?

If we can get Thorsten Alteholz and Bart Delathouwer together at FOSDEM
we could have this conversation in person. It may speed up the process.

Kind Regards,

Bas

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


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

Bug#771705: osm2pgsql: Import fails in PolygonBuilder.cpp:261

[Sebastiaan Couwenberg]

Hi Daniel,

On 12/01/2014 08:22 PM, Daniel Baur wrote:
 I try to import the last planet-dump into the database. The import fails
 with
 
 --snip
 
 Reading in file: /data/dump/planet-latest.osm.pbf
 Processing: Node(2614096k 177.8k/s) Way(261025k 27.43k/s) Relation(46730
 40.49/s)osm2pgsql: PolygonBuilder.cpp:261: geos::geomgraph::EdgeRing*
 geos::operation::overlay::PolygonBuilder::findShell(std::vectorgeos::operation::overlay::MinimalEdgeRing*,
 std::allocatorgeos::operation::overlay::MinimalEdgeRing* *): Assertion
 `shellCount = 1' failed.
 
 --snap---
 
 after a few hours. If you need more data, please tell.

This looks like an issue in GEOS, not osm2pgsql.

Searching for the error message turns up several threads marking this
issue as fixed in GEOS = 3.3.3. E.g.

https://github.com/openstreetmap/osm2pgsql/issues/124

This change in GEOS removes the `shellCount = 1' assert, that is
triggered on your system:

http://trac.osgeo.org/geos/changeset/3286

This leads me to think that the mix of squeeze, wheezy and jessie
packages on your system is the actual cause.

To rule out your esoteric mix of package from different Debian releases,
having a smaller test case than importing a full planet dump would be
most helpful. We can't expect anybody to perform full planet imports to
troubleshoot this issue. I for instance don't have the disk space
available for a full planet import.

If you can pinpoint which OSM objects were being processed at the time
of the failure, reproducing the failure with a smaller extract for the
area should be doable.

Reproducing the issue on a proper jessie system would be even more helpful.

Kind Regards,

Bas

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

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

Bug#771782: postgis: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 pending

Hi José,

Thanks for your translation. I've added it in git, and it will be part
of the next upload.

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUfgtnAAoJEGdQ8QrojUrx0GYQALJOVXT7RuKCJM+J68Cb1FkI
cSfeghMMBRqWQ/IKvnHxbAIJIJFObmsKnHPcEkCECvRXL/Q3qqS2UR110ghfPR9C
wL0Wg8uNVXOFiYwTzSCZh2O6b0M3FIQsiTjaqnd49ZttkA1+BX1LnhjBulTy2xJT
jjmWSpcK8f9wBP8dNYcXSpqc6ikhDbwplYCi5CWbh2NS+/BQ9pUGAF0P8lQ7Zmn1
mqYRaoML4SfvkKfzg1h5Whl5UEVo5pSQ5KGEOoBkleU2Ov/QZ/FD5X6WjIV6sFcG
hClgrdkSgzqKE9KNE2L6LQQXi3Na6SWfIa+I853zYKU6U/WbS1RPVIRNjGj03sVl
Gpt9wKbteF45H/qF2j4EH48MktU9lwpI6l6SZF5MNttirwZRhR53EzR3EcTmKZQB
2FCeyTY24AUICVK0/c4EyDuuNwrQoOoHUwcEpBQoP31StS2jYmgwurJGiKS1JGke
ocYBdQG8zT8IHd6cNijzu/qhI3BJxvsizsVEJSockp8HvTjH8FU0MeFGIbT9tQm6
58v13qD/HsUnW6CQBAf1KzHMzSgg0Oy9teYJLFUTm/rmf6i3ZQ6KFGwCtqhRvc00
twA5ZYgSpRcOe8C58GBSkuLst5P9TrcEXOniB3+y6+oF6w0Mn4vR1+KauaXsO6E5
PjQ8j0WQ7yDa8W2ma06m
=L3UX
-END PGP 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

Re: Bug#706157: mapserver: Re: mapserver: Please package new upstream Version 6.2.1

[Sebastiaan Couwenberg]

Hi Alan and devs,

Thanks for accepting my application on alioth.

I can explain the reason for the git clone of the pkg-grass mapserver
packaging. To summarize the thread on debian-gis, I needed a fix from
mapserver 6.2.1 to make the mapserver 6.0.1 package in wheezy handle
Content-Type headers including a charset. Looking at the other changes
in mapserver 6.2 I thought about packaging that for my own use since
there was no 6.2 package in Debian yet.

Sometime during my packing of 6.2.1 I found your changes in the
UbuntuGIS PPA and merged those into my git clone. As indicated in my
initial post to the thread I want to contribute those changes to the
DebianGIS team. I've been using Debian for little of 10 years now, and
I've always wanted to contribute more to the project than the occasional
bug report. Andreas Tille convinced me to finally take the plunge and
apply for team membership so I can contribute directly instead of being
forced to use my fork.

I've been procrastinating writing an email to Francesco, yourself and
Jerome asking about your plans for the MapServer stack packaging, as you
three seem to be the active maintainers of the package in Debian and
Ubuntu. The lack of feedback on the debian-gis thread made me think that
you're all just too busy to work on MapServer packaging currently.

Are the changes for the UbuntuGIS package in a local git clone that can
be pushed to git.debian.org? Then I can generate clean patches for my
changes on top of that. So we don't have to pollute the history with my
mistakes and their subsequent fixes in a later commit.

I've also been working on packaging MapCache 1.0.0 which I'll also move
to git.debian.org. As far as I could find there is no packaging for that
yet, only for an older git branch. My packaging is based on the 1.0.0
tarball release, and currently lives in my git repo too:

http://git.linuxminded.nl/?p=pkg-grass/mapcache;a=summary

Francesco, can you share your thoughts on the packing of the MapServer
stack, and how you'd like to proceed with that?

Kind Regards,

Bas

On 05/24/2013 11:44 PM, Alan Boudreault wrote:
 Devs,
 
 Could anyone explain me the use of the following repository?
 
 http://git.linuxminded.nl/?p=pkg-grass/mapserver;a=summary
 
 Looks like we are duplicating a lot of effort here. If I recall
 correctly, there were already a working package for debian of mapserver
 6.2.0 in the official debian git. It would be interesting to get your
 improvements in the official repo.
 
 Best Regards,
 Alan
 
 On 13-05-24 05:17 PM, Bas Couwenberg wrote: There were already a
 working debian package for 6.2.0 in the official debian repository.
 Package: cgi-mapserver
 Followup-For: Bug #706157

 Dear Sven and Debian GIS team,

 As mentioned on the debian-gis list [1] I've been working on packaging
 mapserver
 6.2.1 for Debian. My changes are available in the git repo mentioned
 in the
 message, and I've uploaded a build for unstable to mentors.

 [1] http://lists.debian.org/debian-gis/2013/05/msg1.html

 ...snip...

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#663875: cgi-mapserver: mapserver --with-agg

[Sebastiaan Couwenberg]

notfound 663875 mapserver/5.6.5-2+squeeze2
thanks

On 02/22/2013 08:27 AM, carlo pelliconi wrote:
 Package: cgi-mapserver
 Version: 5.6.5-2+squeeze2
 Severity: normal
 
 I've installed mapserver-bin, cgi-mapserver and php5-mapscript from aptitude. 
 when asking mapserv -v it appears SUPPORTS=AGG, but when I use DRIVER AGG 
 inside mapserver, I get an error saying AGG/PNG driver is not configured. I 
 found the error using geomoose 2.6

You have a different problem than the one reported for this bug. Version
5.6.5-2+squeeze2 does not contain the typo in debian/rules, see:

http://sources.debian.net/src/mapserver/5.6.5-2%2Bsqueeze2/debian/rules

In your case the problem may be that you need to specify DRIVER
AGG/PNG or DRIVER AGG/JPEG in your mapfile instead of only DRIVER AGG.

I don't have a squeeze VM at hand to reproduce your problem, and because
squeeze is oldstable now I recommend upgrading to wheezy if you're able.

An updated package for wheezy is in the works which fixes the typo in
debian/rules. MapServer 6.0.1 in wheezy may or may not fix your problem,
if it doesn't please file a new bug with relevant mapfile configuration
to reproduce the issue.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#718382: osgearth: Please recompile against OpenSceneGraph 3.2

[Sebastiaan Couwenberg]

Package: src:osgearth
Followup-For: Bug #718382
Control: fixed -1 osgearth/2.4.0+dfsg-4
Control: tags -1 pending

There was indeed a fix for OpenSceneGraph = 3.1.8 support in the
osgEarth upstream git:

http://anonscm.debian.org/gitweb/?p=pkg-grass/osgearth.git;a=commitdiff;h=fa3747cda6b533fc030d30fabbf7d8af77dad3ab

A build of osgEarth 2.4 with this fix and more has been uploaded to
mentors and waiting for a sponsor (#723175).

Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: [ftpmas...@ftp-master.debian.org: osgearth_2.4.0+dfsg-4_amd64.changes REJECTED]

[Sebastiaan Couwenberg]

Hi Andreas and Pirmin,

On 09/19/2013 10:04 AM, Andreas Tille wrote:
 Hi,
 
 hmmm, this came a bit unexpected from looking at the changelog.  From
 what I can see at
 
http://packages.debian.org/sid/osgearth
 
 there is no later version than
 
2.0+dfsg-4
 
 uploaded to Debian.  The changelog in Git is mentioning a *lot* of
 intermediate versions targeting at unstable but they are not.  Usually
 you should tag something that was not released as UNRELEASED or if
 you upload to some other target distribution (for instance to Ubuntu)
 you should use this (and use a versioning like
 
   2.4.0+dfsg-0ubuntu0
 
 or so.  Could you please clarify what *really* was uploaded before?
 I would like to sort this out first before I simply build using
 
 --debbuildopts -sa
 
 because I do not intend to upload with a missleading changelog.  In some
 sense the status at packages.debian.org is matching the tags 
 
 $ git tag | grep ^debian
 debian/1.3-3
 debian/1.3-4
 debian/1.4-2
 debian/1.4-3
 debian/1.4-4
 debian/1.4-5
 debian/1.4-6
 debian/1.4.1-1
 debian/2.0-1
 debian/2.0-2
 debian/2.0-4
 debian/2.0rc4-1
 debian/2.4-1
 
 Which means 2.1.1+dfsg-1 and 2.4-[23] are missing - no idea about
 2.4-1.  Pirmin, could you please shed some light into this?

Most outdated GIS packages in Debian are usually more actively
maintained in the UbuntuGIS PPA. osgEarth is no different.

Version 2.1.1+dfsg-1 was uploaded to the UbuntuGIS PPA, and is listed on
launchpad in ubuntugis-unstable for oneiric.

Version 2.4.0+dfsg-1 was uploaded to the UbuntuGIS PPA, and is listed on
launchpad in ubuntugis-unstable for precise.

Version 2.4.0+dfsg-2 is missing from the UbuntuGIS PPA, and was probably
never uploaded (anywhere public).

Version 2.4.0+dfsg-3 was uploaded to the UbuntuGIS PPA, and is listed on
launchpad in ubuntugis-unstable for precise and raring.

https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/+packages?field.name_filter=osgearthfield.status_filter=field.series_filter=

It's probably a good idea to rename the tags to ubuntu/version to
reflect the destination of the packaging. The two Debian releases can be
tagged debian/version

We can fix the changelog for Debian by appending ~ubuntu1 to the
versions which were only uploaded to the UbuntuGIS PPA. I've done this
for MapCache on advise from Francesco, because MapCache has so far only
been uploaded to the UbuntuGIS PPA.

 
 Kind regards
 
   Andreas.

Kind Regards,

Bas

 
 - Forwarded message from Debian FTP Masters 
 ftpmas...@ftp-master.debian.org -
 
 Date: Wed, 18 Sep 2013 21:50:11 +
 From: Debian FTP Masters ftpmas...@ftp-master.debian.org
 To: Debian GIS Project pkg-grass-devel@lists.alioth.debian.org, Bas 
 Couwenberg sebas...@xs4all.nl, ti...@debian.org
 Subject: osgearth_2.4.0+dfsg-4_amd64.changes REJECTED
 
 
 
 osgearth_2.4.0+dfsg-4.dsc refers to non-existing file: 
 osgearth_2.4.0+dfsg.orig.tar.gz
 Perhaps you need to include it in your upload?
 
 ===
 
 Please feel free to respond to this email if you don't understand why
 your files were rejected, or if you upload new files which address our
 concerns.
 
 
 ___
 Pkg-grass-devel mailing list
 Pkg-grass-devel@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
 
 
 - End forwarded message -
 


-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: [ftpmas...@ftp-master.debian.org: osgearth_2.4.0+dfsg-4_amd64.changes REJECTED]

[Sebastiaan Couwenberg]

Hi Andreas,

On 09/19/2013 02:49 PM, Andreas Tille wrote:
 On Thu, Sep 19, 2013 at 01:41:41PM +0200, Sebastiaan Couwenberg wrote:
 It's probably a good idea to rename the tags to ubuntu/version to
 reflect the destination of the packaging.
 
 Yes, please!
 
 The two Debian releases can be
 tagged debian/version
 
 Yes.
 
 We can fix the changelog for Debian by appending ~ubuntu1 to the
 versions which were only uploaded to the UbuntuGIS PPA. I've done this
 for MapCache on advise from Francesco, because MapCache has so far only
 been uploaded to the UbuntuGIS PPA.
 
 It would be great if you could fix this also for osgearth.

The ubuntu releases have their version appended with ~ubuntu1. The tags
are renamed, and the Debian tag for 2.0-4 there too. Although neither
the ubuntu nor the debian tag match the state of the source package for
2.0+dfsg-4 exactly. The current tagged commit is the closest.

 Thanks for the clarification
 
   Andreas.

Your welcome.

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: Bug#723980: libosgearth1: transitional package for shared library

[Sebastiaan Couwenberg]

Control: fixed -1 2.4.0+dfsg-5
Control tags -1 pending

Hi Andreas,

Thanks for your detailed explanation.

A fixed package has been uploaded to mentors and is waiting for
sponsorship (#723996).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#723979: libmapserver-6.2.1{, -dev}: transitional packages uninstallable

[Sebastiaan Couwenberg]

Hi Andreas,

Thanks again for you detailed explanation.

I've updated the package on mentors to drop the transitional packages
for the old libmapserver packages. Since there are no file conflicts the
Break/Replaces has also been removed from the libmapserver1 package.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: mapserver/6.4.0-2 (#723991) and osgearth/2.4.0+dfsg-5 (#723996)

[Sebastiaan Couwenberg]

Hi Francesco,

Can you sponsor the upload of mapserver/6.4.0-2 (#723991) and
osgearth/2.4.0+dfsg-5 (#723996)?

Both packages fix issues with transitional packages for the their shared
libraries (#723979 and #723980 respectively).

The mapserver update also includes a fix for #667771, and some changes
to support building MapCache with MapServer support.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#724259: mapserver: FTBFS: Could NOT find PerlLibs (missing: PERL_LIBRARY)

[Sebastiaan Couwenberg]

Hi Aaron,

Thanks for bringing reporting this. The problem was indeed the missing
build dependency on libperl-dev. I've successfully build the fixed
package in a i386 chroot.

The fixed package has been uploaded to mentors and is waiting for
sponsorship (#723991).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#667771: Please make use of new php5enmod and php5dismod commands in your package

[Sebastiaan Couwenberg]

Control: fixed -1 6.4.0-2
Control: tags 667771 pending

Hi Ondřej,

An updated mapserver package incorporating the php5enmod/php5sidmod
changes has been uploaded to mentors and is waiting for sponsorship
(#723991).

Kind Regards,

Bas

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

Bug#709186: mapserver: fails to build with ld that defaults to --as-needed

[Sebastiaan Couwenberg]

Dear Colin,

Is this bug still relevant?

In the mean time MapServer has been updated in Debian to 6.2.1 and
6.4.0. These build use -ldl already.

In Ubuntu saucy MapServer has been updated to 6.2.1-3, and should pull
in 6.4.0-2 from Debian.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#690884: qgis fails to access HDF-EOS datasets directly

[Sebastiaan Couwenberg]

Hi Ivan,

I've tried to reproduce your problem with QGIS 2.0.1, but I'm not able
to download the HDF file.

ftp://e4ftl01.cr.usgs.gov/MODIS_Composites/MOTA/MCD12Q1.005/2008.01.01/MCD12Q1.A2008001.h22v03.005.2011215183430.hdf

The FTP server claims to allow anonymous access with an email address as
password, but refuses login when done so.

Is there some HDF file publicly available with which I can reproduce
your problem?

If you don't mind building QGIS yourself, you can try building QGIS
2.0.1 from the pkg-grass git to see if it fixes your problem:

http://anonscm.debian.org/gitweb/?p=pkg-grass/qgis.git

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#688246: qgis fails to build on powerpc due to internal spatialite

[Sebastiaan Couwenberg]

Control: fixed -1 gqis/2.0.1-1
Control: tags -1 pending

This issue has been addressed in the updated QGIS package, which also
includes the latest upstream release.

The package has been uploaded to mentors and is waiting for sponsorship
(#724927).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#676562: [qgis] Ugly desktop icon

[Sebastiaan Couwenberg]

Control: fixed -1 gqis/2.0.1-1
Control: tags -1 pending

This issue has been addressed in the updated QGIS package, which also
includes the latest upstream release.

The package has been uploaded to mentors and is waiting for sponsorship
(#724927).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#713893: python-qgis: Couldn't load PyQGIS

[Sebastiaan Couwenberg]

Control: fixed -1 gqis/2.0.1-1
Control: tags -1 pending

This issue has been addressed in the updated QGIS package, which also
includes the latest upstream release.

The package has been uploaded to mentors and is waiting for sponsorship
(#724927).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#724873: New QGIS version available

[Sebastiaan Couwenberg]

Control: fixed -1 gqis/2.0.1-1
Control: tags -1 pending

Packaging for the new upstream release is pushed to the Debian GIS git,
and the updated package has been uploaded to mentors where it's waiting
for sponsorship (#724927).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#717052: qgis: Please add working watch file

[Sebastiaan Couwenberg]

Control: fixed -1 gqis/2.0.1-1
Control: tags -1 pending

This issue has been addressed in the updated QGIS package, which also
includes the latest upstream release.

The package has been uploaded to mentors and is waiting for sponsorship
(#724927).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#713644: spatialite-tools: FTBFS: ld: shell.o: undefined reference to symbol 'sqlite3_close'

[Sebastiaan Couwenberg]

Control: fixed -1 3.1.0b-2
Control: tags -1 pending

This issue has been fixed in the 4.1.1-1 package which will supersede
the 4.0.0-1 package in experimental. But the change to 4.x will require
a transition for which we're not quite ready yet.

In the the mean time I've prepared an updated package of 3.1.0 for
unstable which includes the fix from 4.1.1-1. The package has been
uploaded to mentors and is waiting for sponsorship (#725021).

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#504136: thuban: Changing map projections results in error

[Sebastiaan Couwenberg]

Control: found -1 1.2.2-3+b1

This issue is still present in the most current version.

I've not been able to reliable reproduce the error with the steps
provided in the original report, but something very similar.

My steps to reproduce the issue:

Select Map - Projection to open the Map Projection window.

Enter a random name, an select one of these projections:
- Unknown
- Transverse Mercator
- Lambert Conic Conformal
And click the Try button.

This will cause the error popup. Selecting another projection will not
cause the error popup.

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#309122: thuban: Fail to handle postgis with several geometry entries properly

[Sebastiaan Couwenberg]

Control: found -1 1.2.2-3+b1

This issue is still present in the current version in Debian.

While the table list only shows one entry, adding either of the geometry
columns triggers a traceback in the terminal thuban was started from:

Traceback (most recent call last):
  File /usr/lib/thuban/Thuban/UI/view.py, line 205, in _do_redraw
if self.render_iter.next():
  File /usr/lib/thuban/Thuban/UI/view.py, line 254, in _render_iterator
for cont in renderer.RenderMapIncrementally():
  File /usr/lib/thuban/Thuban/UI/baserenderer.py, line 191, in
render_map_incrementally
for i in self.draw_shape_layer_incrementally(layer):
  File /usr/lib/thuban/Thuban/UI/baserenderer.py, line 257, in
draw_shape_layer_incrementally
for shape in self.layer_shapes(layer):
  File /usr/lib/thuban/Thuban/Model/postgisdb.py, line 696, in
ShapesInRegion
srid: self.srid})
ProgrammingError: column gid does not exist
LINE 1: SELECT gid, AsText(center_point) FROM postal_codes WHE...
   ^
Traceback (most recent call last):
  File /usr/lib/thuban/Thuban/UI/view.py, line 205, in _do_redraw
if self.render_iter.next():
  File /usr/lib/thuban/Thuban/UI/view.py, line 254, in _render_iterator
for cont in renderer.RenderMapIncrementally():
  File /usr/lib/thuban/Thuban/UI/baserenderer.py, line 191, in
render_map_incrementally
for i in self.draw_shape_layer_incrementally(layer):
  File /usr/lib/thuban/Thuban/UI/baserenderer.py, line 257, in
draw_shape_layer_incrementally
for shape in self.layer_shapes(layer):
  File /usr/lib/thuban/Thuban/Model/postgisdb.py, line 696, in
ShapesInRegion
srid: self.srid})
ProgrammingError: column gid does not exist
LINE 1: SELECT gid, AsText(area) FROM postal_codes WHERE area...

Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: postgis: sid vs pgapt

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/02/2013 08:20 PM, Markus Wanner wrote:
 On 10/02/2013 08:19 PM, Alan Boudreault wrote:
 We'll do the change and push into the git repository. Is it ok?
 
 
 Not at the moment, please. We're in the middle of landing a rather
 huge renaming diff to fix upgrades. See my original mail.

Any objection to pushing it to an Ubuntu specific branch?

We have distribution specific branches in the MapServer repository for
example. Just don't push to master now.

Regards,

Bas

- -- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJSTGdlAAoJEGdQ8QrojUrxLV8P/R1xEpmZERlF7pcv77nKshD7
SguGjz/3IiS18tpoPiPiHLIg0n2bKpPaPQtoKSvMarw2N5rkpr7riTuSK0HwwUW8
6OJpjUlTgPUDJ/IA05ejqnczvox1z9AAfR7IqLzEuTPsUgidI56L6PlTRPkcFn9F
fJplfNBZhWJPvlFFockJ/ZllqqMvZ04sKWJIC9K/MDkPZ0EmV8fgoII09/zHKthS
WsvROzG/TA7+WkfKFzSrVlwvP2nGUScmTH2rMesFjRRuE6IEddeR5qCSCCVQxYID
2XFlxB+pQYZrO7ynpII3Wp7UWybj7nbZbk6O1qIohyqPBBlLMwxU3s/cdMUzNsWl
I+GGZQuE8C10CRae7EOzXdWJCwAvtW47cmHtOompc1X5c9j3rJSceFt7gplRDrXK
9e/XHR/0wru0VOWaRO602q8ztQi/6xhNNpkYBMvoArqx7YF7Iw89rCpibXuQwF70
B7rd43Ylu8sic2OMY8CF9NDgrq2f6/sKOPJR4mDU590x3pfFA0dylpU70eH6bg9N
pjI8BCLHA9auK2rRWXagCAiHAw+xXwcbdHQvFCCoHkylohazK/5K2Sqtv+Pjxmet
pxJFk/ucdtjUzDbsfe2REUaLhJk3BKbnBgke3eiydvHhJJNnEuzz4iN3Pwu8HWQC
1X6AOKncTO4WeAM7V2dU
=pZVS
-END PGP 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

Bug#725271: Affects experimental only at the moment

[Sebastiaan Couwenberg]

Control: tags -1 + experimental
Control: fixed -1 4.1.1-1

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

Bug#725271: Fixed in git for experimental

[Sebastiaan Couwenberg]

Control: notfixed -1 4.1.1-1
Control: fixed -1 1.1g-1

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

Bug#725267: spatialite: Build failures caused by fromgeojson22.testcase

[Sebastiaan Couwenberg]

Control: fixed -1 4.1.1-1
Control: tags -1 pending

Upstream has advised to disable this specific testcase, or address this
in sqlite's own sqlite3_mprintf().

For now disabling the testcase seems like the best option to allow a
transition for spatialite from experimental.

The testcase is disabled in the updated package available on mentors.

Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#722836: spatialite-tools link with -L/usr/lib

[Sebastiaan Couwenberg]

Control: fixed -1 3.1.0b-2

The current version in unstable use dh-autoreconf for retooling. Those
new builds no longer use -L/usr/lib.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#725383: FTBFS on kfreebsd-*: SYS_gettid is Linux-specific

[Sebastiaan Couwenberg]

Hi Steven,

On 10/04/2013 11:33 PM, Steven Chamberlain wrote:
 Hi,
 
 osgearth fails to build on kfreebsd-* because it tries to directly use a
 Linux-specific syscall:
 
 https://buildd.debian.org/status/package.php?p=osgearthsuite=sid
 cd /«BUILDDIR»/osgearth-2.4.0+dfsg/build/src/osgEarth  /usr/bin/c++   
 -DOSGEARTH_LIBRARY -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DTIXML_USE_STL 
 -DosgEarth_EXPORTS -g -O2 -fstack-protector --param=ssp-buffer-size=4 
 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC 
 -isystem /usr/include/qt4 -isystem /usr/include/qt4/QtGui -isystem 
 /usr/include/qt4/QtCore -I/«BUILDDIR»/osgearth-2.4.0+dfsg/src 
 -I/usr/include/gdal -I/usr/include/curl-o 
 CMakeFiles/osgEarth.dir/ThreadingUtils.cpp.o -c 
 /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp
 /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp: In function 
 'unsigned int osgEarth::Threading::getCurrentThreadId()':
 /«BUILDDIR»/osgearth-2.4.0+dfsg/src/osgEarth/ThreadingUtils.cpp:42:30: 
 error: 'SYS_gettid' was not declared in this scope
return (unsigned)::syscall(SYS_gettid);
   ^
 
 osgearth also knows how to use Windows and Mac OS X--specific syscalls
 to get a thread ID.  This is not portable and there is nothing directly
 equivalent on FreeBSD, see:
 http://lists.freebsd.org/pipermail/freebsd-hackers/2010-June/031992.html
 
 A workaround may be to use pthread_self(), except that the exported
 getCurrentThreadId function has to return 'unsigned int'.  On
 kfreebsd-amd64 a 64-bit pointer to a pthread_t is not absolutely
 guaranteed to be unique if truncated to 32 bits, but it is extremely
 likely, and certainly better than nothing...
 
 Please refer to attached patch which fixes package build at least.  Thanks!

Thanks for the patch.

Another option I've looked at is to use the undocumented thr_self(2)
syscall, this was recommended over pthread_self() on freebsd-hackers@:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-June/031991.html

The attached patch is what I was working on, but it breaks the build
even worse than without it.

I'll have another go at making my patch work, otherwise I'll apply your
patch to at least get the package to build. I had changed the package to
linux-any since upstream doesn't support FreeBSD, but that's not really
a fix for the problem.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
Index: osgearth/src/osgEarth/ThreadingUtils.cpp
===
--- osgearth.orig/src/osgEarth/ThreadingUtils.cpp	2013-10-05 00:21:18.0 +0200
+++ osgearth/src/osgEarth/ThreadingUtils.cpp	2013-10-05 01:02:46.0 +0200
@@ -23,6 +23,9 @@
 #else
 #   include unistd.h
 #   include sys/syscall.h
+#   if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#   include sys/thr.h
+#   endif
 #endif
 
 using namespace osgEarth::Threading;
@@ -39,6 +42,12 @@
 #elif __APPLE__
   return ::syscall(SYS_thread_selfid);
 #else
-  return (unsigned)::syscall(SYS_gettid);
+  if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+long lwpid;
+thr_self( lwpid );
+return (unsigned) lwpid;
+  else
+return (unsigned)::syscall(SYS_gettid);
+  endif
 #endif
 }
Index: osgearth/CMakeModules/FindFREEBSD_THR.cmake
===
--- /dev/null	1970-01-01 00:00:00.0 +
+++ osgearth/CMakeModules/FindFREEBSD_THR.cmake	2013-10-05 00:21:18.0 +0200
@@ -0,0 +1,14 @@
+execute_process(COMMAND uname -r OUTPUT_VARIABLE FREEBSD_KERNEL_RELEASE OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+set(FREEBSD_KERNEL_HEADERS_DIR /usr/src/kfreebsd-headers-${FREEBSD_KERNEL_RELEASE}/)
+
+FIND_PATH(FREEBSD_THR_INCLUDE_DIR
+  NAMES sys/thr.h
+  PATH_SUFFIXES sys
+  PATHS ${FREEBSD_KERNEL_HEADERS_DIR}
+)
+
+set(FREEBSD_THR_INCLUDE_DIRS ${FREEBSD_THR_INCLUDE_DIR})
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(FREEBSD_THR DEFAULT_MSG FREEBSD_THR_INCLUDE_DIR)
+mark_as_advanced(FREEBSD_THR_INCLUDE_DIR)
Index: osgearth/CMakeLists.txt
===
--- osgearth.orig/CMakeLists.txt	2013-10-05 00:21:18.0 +0200
+++ osgearth/CMakeLists.txt	2013-10-05 00:22:50.0 +0200
@@ -196,6 +196,12 @@
 
 #FIND_PACKAGE(GDAL)
 
+FIND_PACKAGE(FREEBSD_THR)
+
+if(NOT FREEBSD_THR_FOUND)
+message(FATAL_ERROR FreeBSD kernel header sys/thr.h could not be found and is a mandatory dependency)
+endif(NOT FREEBSD_THR_FOUND)
+
 
 # Create bin and lib directories if required
 
Index: osgearth/src/osgEarth/CMakeLists.txt
===
--- osgearth.orig/src/osgEarth/CMakeLists.txt	2013-10-05 00:21:18.0 +0200
+++ osgearth/src/osgEarth/CMakeLists.txt	2013-10-05 02:01:12.0 +0200

Bug#671894: libkml: FTBFS on hurd-i386

[Sebastiaan Couwenberg]

Control: fixed -1 1.3.0~r864-1
Control: tags -1 pending

Hi Pino,

Thanks for the patch! I've included it in the new libkml package. The
package has been uploaded to mentors, and is awaiting sponsorship (#725831).

Kind Regards,

Bas

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

Bug#692055: libkml: FTBFS with ld --as-needed

[Sebastiaan Couwenberg]

Control: fixed -1 1.3.0~r864-1
Control: tags -1 pending

Hi Ilya,

Thanks for the patches! I've included them in the new libkml package.
The package has been uploaded to mentors, and is awaiting sponsorship
(#725831).

Kind Regards,

Bas

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

Bug#725383: FTBFS on kfreebsd-*: SYS_gettid is Linux-specific

[Sebastiaan Couwenberg]

Control: fixed -1 2.4.0+dfsg-6
Control: tags -1 pending

Thanks for the advice. I've included both Stevens pthread patch, and an
adaptation of my thr_self patch incorporating the feedback. Updated
packaging is available in the Debian GIS git.

Building an updated package is complicated by the fact that osgearth
fails to build with pbuilder at the moment due to the libav9 transition
[1] which caused libopenscenegraph99 to become uninstallable (#722674,
#720816).

http://release.debian.org/transitions/html/libav9.html

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#577445: Addition version information

[Sebastiaan Couwenberg]

Control: found -1 gdal/1.6.3-2
Control: found -1 gdal/1.6.3-3
Control: found -1 gdal/1.6.3-4
Control: found -1 gdal/1.7.1-1
Control: found -1 gdal/1.7.2-1
Control: found -1 gdal/1.7.2-2
Control: fixed -1 gdal/1.7.3-1

Some analysis of the libgdal-doc versions available on
snapshot.debian.org shows that this issue was fixed much earlier.

Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#727630: Use dh_autotools-dev to update config.{sub, guess} for new ports

[Sebastiaan Couwenberg]

Hi Matthias,

Thanks for the patch.

The 4.1.1 upstream version of spatialite was uploaded to experimental
this week, the packaging uses dh-autoreconf for retooling which solves
the same problem as your patch.

Can you confirm that spatialite 4.1.1-2 builds correctly on arm64?

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#728785: libkml-java_1.3.0~r864-1: arch-dependent file in Multi-Arch: same package

[Sebastiaan Couwenberg]

Control: fixed -1 libkml/1.3.0~r864-2
Control: tags -1 pending

Hi Jenny,

Thanks for reporting this issue. The jar file contains SWIG generated
code that won't be byte-for-byte identical on different architectures.
So I've dropped the Multi-Arch same for the java bindings, which the
python don't have either. Only shared library and dev package are now
Multi-Arch: same.

An updated package is available on mentors, and currently waiting for
sponsorship (#729196).

Kind Regards,

Bas

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

Bug#729875: gdal: FTBFS: libxml/encoding.h: No such file or directory

[Sebastiaan Couwenberg]

Control: fixed -1 gdal/1.10.0-0~exp1

Roland, thanks for bringing this issue to our attention. And thanks for
the patch Michael.

The fix from upstream changeset r25197 is included in the GDAL 1.10.x
package currently in experimental. The transition from 1.9.0 to 1.10.1
should happen as soon as possible, see #712688.

I'm not sure if we should apply the patch for 1.9.0 package. It's
probably a good idea if this issue threatens the removal of GDAL from
testing before the transition.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#732413: Please update Recommends: for postgresql-9.3-postgis

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/17/2013 08:38 PM, Martin Pitt wrote:
 For wheezy we support PostgreSQL 9.3, and want to drop
 postgresql-9.1.

Do you really mean to drop postgresql-9.1 in wheezy, or did you mean
to write jessie?

 Can you please update the Recommends: from postgresql-9.1-postgis
 to postgresql-9.3-postgis?

I've updated dependency in the tasks file in git, it will be part of
debian-gis/0.0.3.

If you really mean to drop postgresql-9.1 in wheezy we'll need prepare
a debian-gis/0.0.2+deb7u1 for wheezy-proposed-updates.

Kind Regards,

Bas

- -- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJSsLTJAAoJEGdQ8QrojUrxDhgQAM8pHB1q+J3/jtDw/BrJs7fv
7VouRW0+yz8Um1DnhzooQN6ZP1VG/PNvfYmJ7+S1iewV1e+N8l36LLDWqcYmjpXL
0EWtApEpGndjRr78g4RrtEDh9iiqo7paQb4KNuXWd4nTap3A0oGiClk+NSvIwLhI
0/pzA9R5VdsCAIVogqnMarFi6Y5oxRTTaXiK+QgKBwghml/H5yoi/OReZmOGkOFm
oIMt8G4tgwiIlipqN3cvmFmVlQafn82iLZgo3jkIWs6xGru3G2TPslJuF7Ggkv4e
FGVh7uTPZ5mTCXwnfHQ1CrybhAYlBvHXiVql9YhPb8Kl8Y7jSCsyorjgP16Eem5Y
GtYJnqA8G0ivVOZukmhajfRTvEMXzS///7cfj6ZIjt9YCExr2/mQWdeHenll7Evg
E4lPxEN1e/uchnHE6d5lY9zWn84T1WOH2UkDmW+9yzcY3ExB2IsXuT6D/tYbuj2c
hcrSJ1zgypSThPgqzSYHFxBK/oOV1aisDsbDS8LL/hsr6Rg2ii5ChqJnttCfD33P
J6dT1hDKs6OlVL8GxA+Z+x41fJ+hWyZIDqHzOqREkHB/ytwQD/imFhydgRNtbsei
cgett/9qT3t5t/dK+/+cImJdRXKsxXyCsn/Eq/fEFkiYf7lKuexXgw1048vBf/GJ
hHE8Yd/HC/p1PCkGc2pZ
=k5y0
-END PGP 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

Re: [SCM] osm2pgsql branch, master, updated. debian/0.80.0+r27899-3-27-gacd6460

[Sebastiaan Couwenberg]

 On Tue, Dec 17, 2013 at 08:25:38PM +, Bas Couwenberg wrote:
  Recommends: postgis,
 -postgresql-9.1-postgis
 +postgresql-9.3-postgis-2.1

 IMHO here an OR statement would be better just to favor possible
 backports.

That may be a good idea as long as it doesn't conflict with the removal of
postgresql-9.1 from jessie (#732415) which was the trigger for this
change.

I just pushed a change to add the wheezy version back as an alternative.

Kind Regards,

Bas



___
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: Jessie and libgdal1

[Sebastiaan Couwenberg]

On 01/02/2014 04:36 AM, Sean Isley wrote:
 I have been trying to install QGIS via the directions on the official QGIS
 website, and I noticed it depends on a package that is not in jessie repos.
 Any ETA on when this will change?

The short answer is soon after the new OpenSceneGraph packages hit unstable.

For the long answer see:

https://lists.debian.org/debian-gis/2014/01/msg0.html
https://lists.debian.org/debian-gis/2013/12/msg00017.html

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#684233: tiff code embedded in gdal and possibly may be out of date and vulnerable

[Sebastiaan Couwenberg]

Control: fixed -1 gdal/1.9.2-1~exp3

Hi Silvio,

Since version 1.9.2-1~exp3 in experimental the GDAL packages no longer
expose the internal *tiff symbols, but still build with their internal
copies.

It doesn't entirely address the issue, but the recent updates of GDAL to
the latest 1.10.1 upstream release should include updates to the
internal libraries.

Can you run your tool on the latest gdal 1.10.1+dfsg-2 packages?

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: [SCM] mapcache tag, debian/1.2.1-1, created. upstream/1.2.0-107-gebc9794

[Sebastiaan Couwenberg]

On 01/04/2014 12:48 AM, Andreas Tille wrote:
 Please `git pull` and re-tag

Hi Andreas,

Thanks for the fixes and sponsoring the uploads.

I had already updated the jessie branches, and now also pushed the
updated tags.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: tinyows_1.1.0-3_amd64.changes REJECTED

[Sebastiaan Couwenberg]

On 01/04/2014 12:50 AM, Debian FTP Masters wrote:
 tinyows_1.1.0-3.dsc refers to non-existing file: tinyows_1.1.0.orig.tar.gz
 Perhaps you need to include it in your upload?

Hi Andreas,

Since the package originates from the UbuntuGIS PPA the first Debian
revision is not -1, and you need to explictly specify -sa when building
the package.

Can you rebuild the package with -sa?

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#695060: Fixed in gdal/1.10.1+dfsg-1

[Sebastiaan Couwenberg]

Control: fixed -1 gdal/1.10.1+dfsg-1

Hi Reid,

The recent gdal/1.10.1+dfsg-1 uploaded to unstable appears to have fixed
your issue. GDAL now recognizes the units correctly:

$ gdalinfo /tmp/foo.tif
Driver: GTiff/GeoTIFF
Files: /tmp/foo.tif
Size is 10, 20
Coordinate System is:
PROJCS[LUnits = unknown,
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.257223563,
AUTHORITY[EPSG,7030]],
AUTHORITY[EPSG,6326]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433],
AUTHORITY[EPSG,4326]],
PROJECTION[Miller_Cylindrical],
PARAMETER[latitude_of_center,0],
PARAMETER[longitude_of_center,0],
PARAMETER[false_easting,0],
PARAMETER[false_northing,0],
UNIT[unknown,100]]
Origin = (-20.015098236551182,-14.671436039695894)
Pixel Size = (2.001509823655118,2.934287207939179)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -20.0150982, -14.6714360) (179d59'59.64W, 89d59'24.00S)
Lower Left  ( -20.0150982,  44.0143081)
Upper Right (   0.000, -14.6714360) (  0d 0' 0.01E, 89d59'24.00S)
Lower Right (   0.000,  44.0143081)
Center  ( -10.0075491,  14.6714360) ( 89d59'59.82W, 89d59'24.00N)
Band 1 Block=10x20 Type=Float32, ColorInterp=Gray

$ listgeo /tmp/foo.tif
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
  ModelTransformationTag (4,4):
 2.00150982365512  0 0
-20.0150982365512
 0 2.93428720793918  0
-14.6714360396959
 0 0 0 0

 0 0 0 1

  End_Of_Tags.
   Keyed_Information:
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,10): Miller_Mm
  GeographicTypeGeoKey (Short,1): GCS_WGS_84
  GeogCitationGeoKey (Ascii,7): WGS 84
  GeogAngularUnitsGeoKey (Short,1): Angular_Degree
  GeogSemiMajorAxisGeoKey (Double,1): 6378137
  GeogInvFlatteningGeoKey (Double,1): 298.257223563
  ProjectedCSTypeGeoKey (Short,1): User-Defined
  PCSCitationGeoKey (Ascii,17): LUnits = unknown
  ProjectionGeoKey (Short,1): User-Defined
  ProjCoordTransGeoKey (Short,1): CT_MillerCylindrical
  ProjLinearUnitsGeoKey (Short,1): User-Defined
  ProjLinearUnitSizeGeoKey (Double,1): 100
  ProjFalseEastingGeoKey (Double,1): 0
  ProjFalseNorthingGeoKey (Double,1): 0
  ProjCenterLongGeoKey (Double,1): 0
  ProjCenterLatGeoKey (Double,1): 0
  End_Of_Keys.
   End_Of_Geotiff.

Projection Method: CT_MillerCylindrical
   ProjCenterLatGeoKey: 0.00 (  0d 0' 0.00N)
   ProjCenterLongGeoKey: 0.00 (  0d 0' 0.00E)
   ProjFalseEastingGeoKey: 0.00 m
   ProjFalseNorthingGeoKey: 0.00 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.00/  0d 0' 0.00E)

Corner Coordinates:
Upper Left( -20.015, -14.671)  (  0d 0' 0.65W,  0d 0' 0.47S)
Lower Left( -20.015,  44.014)  (  0d 0' 0.65W,  0d 0' 1.42N)
Upper Right   (   0.000, -14.671)  (  0d 0' 0.00E,  0d 0' 0.47S)
Lower Right   (   0.000,  44.014)  (  0d 0' 0.00E,  0d 0' 1.42N)
Center( -10.008,  14.671)  (  0d 0' 0.32W,  0d 0' 0.47N)

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#727630: Use dh_autotools-dev to update config.{sub, guess} for new ports

[Sebastiaan Couwenberg]

Hi Matthias,

The current 4.1.1-5 version of spatialite cannot be built on arm64
because of unmet build dependencies.

It seems the debhelper, perl and file builds for arm64 have some
circular build dependencies.

I'll keep an eye on buildd logs, because I'd still like to know if the
dh-autoreconf change is sufficient to support arm64.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: tinyows_1.1.0-3_amd64.changes REJECTED

[Sebastiaan Couwenberg]

On 01/04/2014 08:00 PM, Thorsten Alteholz wrote:
 unfortunately I have to reject your package.
 
 I am afraid that files under the OGC license are not allowed to enter main.
 Especially the paragraph:
  No right to create modifications or derivatives of OGC documents is granted  
   
  
  pursuant to this license. However, if additional requirements (documented
   
  
  in the Copyright FAQ) are satisfied, the right to create modifications or
   
  
  derivatives is sometimes granted by the OGC to individuals complying with
   
  
  those requirements. 
 does not comply with DFSG.

To my best understanding only the OGC Standards documents fall under the
OGC Document Notice.

http://www.opengeospatial.org/ogc/document

Schemas and software are covered by the OGC Software Notice.

http://www.opengeospatial.org/ogc/software

The debian/copyright did not reflect this correctly by only including
the standard OGC Document Notice which upstream includes as LICENSE
file, but not the Software Notice linked within it.

The first paragraph of the OGC Document Notice states that schemas and
software fall under the Software Notice:

 Public documents on the OGC site are provided by the copyright holders
 under the following license. The software or Document Type Definitions
 (DTDs) associated with OGC specifications are governed by the Software
 Notice.

The OGC Legal FAQ also explicitly states that schemas fall under the
Software Notice:

 1. Which statements apply to specifications, Web pages, and software?

 IPR Notice and Disclaimers [1] General web site copyright, trademark,
 and legal disclaimer statements. Document Notice [2] Information on
 reproducing OGC work including Adopted Implementation Standards,
 Abstract Specifications, and Recommendation Papers and other
 documentation.  Software Notice [3] Information on using and modifying OGC
 standards.

 [1] http://www.opengeospatial.org/ogc/policies
 [2] http://www.opengeospatial.org/ogc/document
 [3] http://www.opengeospatial.org/ogc/software

http://www.opengeospatial.org/ogc/legalfaq#Which

 5.10 Is a schema or document definition (DTD) covered by the document
 or software terms?

 Schemas (and DTDs) are frequently part of our specifications and
 seemingly fall under the document copyright terms [2]. However, as
 long as you do not use the same formal namespace or public identifier
 to identify that modified OGC schema/DTD (which might confuse
 applications), you may treat the schema/DTD under the software terms.
 [3] This means that you are permitted to make a derivative or modified
 OGC schema/DTD, but even under the software terms [3] you are
 obligated to include/retain the OGC copyright notice. We further
 appreciate a couple sentences regarding who made the modifications,
 when, and what changes were made in the original DTD -- a common
 software documentation practice.

 We expect to revisit this topic as metadata schemas become an
 increasingly important part of OGC specifications and as the metadata
 schema definition capabilities of XML and other XML technologies
 advance.

http://www.opengeospatial.org/ogc/legalfaq#DTD

The WFS tests are not explicitly mentioned as falling under the OGC
Software Notice. So it can be argued that because they are conformance
tests for the OGC Standards that OGC doesn't allow their modification.

On the other hand the conformance tests are intended to be included in
OGC compliant open source software, which is the reason for the more
liberal OGC Software Notice.

I've updated the packaging in the Debian GIS git repository to include
the OGC Software Notice and use it for the schemas and tests:

http://anonscm.debian.org/gitweb/?p=pkg-grass/tinyows;a=commitdiff;h=8f894dfa718f64fa71db745e166d741d414f0cbf#patch2


Do you consider the OGC Sofware Notice used in this change to comply
with the DFSG?

 So maybe you can move all OGC files to a non-free package? (Of course no
 package in main may depend on it ...)

If the OGC Software Notice is also considered non-free by DFSG
standards, or if the tests are not to be considered to fall under the
OGC Sofware Notice, I have little choice but to target (parts of)
TinyOWS for non-free.

   Thorsten

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org

Bug#734565: mapserver: CVE-2013-7262

[Sebastiaan Couwenberg]

On 01/08/2014 08:25 AM, Salvatore Bonaccorso wrote:
 If you fix the vulnerability please also make sure to include the
 CVE (Common Vulnerabilities  Exposures) id in your changelog entry.

The new mapserver packages were prepared before the CVE was available.

 Please adjust the affected versions in the BTS as needed, at least
 unstable from looking at source seems affected.

Unstable is no longer affect with the upload of mapserver 6.4.1, wheezy
and squeeze still are, but the proposed updates for both are waiting for
feedback from the release team:

Bug#734099:  pu: package mapserver/6.0.4-1
Bug#734118: opu: package mapserver/5.6.9-1

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#734565: Fixed versions

[Sebastiaan Couwenberg]

Control: fixed -1 mapserver/6.4.1-1
Control: fixed -1 mapserver/6.0.4-1
Control: fixed -1 mapserver/5.6.9-1
Control: tags -1 pending

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

Bug#734565: CVE for vulnerability now available: CVE-2013-7262

[Sebastiaan Couwenberg]

 On 2014-01-08 7:51, Sebastiaan Couwenberg wrote:
 Control: tags -1 security

 As reported by Salvatore Bonaccorso in #734565, there is now a CVE for
 the security issue in question.

 Can I get a Go/No Go for uploading the proposed changes in the debdiff?

 You proposed the changes four days ago, including relatively large
 diffs; please give people time to review / process them rather than
 chasing so quickly.

Sorry if my question was seen as chasing the Release Team. I'm not trying
to pressure the RT.

My question was triggered by the bug filed today now that the CVE is
available.

 As a side note, the diffs were sufficiently large that neither of your
 bug reports reached the debian-release list, so several people may not
 have seen them yet.

I was afraid the debdiffs might be a bit too large. So I think the wise
thing to do is to prepare security uploads which only fix the CVE issue if
possible, and leave the other security and stability fixes for a later
(old)stable-update if the complete upstream stable release is considered
acceptable.

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

Bug#734565: mapserver: CVE-2013-7262

[Sebastiaan Couwenberg]

Hi Salvatore,

On 01/08/2014 10:09 AM, Salvatore Bonaccorso wrote:
 On Wed, Jan 08, 2014 at 08:40:35AM +0100, Sebastiaan Couwenberg wrote:
 On 01/08/2014 08:25 AM, Salvatore Bonaccorso wrote:
 If you fix the vulnerability please also make sure to include the
 CVE (Common Vulnerabilities  Exposures) id in your changelog entry.

 The new mapserver packages were prepared before the CVE was available.

I've prepared new mapserver packages for squeeze and wheezy with only
the fix for this CVE, the new stable upstream release route I initially
took is not proper to fix this issue.

mapserver (6.0.1-3.2+deb7u2) for wheezy:

http://mentors.debian.net/debian/pool/main/m/mapserver/mapserver_6.0.1-3.2+deb7u2.dsc

mapserver (5.6.5-2+squeeze3) for squeeze:

http://mentors.debian.net/debian/pool/main/m/mapserver/mapserver_5.6.5-2+squeeze3.dsc

The squeeze package contained debhelper.log files in the debian/
directory, which caused problems for clean pbuilder builds so they were
removed. And dpatch insisted in changing the permissions. I've included
these changes in the squeeze package too.

 Please adjust the affected versions in the BTS as needed, at least
 unstable from looking at source seems affected.

 Unstable is no longer affect with the upload of mapserver 6.4.1, wheezy
 and squeeze still are, but the proposed updates for both are waiting for
 feedback from the release team:
 
 Could you clarify if second commit referenced in
 
 https://github.com/mapserver/mapserver/issues/4834
 (WFS-2 specific fixes for postgis time sql injections (#4834,#4815))
 
 is also needed? Is this relevant for Debian?

No, the WFS-2 specific commit shouldn't be relevant for Debian yet.

The vulnerability was discovered during the implementation of WFS 2.0
support in MapServer. That support only lives in the master branch for
now and will be included in the next major upstream release.

 Thanks for your work, and regards,
 Salvatore

If the security-team approves the package changes, shall I ask my
sponsor to upload the packages?

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: thuban_1.2.2-5_amd64.changes REJECTED

[Sebastiaan Couwenberg]

Hi Andreas,

On 01/11/2014 10:20 AM, Debian FTP Masters wrote:
 thuban_1.2.2-5.dsc refers to non-existing file: thuban_1.2.2.orig.tar.bz2
 Perhaps you need to include it in your upload?

Can you rebuild with -sa and reupload?

Mentors requires this for uploads, not sure why your build required the
orig tarball if you built from git. If you used the dsc from mentors
it's expected.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: gdal_1.10.1+dfsg-3_amd64.changes REJECTED

[Sebastiaan Couwenberg]

On 01/12/2014 11:48 PM, Debian FTP Masters wrote:
 gdal_1.10.1+dfsg.orig.tar.gz: Does not match file already existing in the 
 pool.

It looks like the initial gdal_1.10.1+dfsg.orig.tar.gz was not checked
out from the pristine-tar branch.

I downloaded the orig.tar.gz from snapshot.debian.org, and compared it
them to one checked out by pristine-tar, the pristine-tar one doesn't
contain the .gitignore file.

Now I wonder if it makes sense to fix the pristine-tar branch to  use
the tarball as uploaded to the archive. I think it does, because the
upstream tarball also contains the .gitignore file.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: gdal_1.10.1+dfsg-3_amd64.changes REJECTED

[Sebastiaan Couwenberg]

On 01/13/2014 11:26 PM, Andreas Tille wrote:
 On Mon, Jan 13, 2014 at 09:13:39PM +0100, Sebastiaan Couwenberg wrote:
 Just as a side note I use git-buildpackage for all packages in d-gis tree.

 Further investigation shows that a missing --pristine-tar was not the cause.

 My commit of the new upstream version deleted the .gitignore file, while
 it is included in the upstream tarball and not touched by the repacking.

 http://anonscm.debian.org/gitweb/?p=pkg-grass/gdal.git;a=commitdiff;h=864bb9ee6237551dc25377be642bf59cb6c48644

 Adding the .gitignore file back to the upstream branch makes the
 pristine-tar checkout tarball identical to the one in the archive.
 
 I have checked out the original source via `apt-get source gdal` and
 I get:
 
 $ md5sum gdal_1.10.1+dfsg.orig.tar.gz 
 65f908560558b4801daa6946e52a03a6  gdal_1.10.1+dfsg.orig.tar.gz
 
 
 If I'm using the pristine-tar from the git repository I get:
 
 $ md5sum gdal_1.10.1+dfsg.orig.tar.gz 
 d4960006e29570a8e5c0c8824f7c725c  gdal_1.10.1+dfsg.orig.tar.gz
 
 
 (File size is different as well.)
 
 So something remains wrong here.

Correct. I was comparing the wrong file, and rejoiced prematurely.

This looked good, but wasn't the orig.tar.gz checked out by
pristine-tar, that lived in /tmp :(

65f908560558b4801daa6946e52a03a6  gdal_1.10.1+dfsg.orig.tar.gz
65f908560558b4801daa6946e52a03a6  gdal_1.10.1+dfsg.orig.tar.gz.archive
d4960006e29570a8e5c0c8824f7c725c  gdal_1.10.1+dfsg.orig.tar.gz.pristine

I've commited the orig.tar.gz from the archive in the pristine-tar
branch, checking that out does work.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#735828: spatialite: FTBFS: Tests failures

[Sebastiaan Couwenberg]

Control: fixed -1 spatialite/4.0.0-1

Hi David,

Thanks for reporting this issue.

I can reproduce the build failure with 3.1.0~rc2-2, but not with 4.0.0-1
and up.

The 4.x versions of SpatiaLite were only uploaded to experimental, where
the updated packages for SpatiaLite 4.1.1 are currently waiting for a
transition slot (#731402  #731403).

I'm tempted to disable the failing tests in 3.1.0~rc2-2 to not risk
having the package removed from testing, but these tests succeeded
before so a regression has been introduced by one or more of the
dependencies.

The root cause of the test failure I've not been able to track down yet,
I'm still reviewing the changes for the failing testcases since
3.1.0-rc2. I'll try to backport the changes for an interim update of
spatialite in unstable while we wait for the 4.1.1 transition.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#735828: spatialite: why not transition?

[Sebastiaan Couwenberg]

On 01/18/2014 08:25 PM, Rebecca N. Palmer wrote:
 Now that openscenegraph is fixed (and assuming the new qgis builds),
 what is now blocking the spatialite transition (which would fix this and
 #688328)?

There is nothing really blocking the SpatiaLite transition, we're mostly
waiting for the Release Team.

But ideally we finish the GDAL transition first, because GDAL will need
a binNMU for SpatiaLite 4.1.1.

We still need a rebuild of osmium and libcitygml to depend on libgdal1h.
The latter is now possible with the fixed OpenSceneGraph packages.

The OpenSceneGraph packages are not fully fixed, because it FTBFS on
hurd-i386 and ia64.

https://release.debian.org/transitions/html/gdal.html

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

___
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: ossim-1.8.16 - request for review

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Markus,

Thanks for working on the OSSIM package!

On 01/29/2014 10:47 PM, Markus Wanner wrote:
 as recently discussed on IRC, I took a stab at upgrading ossim to
 a current release. Attached is a patch against the svn repo (do I
 have commit access to that, given that IIRC I'm a member of
 pkg-grass-devel?).

You're a member of the pkg-grass team, and you should therefor have
commit access to both the Git and SVN repos.

Most of the Debian GIS packages are maintain in Git now, OSSIM is one
of the few remaining package still in SVN.

Would you be willing to move the OSSIM package from SVN to Git?

 Please review and comment whether or not you agree with the
 general direction.

If I may propose a wishlist item, move from CDBS to dh for more
uniformity with the other Debian GIS packages.

 
 Some comments and lose ends: - lintian complains about hardening
 issues, looks like I don't properly pass the LDFLAGS through cmake,
 yet.

It's probably sufficient to add CPPFLAGS to CFLAGS in debian/rules to
have the build use -D_FORTIFY_SOURCE=2, which I assume is the
hardening issue lintian reports.

lintian uses hardening-check to verify the hardening flags, and the
hardening-no-fortify-functions check has some false-positives. If
that's the case you can add a lintian override with the comment
containing the hardening-check verbose output, e.g.:

# -D_FORTIFY_SOURCE=2 is used during build, but hardening-check reports:
#  Fortify Source functions: yes (some protected functions found)
#unprotected: memset
#protected: sprintf

 - I dropped the static library build for now. How important is
 that? - ossim-config isn't built, anymore, nor is there an ossim.pc
 (for pkg-config)

I'm not sure about the above. Hopefully Francesco can shed some more
light on this.

 - I didn't do any testing of the resulting library or utilities,
 but am happy it builds at all, for now.

It's a good thing it builds, nice work!

There don't seem to be any reverse dependencies in Debian that need to
be taken into account. Maybe we have some users of OSSIM lurking on
debian-gis@ or subscribed to the PTS that may be able to help you get
some real world tests of your updated package.

Kind Regards,

Bas

- -- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJS6YwRAAoJEGdQ8QrojUrxKCgP/R+z/jDHRQXasfbLLg+Nsh4p
vPlRrzAfGP+AuaaHh8WMnLNe1PRQP1TLfoKXFSzA+WchnCh6p63MPTiDwgXEMq74
5Q0KNMB6yRM6ozoPw/vZ5nC0TvDqnb2zVumpjKW8huP8MQcye8ngarsSHh0OFEyw
moDnc3DV7A+B2R+6bE85xyArZB+6Am9fuMyRmC3nxTiuM8gVLZOvlYmfBH8iQfs9
ompuGDg5SWS1hpd2TLRuAvmmq7JRaOsuD2/uI0oHggFVLdY/qXUZnflqfIMVFG1/
8Rnn3ycmOq1Tz0ZD2lCVbVyAqaq9VHDTTaGE3HX03V02/Lm72oFBci8YXRCEVl4C
t3du31fU4sNuVP+RkkwE+tjmryvfdaKPulbG8kqFxyt5cdPaChvUyTi0cTmVHpEC
Fthmyn1DWOif8pHRe2zJ+lu6g+RVPIG7RMLb3uE4sZCyuquWHLxLUSe7RDcEpjKa
pOm0AgND2udaoEXGe1K3Bxr/HoqB/UVNBcslO6Jd2gWdsSHZ/4hVVSGHx00GURNG
4Cz8OFzTkia0iGv8AUMATtINsnwPqG75eylYm920ePCwDqh9jgBmXmVio/Ms8jFS
HJQFuHJjYstfCz/A3qNXxf+mQPaah5JO7WX75oFpEH+v9JzDbcVpDmlJ0SAP8jJH
Hd4zPHZEbQS3W8HUbYLE
=CJ9l
-END PGP 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

Bug#735516: python-liblas: hardcoded dependency on liblas1 which is no longer built by liblas

[Sebastiaan Couwenberg]

Hi Sebastian,

Thanks for reporting this issue.

Upstream version 1.6.0 is available at pypi, but liblas has version 1.7.0.

It looks like the python directory from liblas is repackaged for pypi,
the code for version 1.6.0 is identical, the python directory in liblas
has additional tests and examples and no egg-info.

I think the wise choice is to build python-liblas from the liblas source
package instead of maintaining the pypi based pyton-liblas source
package separately. So they will be updated together in the future.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#735516: python-liblas: hardcoded dependency on liblas1 which is no longer built by liblas

[Sebastiaan Couwenberg]

Hi Graham,

On 02/03/2014 05:52 PM, Graham Inggs wrote:
 The attached patch to src:liblas builds the python-liblas package as well.
 I haven't done extensive testing, but it builds in my Ubuntu PPA and
 seems to produce debs with all the correct files in place.

Thanks for the patch!

I've been working on a similar patch, so I'll try to merge your changes
to get the best of both worlds.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#735516: python-liblas: hardcoded dependency on liblas1 which is no longer built by liblas

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi,

On 02/04/2014 07:25 PM, Sebastiaan Couwenberg wrote:
 On 02/03/2014 05:52 PM, Graham Inggs wrote:
 The attached patch to src:liblas builds the python-liblas package as well.
 I haven't done extensive testing, but it builds in my Ubuntu PPA and
 seems to produce debs with all the correct files in place.
 
 Thanks for the patch!
 
 I've been working on a similar patch, so I'll try to merge your changes
 to get the best of both worlds.

The updated liblas source package which now also builds the
python-liblas binary package is available in the Debian GIS git repository:

http://anonscm.debian.org/gitweb/?p=pkg-grass/liblas.git

The package is also uploaded to mentors, but I won't request sponsorship
until the python-liblas source package is removed from unstable. (#738141)

Kind Regards,

Bas

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

Bug#738273: qgis-providers-common: fails to install, should use triggers for crssync

[Sebastiaan Couwenberg]

Hi Andreas,

Thanks for reporting this issue.

The srs.db provided by qgis-providers-common is updated by crssync
included in qgis-providers.

Because qgis-providers depends on qgis-providers-common, the common
package will be configured first, and I think this will prevent the
trigger in qgis-providers from running because that hasn't been
installed yet.

I've updated the qgis-providers-common.postinst to execute
`dpkg-trigger qgis-crssync` instead of `/usr/lib/qgis/crssync`,
added interest qgis-crssync in qgis-providers.triggers, and added
handling for the qgis-crssync named trigger in qgis-providers.postinst.

When I upgrade the the qgis 2.0.1-1 packages currently in unstable to
2.0.1-2 from my local repo the triggers are never run.

The trigger is only run when I `dpkg -i`
qgis-providers-common_2.0.1-2_all.deb from the apt archives cache after
wards.

Using a file based trigger on the srs.db may be an option, then we'll
need to watch for changes to /usr/share/qgis/resources/srs-template.db
which will be installed by dpkg whereas the srs.db is created from it in
the postinst to fix #738117.

I haven't tried the file based trigger yet, nor have I pushed my changes
thus far because they don't fix the issue just yet. The trigger changes
are included in the attached debdiff. I'll experiment with the file
based trigger to see if that works.

Kind Regards,

Bas
diff -Nru qgis-2.0.1/debian/changelog qgis-2.0.1/debian/changelog
--- qgis-2.0.1/debian/changelog 2014-01-18 03:34:17.0 +0100
+++ qgis-2.0.1/debian/changelog 2014-02-09 16:52:22.0 +0100
@@ -1,3 +1,25 @@
+qgis (2.0.1-2) UNRELEASED; urgency=low
+
+  [ Peter Michael Green ]
+  * Fix broken ARM patch by Konstantinos Margaritis.
+  * Fix qreal vs double issues with qmin and qmax.
+
+  [ Jürgen E. Fischer ]
+  * run crssync on copy of srs.db
+(closes: #738117)
+
+  [ Bas Couwenberg ]
+  * Additional checks in qgis-providers-common.postinst 
+  * Add patch to fix mis-detection of PostGIS table types.
+  * Add patch to not look for topology layers without topology support.
+  * Add patch to fix postgis topology availability detection query.
+  * Enable parallel builds.
+  * Add patch to disable features on ARM.
+  * Add qgis-crssync dpkg trigger to run crssync after installing the srs.db.
+(closes: #738273)
+
+ -- Bas Couwenberg sebas...@xs4all.nl  Fri, 31 Jan 2014 19:42:03 +0100
+
 qgis (2.0.1-1) unstable; urgency=low
 
   [ Jürgen E. Fischer ]
diff -Nru qgis-2.0.1/debian/patches/disable-features-on-arm.patch 
qgis-2.0.1/debian/patches/disable-features-on-arm.patch
--- qgis-2.0.1/debian/patches/disable-features-on-arm.patch 1970-01-01 
01:00:00.0 +0100
+++ qgis-2.0.1/debian/patches/disable-features-on-arm.patch 2014-02-09 
12:53:16.0 +0100
@@ -0,0 +1,66 @@
+Description: Disable troublesome features on ARM.
+ Building QGIS on ARM produces the error:
+
+ sip: qgis/python/core/qgsclipper.sip:44: \
+ QgsClipper::trimFeature() unsupported function argument type - provide 
%MethodCode and a C++ signature
+
+ In the upstream git repository this and other functions are disbled for
+ Android builds which have the same problems:
+
+ https://github.com/qgis/QGIS/commit/2cc684793ceb29d8600d71564fb38f92c998f588
+
+Author: Bas Couwenberg sebas...@xs4all.nl
+Bug-Debian: http://bugs.debian.org/737814
+
+--- a/python/core/qgsclipper.sip
 b/python/core/qgsclipper.sip
+@@ -1,3 +1,5 @@
++%Feature ARM
++
+ class QgsClipper
+ {
+ %TypeHeaderCode
+@@ -34,6 +36,7 @@ class QgsClipper
+ // A handy way to refer to the four boundaries
+ enum Boundary {XMax, XMin, YMax, YMin};
+ 
++%If (!ARM)
+ // Trims the given feature to a rectangular box. Returns the trimmed
+ // feature in x and y. The shapeOpen parameter determines whether
+ // the function treats the points as a closed shape (polygon), or as
+@@ -41,7 +44,7 @@ class QgsClipper
+ static void trimFeature( QVectordouble x,
+  QVectordouble y,
+  bool shapeOpen );
+-
++%End
+ static void trimPolygon( QPolygonF pts, const QgsRectangle clipRect );
+ 
+ /**Reads a polyline from WKB and clips it to clipExtent
+--- a/python/core/composer/qgscomposerscalebar.sip
 b/python/core/composer/qgscomposerscalebar.sip
+@@ -104,9 +104,11 @@ class QgsComposerScaleBar: QgsComposerIt
+ /**Returns style name*/
+ QString style() const;
+ 
++%If (!ARM)
+ /**Returns the x - positions of the segment borders (in item coordinates) 
and the width
+  of the segment*/
+ void segmentPositions( QListQPairdouble, double  posWidthList ) 
const;
++%End
+ 
+ /**Sets box size suitable to content*/
+ void adjustBoxSize();
+--- a/python/CMakeLists.txt
 b/python/CMakeLists.txt
+@@ -72,6 +72,10 @@ IF(PYQT4_VERSION_NUM LESS 264196)
+   SET(SIP_DISABLE_FEATURES ${SIP_DISABLE_FEATURES} QLISTCONSTPTR_CONVERSION)
+ ENDIF(PYQT4_VERSION_NUM LESS 264196)
+ 
++IF(CMAKE_SYSTEM_PROCESSOR MATCHES ^arm)
++  

Bug#737814: qgis ftbfs on arm* qreal vs double issues

[Sebastiaan Couwenberg]

Hi Peter,

Thanks for working on the QGIS patches for ARM.

I've included your changes are included in the updated qgis package.

I'm currently experimenting with a patch to disable the troublesome
functions on ARM as upstream has done in their master branch for their
Android builds.

The patch doesn't quite work just yet, so I need to hack a bit more on
it before I can get a fixed package uploaded.

I sent a debdiff of the current work in process qgis package to #738273
which includes the ARM related changes too.

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=qgis_2.0.1-2.debdiff;att=1;bug=738273

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#738273: qgis-providers-common: fails to install, should use triggers for crssync

[Sebastiaan Couwenberg]

On 02/10/2014 12:08 AM, Andreas Beckmann wrote:
 On 2014-02-09 22:52, Sebastiaan Couwenberg wrote:
 When I upgrade the the qgis 2.0.1-1 packages currently in unstable to
 2.0.1-2 from my local repo the triggers are never run.
 
 I'll take a look.
 Is the debdiff you sent also already in git somewhere? That would make
 it easier for me to experiment.

Yes, the changes are in my personal git repo for the time being.

I heavily rebase this repo before pushing the changes to Alioth, so it's
not the best repo to clone from. Pulling updates won't work most of the
time.

http://git.linuxminded.nl/?p=pkg-grass/qgis

 As I have no idea what your packages do, please give me a bit more
 information about /usr/lib/qgis/crssync. It updates a srs.db - where
 does it look for input files? hardcoded directory(ies) (which?) or
 from config file (which?)

The srs.db is updated with the CRS data from GDAL and PROJ.4. crssync
uses the csv and wkt files shipped in libgdal1h:

 /usr/share/gdal/1.10/gcs.csv
 /usr/share/gdal/1.10/pcs.csv
 /usr/share/gdal/1.10/vertcs.csv
 /usr/share/gdal/1.10/compdcs.csv
 /usr/share/gdal/1.10/geoccs.csv

 /usr/share/gdal/1.10/epsg.wkt (the wkts it includes no longer exist)

The paths are not hardcoded, only the file basename is. The full path is
looked up using CPLFindFile() which is a function from libgdal.

From reading the source (QgsCoordinateReferenceSystem::syncDb() in
src/core/qgscoordinatereferencesystem.cpp),
http://hub.qgis.org/issues/5282 where crssync is added to
qgis-providers-common.postinst, and http://hub.qgis.org/issues/3645
where crssync was initially introduced, it also uses the EPSG list from
Proj.4 via the proj API.

 /usr/share/proj/epsg

The EPSG list from Proj.4 is included in proj-data which is a dependency
of libproj0.

I chose to go with the named trigger first because I envision the gdal
and proj4 packages to activate this trigger too in their postinst when
their data is updated.

Kind Regards,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Bug#737814: qgis ftbfs on arm* qreal vs double issues

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Peter,

The patch to disable the troublesome functions on ARM is fixed. QGIS now
successfully builds on armhf.

I've uploaded the updated qgis package to mentors, and requested
sponsorship (#739029).

Kind Regards,

Bas

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

Bug#738117: qgis: modifies shipped files: /usr/share/qgis/resources/srs.db

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Andreas,

The updated qgis package available on mentors and waiting for
sponsorship (#739029).

After I first built the updated package, I noticed that upstream had
fixed this issue separately in their master branch:

https://github.com/qgis/QGIS/commit/f06e72efcd2de347be6918a2ff278f17dc8a0b0c

I've merged the changes from upstream in:

http://anonscm.debian.org/gitweb/?p=pkg-grass/qgis.git;a=commitdiff;h=4b92f01ecd1a903112502fbc96456b90414653d0

Together with the changes for #738273 the issues relating to the srs.db
are now fixed.

Thanks for your assistance with these issues.

Kind Regards,

Bas

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

Bug#735516: python-liblas: hardcoded dependency on liblas1 which is no longer built by liblas

[Sebastiaan Couwenberg]

Hi Peter,

On 02/20/2014 04:17 PM, peter green wrote:

 The package is also uploaded to mentors, but I won't request sponsorship
 until the python-liblas source package is removed from unstable.
 (#738141)
   
 I've just spoken to a memeber of the ftp team on irc and you have this
 backwards, the normal thing to do is to upload the package doing the
 takeover first, then cleanup the old source package.

Thanks for this information. The devref and related documentation is not
quite clear about this.

I've just requested sponsorship of liblas (#735516).

Kind Regards,

Bas

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

Bug#739773: mapserver: Please support building with Ruby 2.0

[Sebastiaan Couwenberg]

Hi Christian,

Thanks for reporting this issue.

On 02/22/2014 01:54 PM, Christian Hofstaedtler wrote:
 A new ruby-defaults, switching the default Ruby version to 2.0, will be
 uploaded soon. (It is available in experimental for testing.)
 
 During a test rebuild of rdepends with the new package, your package
 failed to build.
 
 If possible, please change your package in advance to support building
 for Ruby 2.0, so when ruby-defaults is uploaded, only a binNMU is
 needed.

Supporting Ruby 2.0 is not straight forward. The FindRuby.cmake shipped
with CMake 2.8 doesn't search for Ruby 2.0 yet, so we'll need to at
least include a custom FindRuby.cmake in MapServer similar to the one
included in mod_ruby for instance:

https://github.com/mikeowens/mod_ruby/blob/master/config/ruby.cmake

The mapscript binding for Ruby doesn't have an upstream maintainer
anymore, so to keep supporting it in Debian may become too burdensome.

I'll try to fix the build with Ruby 2.0 using the packages from
experimental.

Kind Regards,

Bas

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

Bug#739773: mapserver: Please support building with Ruby 2.0

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 pending

Hi Christian,

On 02/22/2014 11:56 PM, Christian Hofstaedtler wrote:
 * Sebastiaan Couwenberg sebas...@xs4all.nl [140222 19:40]:
 Supporting Ruby 2.0 is not straight forward. The FindRuby.cmake
 shipped with CMake 2.8 doesn't search for Ruby 2.0 yet, so we'll
 need to at least include a custom FindRuby.cmake in MapServer
 similar to the one included in mod_ruby for instance:
 
 https://github.com/mikeowens/mod_ruby/blob/master/config/ruby.cmake

 
 I've filed #739826 against cmake, hopefully the cmake maintainer
 can fix this in a central place.

Thanks for filing the cmake bug, hopefully the custom FindRuby.cmake
now included in mapserver is only needed for a short time.

Instead of including an entirely different CMake module for Ruby, I've
updated the FindRuby module included in CMake to also support Ruby 2.0
and 2.1. See:

http://anonscm.debian.org/gitweb/?p=pkg-grass/mapserver.git;a=blob;f=debian/patches/cmake-ruby2.patch;h=a43bb4a0d76da5754351f60d6d5ed238af6e4bcb;hb=8251b4527cfaf1821a522afee84245a4768df2a3

I'll forward it to CMake upstream so they can include the changes in
the next release.

The update mapserver package is available on mentors, and currently
waiting for sponsorship (#740344).

Kind Regards,

Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJTEIgYAAoJEGdQ8QrojUrxKXoP/14Jj+aacCMI+nUOR53iZ+T1
vtLsOWmo3IUWzzaURWSuGUyqqQTh8Oqjcb1LMCIo3k+czsL2COySXAI5lCQSZvE1
ZoEod+9oJ60NG+Ex1F39k1JeH9ic9q/OPWkKrku3keIzZLDb94roc0s0iwEznHYR
YjIrMhwVHPzgdvWl4RTPcNwvNNeetVd5HMJMH2kgY2xb679Cj1UGEwK5p6+805zY
/Li/XHc4tjTaYWCQYztPjrAEFNXho/sW5+FnjbfBjz9fPNGqTQp4aPSKdEA3Pkgy
/hBgVTHk4dEpdbuH+iu7qisXtVz2Z0TjbQxwqgG5qSjHlADGYN6MuUmvMKqWOmXV
b98rKdH83MUCDjXEl9eG7gNkMdk3p2bnVkJrv3Husn4Ca2rpb1cZGbi/KyuTD/ul
hqbn1IRwIyLZWaIIjZYz6eJzerewpBb6EiHuV5khvqjpJ5v9G1gxCzo/zxE94lH3
VKKzodOmM7X0ntxYrIB2ozSED9UDsCVxE2GtNiUiRIDea9/3xgTPN141SNCUZTnb
gaSIMjuth20UiBIvL8Sj3OyhU9ZPDWeOD2+NoE9Zp62IXRxieOGkuTFUXWLwtcdq
5GyfmHXVZAqcnoQRCF7u8sjg3xqwN9vtBLF9S/QwsDzEEk231uPA+Sp9tFO2zTqw
xbW+KwpOdD12pxFJE+zg
=R8oA
-END PGP 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

Bug#740327: libapache2-mod-mapcache: unowned directory after purge: /var/cache/mapcache/

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Andreas,

Thanks for reporting this issue.

I've fixed the package in git by having debhelper manage the directory.

http://anonscm.debian.org/gitweb/?p=pkg-grass/mapcache.git;a=commitdiff;h=c696bcc727ecc173eadf9b77aa9e566373f49f20

The fixed package is available on mentors, where it's currently waiting
for sponsorship (#740376).

Kind Regards,

Bas

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

Bug#740351: mapserver: Please enable mapscript java bindings

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Ezequiel,

Thanks for the patch. I've incorporated it in the updated mapserver
packging in git.

http://anonscm.debian.org/gitweb/?p=pkg-grass/mapserver.git;a=commitdiff;h=85e0c99fafbd7ce868ae860a19e67a820572cfdf

Because mapserver 6.4.1-2 was uploaded earlier today, I don't want to
uploaded it again just for this change. I'll leave it in git for now,
and at least wait for -2 to migrate to testing.

Kind Regards,

Bas

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

Bug#740610: qgis: Fails to load Python

[Sebastiaan Couwenberg]

Hi Paolo,

On 03/03/2014 04:17 PM, Paolo Cavallini wrote:
 Just finished and cleaned up my installation from exp. [...]
 ===
 I then get an error:
 ===
 Couldn't load PyQGIS.
 Python support will be disabled.
 
 
 Traceback (most recent call last):
   File , line 1, in
 ImportError: No module named qgis.core
 
 [...]
 ===
 In fact, something should be wrong:
 ===
 # deborphan
 libqgispython2.2.0
 libqgissqlanyconnection2.2.0
 ===
 Hope this helps.
 Thanks.
 
 [...]
 
 Versions of packages qgis recommends:
 pn  python-qgisnone
 ii  qgis-plugin-globe  2.2.0-1~exp1
 ii  qgis-plugin-grass  2.2.0-1~exp1

libqgispython2.2.0 only gets installed as a dependency of python-qgis,
but this package is not installed on your system.

Installing python-qgis should fix your issue.

python-qgis is installed as a dependency of qgis by default unless
you've disabled automatic installation of Recommends in apt.

But when you install the 2.2.0-1~exp1 packages from experimental while
already having the 2.0.1-2 packages from unstable installed,
python-qgis is not automatically upgraded.

The experimental repository is marked as NotAutomatic in the Release
file, so you need to explicitly install packages from experimental.

We can force the upgrade of python-qgis together with qgis by
recommending the same version as qgis, but that is only relevant for
experimental. Once QGIS 2.2 hits unstable the 2.0 packages from unstable
will all be upgraded.

Kind Regards,

Bas

___
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: Bug#740982: liblas does not build

[Sebastiaan Couwenberg]

Hi Andreas,

Thanks for sponsoring the upload.

The fixed boost1.54 packages wasn't built and installed yet on the mips
buildd. I sent a give-back request sortly after boost1.54 was installed
on the buildd, and it just finished building liblas on mips too.

Kind Regards,

Bas

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


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

Bug#741242: libgeos-3.3.3: Linking against libgeos fails

[Sebastiaan Couwenberg]

Hi Tobias,

 I was trying to compile matplotlib basemap
 (http://sourceforge.net/projects/matplotlib/files/matplotlib-
 toolkits/basemap-1.0.7/) which depends on libgeos.
 The compilation fails because matplotlib basemap tries to link against
 libgeos.so but in /usr/lib only libgeos-3.3.3-so is present.

 When manually creating a link (sudo ln -s /usr/lib/libgeos-3.3.3.so
 /usr/lib/libgeos.so), the compilation/linking works without problems.

 I think during installation this link should be created.

Creating library symlinks manuall is seldomly a good idea.

libgeos-3.3.3.so is the C++ library, linking against this is discouraged.
Applications should like to the C API (libgeos_c.so) which is considered
stable.

In de documentation for mathplotlib basemaps they document linking to the
C API:


If you already have it on your system, just set the environment variable
GEOS_DIR to point to the location of libgeos_c and geos_c.h (if libgeos_c
is in /usr/local/lib and geos_c.h is in /usr/local/include, set GEOS_DIR
to /usr/local).


See: https://github.com/matplotlib/basemap

Please try the above procedure to build mathplotlibs basemap with the GEOS
C API. You may need to install libgeos-c1 if it's not already installed.

Kind Regards,

Bas

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

Bug#742149: mapnik: FTBFS on mipsen (virtual memory exhausted)

[Sebastiaan Couwenberg]

On 03/19/2014 09:28 PM, Aurelien Jarno wrote:
 On Wed, Mar 19, 2014 at 09:18:20PM +0100, Sebastiaan Couwenberg wrote:
 At the end of last year during the mapnik transition the memory
 exhaustion was fixed by scheduling the builds on buildds with more memory.

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729121#16

 Is that an option now too? Or are the more capable buildds already used?
 
 I have blacklisted the package on all buildds which have less than 4GB
 of RAM for mipsel, and requeued the package. Let's see how it goes, if
 it works, i'll look at doing the same for mips.

Thanks for the quick response.

Unfortunately the requeued build also failed.

I'm not sure what the best course of action is. But Jérémy suggested
backporting a change from upstream, I'll give that a go tomorrow:

https://github.com/mapnik/mapnik/pull/2134

Kind Regards,

Bas

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

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

Bug#742149: mapnik: FTBFS on mipsen (virtual memory exhausted)

[Sebastiaan Couwenberg]

At the end of last year during the mapnik transition the memory
exhaustion was fixed by scheduling the builds on buildds with more memory.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729121#16

Is that an option now too? Or are the more capable buildds already used?

Kind Regards,

Bas

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

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

Bug#742273: osgearth: unsatisfiable libv8-dev build-dep

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/21/2014 02:53 PM, Julien Cristau wrote:
 osgearth added an unconditional build-dep on libv8-dev, however
 that package is only built on little endian archs by the looks of
 it (it's missing on mips, powerpc, s390x and sparc).

Because libv8 is not available on all architectures, I've filed an RM
request for osgearth on the architectures where it cannot be built.
(#742261)

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJTLEv7AAoJEGdQ8QrojUrxfVYP/0L+W5GEJENMIQbEYUtcZiie
KOkuGxk2pUeuQc193t2EZz+CCs0o9ElvMM9GujDW04eljGp1DmGd8227xeq1pX+l
Wgubo/dvKA+Zpqij/B/jrMTe6JJOxp+hkoCODP/dIGCse+ryazBTeqjSYNUuFlTN
FsGY0PXNIZOS9cjw5uIaBDym9g2j8EBp2FjgREj0/2YmWGxU/8YCtrHl3BKk36sL
amRHhBwicbxifkBiJbp7VXItY8wkY27+tCmCOAaRDE93uxdDKuQtwivceA9ENTdo
LgZfss49qOCUrvG1TxsGcDnlGkSt9BStVZt1/WU2Kl5SDWZVJhzIc/Fi9mieSwdD
cJ4yzSe/JKfLg+UUtqkcV/O/jqmp02SElGdev5TvP8S7VH7ALRor/8TbKMW1lB2W
D7q2ichkzN8i0QS+RKQOGlsSQh161synohdvNtu/UoPD3Bs1V0Iceryl9vncRpN0
JjS1WJ1NMtu+a5p0gNMhHyNtHUS3mb5y5rlMxSdWFY8P/fLqrUb29VxpG8RYiP03
I2ZPgVl5I5vK4Y1mQ6Y+wrhvSn0SZWC1TJKmD7ihuQx5PozncuFT0al66PV/M+Yy
QwK71wdK67sa15h9zO6OT4UGBF43pGS8neh8Gl62Lg7U6+pL+xhckMHzgtbc4O/q
V1RseSZGJbWKi1/NjEDi
=gdD9
-END PGP 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

Bug#742273: osgearth: unsatisfiable libv8-dev build-dep

[Sebastiaan Couwenberg]

On 03/21/2014 04:10 PM, Sebastiaan Couwenberg wrote:
 The security status of libv8 is also a bit worrisome, and another reason
 to drop the build dependency. We just need to deal with a number of
 FTBFSes for osgEarth and QGIS then.

This was enough for me to justify dropping the libv8-dev build
dependency. I've prepared a new osgearth package for unstable and
requested sponsorship (#742325).

osgEarth can now be built on all architectures except hurd-i386 where
the openscenegraph dependency is not available due to a FTBFS.

Kind Regards,

Bas

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

___
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: postgis backport for wheezy

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/02/2014 03:28 PM, William Dauchy wrote:
 I was wondering if a backport for wheezy was planned for the
 package postgis?

I'm not aware of any backport plans, but maybe Markus (CC'ed) can shed
some light on his plans for PostGIS.

In general none of the Debian GIS packages are backported, but we've
talked about a couple of times without anything concrete coming out of it.

If you'd like to help maintain a backport that's the best way to make
it happen.

Kind Regards,

Bas

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCgAGBQJTPEi/AAoJEGdQ8QrojUrx5iMP/jmV73G9B3nWMqiU6FGfVbay
cpuGwWU+CurJPAGY0M9yoOx0kcW1XYQWs0yONGVnC7Y1I05HgF7mZp/5IUJkNaFu
EKnJxDvR9LirxmyqH37tKmn1R4q2TJ4VN8X09gX0DYC6WrG1p/qr/YYZNUlJ6ssO
wbWyxUOzd3HBfdST6WDUvyjs+EwzHDU2JY8Mik9c7G3xe2GBdd8wyG+yxEIX8+1W
RNX+uiZVvEHXwOvbJB3UwQsESpUIc3RMveOIayQcqagR30tp8V289Syzbbxs4uzJ
z529i8OrTXBi8Va4MKdjsr7VwCQUBrnDNfajBcYjZIRhWktD3WAnRliwuZwB8E1G
bUiJsGcgVxgPDUZAUuMXM9iw9JRjOHTxJfjnCKWwvELiTOA+4gJ7rprdvaJoru3s
Z+HJeGBcsnHfZb5wmuPZEo8+0vgi5/XcKFftfARhmqcM4iHl2t/W51We2e8//udH
pnsID+KVA3ohx/tuSe45DDiUhcbrjRUJfQKgw/0uS79Y8+FunXp/h5PIyT1VEkiv
lLwJbIPiGcxeHXkIQ3IqxCCXDH+Y7opZ76iz0BHZtlDH4o6jWHgl8w/BX1huExVK
RZTuJxnwmpmiZ8EoSU0Z/zKttcSgXF+AWJFFTm7tx17iD+IkxWkRva4lWmiBUrT6
vPBgQFRC+w01qF3PD2bc
=rOfg
-END PGP 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