-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
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
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:
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
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
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
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
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
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
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
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
-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
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
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 (=
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
-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
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
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
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
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
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.
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
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
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
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
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:
-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
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
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,
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:
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
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
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)
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
--
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
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:
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
___
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) /
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
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)
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)
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)
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)
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)
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
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
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
-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
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
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
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
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
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
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
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
___
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
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
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
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
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
-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
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
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
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
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)
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
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 =
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
___
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:
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
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,
-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
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
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
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
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:
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
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
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
--
-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
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
-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
1 - 100 of 13149 matches
Mail list logo