Bug#620593: libhdf4: please wipe out dependency_libs from .la files (Policy 10.2)
Package: libhdf4
Version: 4.2r4-11
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty ubuntu-patch
Hi Francesco,
The attached patch has just been applied to the Ubuntu libhdf4 package, to
null out the dependency_libs field in the libtool .la file being shipped in
the -dev package. This is generally a good idea because it avoids causing
consumers of your library to require other .la files listed here to be
available at build time when they're not actually needed (i.e., in the
dynamic linking common case). It's specifically a good idea right now
because multiarch is imminent, and that means the .la files referenced here
are going to *move* soon, causing build failures for anything using libtool
to build against libhdf4. As long as libhdf4 is going to need a rebuild to
fix up the invalid .la references, it would be nice to get rid of them
altogether.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -u libhdf4-4.2r4/debian/rules libhdf4-4.2r4/debian/rules
--- libhdf4-4.2r4/debian/rules
+++ libhdf4-4.2r4/debian/rules
@@ -153,6 +153,11 @@
for obj in $(DESTDIR)/usr/bin/* $(DESTDIR)/usr/lib/*.so.* $(DESTDIR)/usr/lib-alt/*.so.*; do \
chrpath -d $${obj} || true; \
done
+
+ # Empty out the dependency field in our .la files
+ for file in $(DESTDIR)/usr/lib/*.la; do \
+ sed -i "/dependency_libs/ s/'.*'/''/" $$file ; \
+ done
# rename programs also provided by netcdf-bin
mv $(DESTDIR)/usr/bin/ncdump $(DESTDIR)/usr/bin/ncdump-hdf
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#335291: mapserver: FTBFS on hppa
clone 335291 -1 reassign -1 libcurl3-openssl-dev 7.15.0-3 retitle -1 curl-config --vernum is empty thanks On Sun, Oct 23, 2005 at 12:44:13AM -0400, Nathanael Nerode wrote: > Package: mapserver > Severity: serious > Justification: no longer builds from source > Log at > http://buildd.debian.org/fetch.php?&pkg=mapserver&ver=4.6.1-3&arch=hppa&stamp=1129937926&file=log&as=raw > This is a very dumb error: > configure: checking for curl-config... > checking for curl-config... /usr/bin/curl-config > found libcurl version 7.15.0 > configure: error: libcurl version 7.10.1 or more recent is required. > make: *** [configure-stamp] Error 1 > Your configure script is being very stupid, since it thinks that > 7.15.0 is older than 7.10.1. It's a dumb error message, but the real problem is that it's checking the output of curl-config --vernum, which is empty in libcurl3-openssl-dev 7.15.0-3. (The generated error message uses the value of curl-config --version instead.) I assume that since the commandline option still exists, that it's meant to still be available for use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#339007: php4-mapscript: php_mapscript.so is into incorrect directory
severity 339007 grave thanks On Fri, Nov 18, 2005 at 09:05:08AM +0100, Petter Reinholdtsen wrote: > > I get this error because php_mapscript.so is into /usr/lib/php4/20020429: > > Warning: dl(): Unable to load dynamic library > > '/usr/lib/php4/20050606/php_mapscript.so' - > > /usr/lib/php4/20050606/php_mapscript.so: cannot open shared object file > > I have corrected this problem with a symbolic link. > The date used in /usr/lib/php4/ is supposed to be the PHP ABI/API > version. I'm told the php4 ABI/API version is supposed to be > 20020429, and the php5 ABI version is supposed to be 20041030. I have > no idea where your '20050606' ABI/API comes from. > PHP5 support was added to mapserver version 4.6.1-5, see bug #333057. > Perhaps it is related to this problem? > I'm reducing the severity from grave to important, because I believe > the ABI/API date is correct for php4, and I've also been told that it > works for others. Grave severity would only be correct for this issue > if it was broken for everyone. Sorry, it *is* broken for everyone. The current version of PHP4 expects modules in /usr/lib/php4/20050606/, and packages using this interface need to depend on phpapi-20050606. You should be using php-config4 --extension-dir and php-config4 --phpapi respectively to determine these values, as the #defines PHP upstream provides in their headers for this are complete crap. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#351869: mapserver_4.6.2-1 (unstable/alpha): FTBFS: doesn't build under sudo
Package: mapserver Version: 4.6.2-1 Severity: serious The latest version of mapserver has failed to build on alpha with the following error: [...] touch mapscriptvars touch: cannot touch apscriptvars': Permission denied make[1]: *** [mapscriptvars] Error 1 make[1]: Leaving directory /build/buildd/mapserver-4.6.2' make: *** [build-arch-stamp] Error 2 [...] A full build log is available at <http://buildd.debian.org/fetch.php?pkg=mapserver&arch=alpha&ver=4.6.2-1&stamp=1139283445&file=log>. This failure occurs because the alpha autobuilder uses sudo instead of fakeroot for building, and mapserver does not have a clean separation between its "clean" and "build" targets. The "clean" target is specified as running under rootcmd; you should therefore *not* be creating files in "clean". (That, and creating files in "clean" is somewhat backwards...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#360389: gdal: FTBFS: cannot convert 'SQLUINTEGER*' to 'SQLULEN*'
tags 360389 patch thanks On Sat, Apr 01, 2006 at 11:13:53PM +0200, Kurt Roeckx wrote: > Your package is failing to build with the following error: > g++ -Wall -O2 -I../port -c cpl_odbc.cpp -fPIC -DPIC -o .libs/cpl_odbc.o > cpl_odbc.cpp: In member function 'int CPLODBCStatement::CollectResultsInfo()': > cpl_odbc.cpp:424: error: cannot convert 'SQLUINTEGER*' to 'SQLULEN*' for > argume > nt '7' to 'SQLRETURN SQLDescribeCol(void*, SQLUSMALLINT, SQLCHAR*, > SQLSMALLINT, > SQLSMALLINT*, SQLSMALLINT*, SQLULEN*, SQLSMALLINT*, SQLSMALLINT*)' > cpl_odbc.cpp: In member function 'int CPLODBCStatement::Fetch(int, int)': > cpl_odbc.cpp:638: error: cannot convert 'SQLINTEGER*' to 'SQLLEN*' for > argument > '6' to 'SQLRETURN SQLGetData(void*, SQLUSMALLINT, SQLSMALLINT, void*, SQLLEN, > SQLLEN*)' > [...] > See full buildd log at: > http://buildd.debian.org/fetch.php?&pkg=gdal&ver=1.3.1-4&arch=amd64&stamp=1143533668&file=log&as=raw This bug is release-critical because it affects all 64-bit architectures, and there are previous binaries in the archive for alpha and ia64. The problem is that gdal has code to support 64-bit ODBC, but assumes that SQLLEN will be a #define -- which with UnixODBC, it isn't. The only reliable test for the presence of SQLLEN is therefore a configure test; but for Debian's purposes, the attached mini-patch should be sufficient. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ diff -u gdal-1.3.1/debian/changelog gdal-1.3.1/debian/changelog --- gdal-1.3.1/debian/changelog +++ gdal-1.3.1/debian/changelog @@ -1,3 +1,12 @@ +gdal (1.3.1-4.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix build failures on 64-bit archs due to incorrect assumption that +SQLLEN will be a #define. Instead, check for ODBCVER >= 0x0351, +which is about the closest we can get. Closes: #360389. + + -- Steve Langasek <[EMAIL PROTECTED]> Sat, 8 Apr 2006 05:18:46 -0700 + gdal (1.3.1-4) unstable; urgency=low [ Paul Wise ] only in patch2: unchanged: --- gdal-1.3.1.orig/port/cpl_odbc.h +++ gdal-1.3.1/port/cpl_odbc.h @@ -95,7 +95,7 @@ class CPLODBCStatement; -#ifdef SQLULEN +#if defined(ODBCVER) && (ODBCVER >= 0x0351) /* ODBC types to support 64 bit compilation */ # define _SQLULEN SQLULEN # define _SQLLEN SQLLEN signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#361827: libgdal1-grass: fails to read GRASS vectors
Is anyone looking after this bug? It seems to be a straightforward makefile edit for libgdal-grass; whereas removing this package from etch means removing qgis as well due to qgis-plugin-grass. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#368060: easy to fix with rebuilding
On Thu, Jun 01, 2006 at 02:11:42AM +0200, Holger Levsen wrote: > after rebuilding thuban in a clean sid chroot (and confirming this with > pbuilder) I can say that a simple binNMU fixes this bug. > As we are in a permanent BSP (where 0-day NMUs are allowed (*)) and this bug > is open for more than a week, I plan to do a (sponsored) binNMU tomorrow. > If you're preparing a new upload within few _days_ anyway, please let me > know, > so I dont have to bother someone with sponsoring. (As there is no new > upstream version, no activity in the BTS or the pkg-grass-devel list (in may) > about thuban I somewhat doubt this - but of course I would be happy to be > proven wrong :-) It is not appropriate to use binNMUs to work around insufficiently versioned dependencies. What happens when python-wxgtk2.4 version 2.4.6 is uploaded just before the freeze, breaking thuban again without anyone noticing in time? This is a sourceful bug between thuban and python-wxgtk2.4 which requires a sourceful fix. If thuban isn't actually compatible with all versions of python-wxgtk2.4 (why not?), then it's wrong for this package to declare its dependency on python-wxgtk2.4. Also, FWIW, binNMUs are properly the domain of the porters, and don't fall under the policy for source NMUs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#392560: GRASS not compilable on testing
severity 392560 important thanks On Thu, Oct 12, 2006 at 11:07:25AM +0200, Harri Kiiskinen wrote: > Subject: grass: Outdated build-deps for testing > Source: grass > Severity: serious > Justification: no longer builds from source > *** Please type your report below this line *** > The grass source package from testing (6.0.2-6) has impossible build > dependencies for testing, and the current grass binary in > testing cannot have been built with these dependencies. > dpkg-checkbuilddeps: Unmet build dependencies: fftw3-dev > libgl1-mesa-swx11-dev libglu1-xorg-dev | xlibmesa-glu-dev autoconf2.13 > libgdal1-1.3.1-dev > results in this: > to be REMOVED: > libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx x-window-system > x-window-system-core xlibmesa-dri xlibmesa-gl xlibmesa-gl-dev xorg > to be INSTALLED: > autoconf2.13 fftw3-dev libgl1-mesa-swx11 libgl1-mesa-swx11-dev > libglu1-xorg-dev > To remove xorg just to build grass? Somewhat exaggarated, IMHO. That doesn't make it a serious bug in grass just because you choose not to install the build-dependencies. Though since grass doesn't appear to be building against libOSMesa, it should be fixed to use one of the less-conflicty implementations of libgl1-dev. > And the current grass binary dependes on libgdal1-1.3.2, which is the > current version in testing, not 1.3.1, which is required by > the source package. Would be nice to have the control file that was used > to build the current testing packages, not some age-old > ones. What are you talking about? The current version of the package build-depends on libgdal1-1.3.2-dev. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
[DebianGIS-dev] Bug#391075: thuban fails to start: missing python module
severity 391075 minor thanks The missing python module is resolved with python-wxgtk2.4 version 2.4.5.1.1. I think we'll probably still want thuban upgraded to wxwidgets 2.6 sooner rather than later, but this is no longer a release-critical bug (2.4.5.1.1 hits testing tonight). Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
Re: [DebianGIS-dev] OpenMPI support for hdf FTBFS on several arches
On Sat, Mar 29, 2008 at 10:39:54AM +0100, Rafael Laboissiere wrote: > If you think I should file a bug report about this, please tell me. I think you should file a severity: serious bug report about this, so that it's appropriately visible where others in the project will see it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel
Bug#893335: python-mpop: make autopkgtests pass on 32-bit archs
Package: python-mpop
Version: 1.5.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest
Dear maintainers,
With python-mpop 1.5.0-1, while the autopkgtests continue to pass fine on
amd64 as seen at <https://ci.debian.net/packages/p/python-mpop/>, but an
added upstream test makes assumptions about the python hash() function that
don't hold on 32-bit archs, as seen in Ubuntu at
<http://autopkgtest.ubuntu.com/packages/p/python-mpop/bionic/i386>.
Since there doesn't seem to be any reason to care that the cache filename
schema is consistent across architectures, and in any case this wasn't a
blocker for this version of python-mpop to reach testing, I think the test
should be fixed to be portable to 32-bit architectures. The attached patch
achieves this, and has been uploaded to Ubuntu.
Please consider applying this change in Debian as well.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru python-mpop-1.5.0/debian/patches/series
python-mpop-1.5.0/debian/patches/series
--- python-mpop-1.5.0/debian/patches/series 2017-03-13 10:28:27.0
-0700
+++ python-mpop-1.5.0/debian/patches/series 2018-03-17 00:02:10.0
-0700
@@ -3,3 +3,4 @@
0003-fix-missing-trollsift.patch
0004-Include-test-sub-package.patch
0005-Disable-TestEmptyImage.test_pil_image.patch
+wordsize-safe-tests.patch
diff -Nru python-mpop-1.5.0/debian/patches/wordsize-safe-tests.patch
python-mpop-1.5.0/debian/patches/wordsize-safe-tests.patch
--- python-mpop-1.5.0/debian/patches/wordsize-safe-tests.patch 1969-12-31
16:00:00.0 -0800
+++ python-mpop-1.5.0/debian/patches/wordsize-safe-tests.patch 2018-03-17
00:04:43.0 -0700
@@ -0,0 +1,26 @@
+Description: fix tests to work on 32-bit archs
+ The python hash() function doesn't return the same results on 64-bit and
+ 32-bit archs, so don't make incorrect assumptions about its output in a
+ test when used for something as inconsequential as predictable cache file
+ names.
+Author: Steve Langasek
+Index: python-mpop-1.5.0/mpop/tests/test_projector.py
+===
+--- python-mpop-1.5.0.orig/mpop/tests/test_projector.py
python-mpop-1.5.0/mpop/tests/test_projector.py
+@@ -259,8 +259,13 @@
+ res = mpop.projector.get_precompute_cache_fname('in_id', 'out_id',
+ 'in_area', 'out_area',
+ 'mode', 'proj_dir')
+-cor_res = "proj_dir/in_id2out_id_-" + \
+- "6296787761359943868to8984161303220364208_mode.npz"
++if sys.maxsize > 2**32:
++cor_res = "proj_dir/in_id2out_id_-" + \
++ "6296787761359943868to8984161303220364208_mode.npz"
++else:
++cor_res = "proj_dir/in_id2out_id_-" + \
++ "1843591356to-347954256_mode.npz"
++
+ self.assertTrue(res == cor_res)
+
+ @patch.object(mpop.projector, 'get_area_def')
___
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#793645: fiona: Please build-depend on python3-all-dev, not python3-dev
Package: fiona Version: 1.5.1-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu wily ubuntu-patch Hi Johan, The fiona package currently build-depends on python3-dev and python3-all (as well as python-all and python-all-dev). This is inconsistent, and results in a misbuild when there is more than one supported version of python3 as only support for the default interpreter is installed. The correct thing to do is to build-depend on either python3-all-dev + python3-all, or python3-dev + python3. Attached is a trivial patch to fix this issue. Note that the python3.5 transition is coming soon to Debian, at which point the severity of this bug might be raised. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org diff -Nru fiona-1.5.1/debian/control fiona-1.5.1/debian/control --- fiona-1.5.1/debian/control 2015-02-05 10:37:23.0 -0800 +++ fiona-1.5.1/debian/control 2015-07-25 14:15:33.0 -0700 @@ -8,11 +8,11 @@ libgdal-dev, python-cligj, python-all, - python-dev, + python-all-dev, python-nose, python3-cligj, python3-all, - python3-dev, + python3-all-dev, python3-nose, cython (>=0.21), cython3 (>=0.21), ___ 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#794047: pyspatialite: distro patch causes misbuild on 64-bit archs
Package: pyspatialite
Version: 3.0.1-8
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch
pyspatialite is currently misbuilt on 64-bit architectures in Debian testing
and unstable, because of a distro patch that causes /usr/include/spatialite
to be added to the header search path. libspatialite-dev ships both a
/usr/include/spatialite.h and a /usr/include/spatialite/spatialite.h, and
the first one is the correct one. Without the correct function types, this
results in the compiler truncating pointers along its way; e.g., from
<https://buildd.debian.org/status/fetch.php?pkg=pyspatialite&arch=arm64&ver=3.0.1-8&stamp=1436875015>:
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC
-DMODULE_NAME="spatialite.dbapi2" -DVERSION="3.0.1" -DSQLITE_ENABLE_FTS3=1
-DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DOMIT_FREEXL=1
-DSPATIALITE_HAS_INIT_EX=1 -I/usr/include -I/usr/include/spatialite
-I/usr/include/python2.7 -c src/connection.c -o
build/temp.linux-aarch64-2.7/src/connection.o
src/connection.c: In function 'pysqlite_connection_init':
src/connection.c:110:9: warning: implicit declaration of function
'spatialite_alloc_connection' [-Wimplicit-function-declaration]
self->slconn = spatialite_alloc_connection();
^
src/connection.c:110:22: warning: assignment makes pointer from integer without
a cast
self->slconn = spatialite_alloc_connection();
^
This doesn't get caught by the Debian buildds, but in Ubuntu this is treated
as a fatal error as this is a known misbuild that won't work at all on some
64-bit architectures and will fail randomly at runtime on others.
The one-liner fix has been applied to Ubuntu with the following changelog:
* debian/patches/00-fix_build.patch: don't add /usr/include/spatialite to
the search path. This is a wrong fix which causes
/usr/include/spatialite/spatialite.h to be found instead of
/usr/include/spatialite.h, resulting in a misbuild on 64-bit archs.
Thanks for considering the patch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pyspatialite-3.0.1/debian/patches/00-fix_build.patch pyspatialite-3.0.1/debian/patches/00-fix_build.patch
--- pyspatialite-3.0.1/debian/patches/00-fix_build.patch 2015-06-27 15:57:24.0 -0700
+++ pyspatialite-3.0.1/debian/patches/00-fix_build.patch 2015-07-29 20:57:42.0 -0700
@@ -7,9 +7,11 @@
setup.py | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
a/setup.py
-+++ b/setup.py
-@@ -44,7 +44,7 @@ sources = ["src/module.c", "src/connecti
+Index: pyspatialite-3.0.1/setup.py
+===
+--- pyspatialite-3.0.1.orig/setup.py
pyspatialite-3.0.1/setup.py
+@@ -44,7 +44,7 @@
include_dirs = []
library_dirs = []
@@ -18,7 +20,7 @@
runtime_library_dirs = []
extra_objects = []
define_macros = []
-@@ -113,24 +113,27 @@ def get_amalgamation():
+@@ -113,24 +113,26 @@
class MyBuildExt(build_ext):
def build_extension(self, ext):
@@ -50,7 +52,6 @@
+#ext.sources.append(os.path.join(AMALGAMATION_ROOT, "sqlite3.c"))
+#ext.sources.append(os.path.join(AMALGAMATION_ROOT, "spatialite.c"))
+#ext.include_dirs.append(AMALGAMATION_ROOT)
-+ext.include_dirs.append("/usr/include/spatialite")
build_ext.build_extension(self, ext)
___
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#794047: pyspatialite: distro patch causes misbuild on 64-bit archs
On Thu, Jul 30, 2015 at 02:55:00PM +0200, Sebastiaan Couwenberg wrote: > Thanks for the patch. I've applied it in pyspatialite (3.0.1-9) > available in unstable for syncing sortly. > In a related question, why are you syncing pyspatialite into Ubuntu but > not the qgis 2.8.x LTR version which is the reason we have a > pyspatialite package in the archive? The pyspatialite package is in sync in Ubuntu because it has had no Ubuntu-specific changes previously. The qgis package has an Ubuntu delta, which means an Ubuntu developer needs to merge it for an updated version to be included in Ubuntu. At the moment I'm only looking at resolving build failures to unblock library transitions related to the python3.5 transition, not at merging new work from Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
