GNU bug report logs -
#39204
r-rgdal: Reading of vector GIS data causes segfault
Previous Next
Reported by: Wiktor Żelazny <wz <at> freeshell.de>
Date: Mon, 20 Jan 2020 15:44:01 UTC
Severity: normal
Done: Arun Isaac <arunisaac <at> systemreboot.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39204 in the body.
You can then email your comments to 39204 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Mon, 20 Jan 2020 15:44:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Wiktor Żelazny <wz <at> freeshell.de>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Mon, 20 Jan 2020 15:44:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi list,
The same behaviour on two machines.
To reproduce:
guix environment --container --ad-hoc r r-rgdal
Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'
Loading required package: sp
rgdal: version: 1.4-8, (SVN revision 845)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.0.2, released 2019/10/28
Path to GDAL shared files:
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
Path to PROJ.4 shared files: (autodetected)
Linking to sp version: 1.3-2
*** caught segfault ***
address 0x30, cause 'memory not mapped'
Traceback:
1: ogrFIDs(dsn = dsn, layer = layer)
2: ogrInfo(dsn = dsn, layer = "cities")
An irrecoverable exception occurred. R is aborting now ...
sh: rm: command not found
Segmentation fault
Opening with QGIS, which also depends on GDAL (it uses PROJ.6 instead of
PROJ.4, though), works.
WŻ
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Mon, 20 Jan 2020 19:51:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi,
Thank you for reporting.
The issue is that the error is not catched at build time. It is not
expected. This package should fail and not say "successfully built".
Well, this needs more investigation.
--8<---------------cut here---------------start------------->8---
$ guix build r-rgdal --check --no-grafts -K
[...]
phase `install' succeeded after 19.0 seconds
starting phase `check'
Testing examples for package ‘rgdal’
/gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BATCH:
line 60: 598 Segmentation fault ${R_HOME}/bin/R -f ${in}
${opts} ${R_BATCH_OPTIONS} > ${out} 2>&1
[...]
successfully built /gnu/store/7spmagnk5fycwxsigdypwkmk4kazbw7a-r-rgdal-1.4-8.drv
note: keeping build directory `/tmp/guix-build-r-rgdal-1.4-8.drv-0'
/gnu/store/dgkyzlasbqsxcsfk3n3bgmhrpg447f55-r-rgdal-1.4-8
--8<---------------cut here---------------end--------------->8---
Good catch! :-)
All the best,
simon
--
$ guix describe
Generation 68 Jan 16 2020 15:57:09 (current)
guix d14e474
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: d14e4745b36a835c6babd5b5f5562e12294cd9cf
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Thu, 20 Feb 2020 10:36:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
There is 2 issues in this bug report:
1. the `check' phase is failing but the build ends with "success".
2. a regression of r-rgdal introduced by your commit
f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
About the point 1., here is what happens:
> --8<---------------cut here---------------start------------->8---
> $ guix build r-rgdal --check --no-grafts -K
> [...]
> phase `install' succeeded after 19.0 seconds
> starting phase `check'
> Testing examples for package ‘rgdal’
> /gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BATCH:
> line 60: 598 Segmentation fault ${R_HOME}/bin/R -f ${in}
> ${opts} ${R_BATCH_OPTIONS} > ${out} 2>&1
> [...]
> successfully built /gnu/store/7spmagnk5fycwxsigdypwkmk4kazbw7a-r-rgdal-1.4-8.drv
> note: keeping build directory `/tmp/guix-build-r-rgdal-1.4-8.drv-0'
> /gnu/store/dgkyzlasbqsxcsfk3n3bgmhrpg447f55-r-rgdal-1.4-8
> --8<---------------cut here---------------end--------------->8---
Therefore, more investigations are required to see why the upstream
test suite does not report correctly the failure.
However, the Segmentation Fault is the point 2. and introduced by the commit:
--8<---------------cut here---------------start------------->8---
commit f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
Author: Arun Isaac <arunisaac <at> systemreboot.net>
Date: Thu Dec 5 01:47:47 2019 +0530
gnu: libgeotiff: Update to 1.5.1.
* gnu/packages/patches/libgeotiff-adapt-test-script-for-proj-6.2.patch:
New file.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/geo.scm (libgeotiff): Update to 1.5.1.
[inputs]: Replace proj.4 with proj.
[sources]: Add libgeotiff-adapt-test-script-for-proj-6.2.patch
to patches.
gnu/local.mk | 1 +
gnu/packages/geo.scm | 17 +++---
...libgeotiff-adapt-test-script-for-proj-6.2.patch | 63 ++++++++++++++++++++++
3 files changed, 72 insertions(+), 9 deletions(-)
create mode 100644
gnu/packages/patches/libgeotiff-adapt-test-script-for-proj-6.2.patch
--8<---------------cut here---------------end--------------->8---
I have bisected this way:
git bisect start
git bisect bad ba7ead2b507d94397481be014d6ac0c41c7ddbfa
git bisect good 28d940961cfa1ae6dc574053aec8d03095677df8
# ba7ead2b507d94397481be014d6ac0c41c7ddbfa => bad
# 28d940961cfa1ae6dc574053aec8d03095677df8 => good
# fe0686864dc57ecdda7ecbb318d2618ac46169ae => bad
# 85c945aa97d89fdc17ec5d64c3ffa7f99ba1184b => good
# 885424bf7f6e0bc0ad5dd9353690aa82d17dd8b8 => bad
# 6f5d849a83c44ffb39c3a976aea10b7b31c24063 => good
# ce5b71f98ce39c92637876120f44868ec7ad391f => good
# 96211e3f33d1f1c35fd6377db1d8a4c6ec1a9c22 => bad
# 6cde07379f2a049b8c7f0eca90959f6c170c4102 => bad
# 87a028100c665814c3b5d622701abc6d77144faf => good
# 00d81f9866726f85241f08e444ba3932fcb38842 => good
# e72557c08f4f2fdd545106a9f4f0fc0bc9496249 => bad
# 3500d7addc2f9b2067ffd239383eb0e546be4f43 => good
# f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 => bad
Please could you confirm?
If 'libgeotiff' is really the culprit, then we can try to fix it.
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Thu, 20 Feb 2020 17:12:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> There is 2 issues in this bug report:
>
> 1. the `check' phase is failing but the build ends with "success".
I haven't investigated why this is happening.
> 2. a regression of r-rgdal introduced by your commit
> f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
Replacing proj.4 with proj in the r-rgdal package seems to fix this
regression. Can you confirm?
Thanks!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 11:20:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
On Thu, 20 Feb 2020 at 18:11, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> > 2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?
Maybe, but it is not what the user expects. Upstream explicitly
mentions proj.4, see [1].
[1] https://cloud.r-project.org/web/packages/rgdal/index.html
which is reflected by:
--8<---------------cut here---------------start------------->8---
$ guix show r-rgdal
name: r-rgdal
version: 1.4-8
outputs: out
systems: x86_64-linux i686-linux
dependencies: gdal <at> 3.0.2 pkg-config <at> 0.29.2 proj.4 <at> 4.9.3 r-sp <at> 1.3-2 zlib <at> 1.2.11
location: gnu/packages/cran.scm:15897:2
homepage: http://rgdal.r-forge.r-project.org
license: GPL 2+
synopsis: Bindings for the Geospatial Data Abstraction Library
description: This package provides bindings to the Geospatial Data
+ Abstraction Library (GDAL) and access to projection/transformation
+ operations from the PROJ.4 library.
--8<---------------cut here---------------end--------------->8---
The question is: why proj instead of proj.4 in libgeotiff?
The bug [1] cannot be solved using proj.4, why?
[2] https://github.com/OSGeo/libgeotiff/issues/22
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 12:14:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> > 2. a regression of r-rgdal introduced by your commit
>> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>>
>> Replacing proj.4 with proj in the r-rgdal package seems to fix this
>> regression. Can you confirm?
>
> Maybe, but it is not what the user expects. Upstream explicitly
> mentions proj.4, see [1].
> [1] https://cloud.r-project.org/web/packages/rgdal/index.html
No, upstream says that both proj (aka proj6) and proj.4 are
supported. Quoting [1],
"From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."
> The question is: why proj instead of proj.4 in libgeotiff?
> The bug [1] cannot be solved using proj.4, why?
proj and proj.4 are different versions of the same software, with proj
being the newer version. See
https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
deprecate our proj.4 package and replace all occurrences of proj.4 with
proj.
WDYT?
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 12:32:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 39204 <at> debbugs.gnu.org (full text, mbox):
On Fri, 21 Feb 2020 at 13:13, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> >> > 2. a regression of r-rgdal introduced by your commit
> >> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
> >>
> >> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> >> regression. Can you confirm?
> >
> > Maybe, but it is not what the user expects. Upstream explicitly
> > mentions proj.4, see [1].
>
> > [1] https://cloud.r-project.org/web/packages/rgdal/index.html
>
> No, upstream says that both proj (aka proj6) and proj.4 are
> supported. Quoting [1],
>
> "From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."
I agree, but I was referring to "access to projection/transformation
operations from the 'PROJ.4' library." or "Windows and Mac Intel OS X
binaries (including 'GDAL', 'PROJ.4' and 'Expat') are provided on
'CRAN'."
Well, your comment below says my remark here is irrelevant. :-)
> > The question is: why proj instead of proj.4 in libgeotiff?
> > The bug [1] cannot be solved using proj.4, why?
>
> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.
Thank you for the pointer, I was not aware.
Well, I agree. Let replace all the dependencies of proj.4 by proj and
deprecate our proj.4 package.
--8<---------------cut here---------------start------------->8---
$ guix graph -t reverse-package proj.4 \
| grep label | cut -d'=' -f2 | cut -d',' -f1
"proj.4 <at> 4.9.3"
"r-sf <at> 0.8-0"
"r-spdep <at> 1.1-3"
"r-monocle3 <at> 0.1.2"
"r-cicero-monocle3 <at> 1.3.2-1.fa2fb65"
"r-adegenet <at> 2.1.2"
"r-rmetasim <at> 3.1.7"
"r-hierfstat <at> 0.04-22"
"r-pegas <at> 0.12"
"r-rgdal <at> 1.4-8"
"libosmium <at> 2.14.2"
"osm2pgsql <at> 0.96.0"
"mapnik <at> 3.0.18"
"python2-mapnik <at> 3.0.16"
"xygrib <at> 1.2.6.1"
"spatialite-gui <at> 1.7.1"
"libspatialite <at> 4.3.0a"
"libgaiagraphics <at> 0.5"
--8<---------------cut here---------------end--------------->8---
Thanks,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 18:54:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
On Thu, 20 Feb 2020 at 18:11, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> > 2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?
You mean:
guix build --with-input=proj.4=proj r-rgdal
then it compiles a lot... and I do not understand why gdal is
recompiled. Anyway!
So after some CPU burning, I get:
--8<---------------cut here---------------start------------->8---
Testing examples for package ‘rgdal’
Running specific tests for package ‘rgdal’
Running ‘srs_rendering.R’
comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
5c5
< [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
---
> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
7c7
< [1] "GDAL 3.0.2, released 2019/10/28"
---
> [1] "GDAL 2.4.0, released 2018/12/14"
11c11
<
scot_BNG
---
> trin_inca_pl03
12c12
< "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
+y_0=-100000 +ellps=airy +units=m +no_defs"
---
> NA
13c13
<
trin_inca_pl03
---
> kiritimati_primary_roads
14c14
<
NA
---
> "+proj=utm +zone=4 +datum=WGS84 +units=m +no_defs "
16c16
<
"+proj=longlat +datum=WGS84 +no_defs"
---
<
kiritimati_primary_roads
---
> scot_BNG
18c18
< "+proj=utm
+zone=4 +datum=WGS84 +units=m +no_defs"
---
> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs "
22c22
< [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
+towgs84=0,0,0,0,0,0,0 +no_defs"
---
> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
24c24
< [1] "+proj=utm +zone=23 +south +ellps=aust_SA
+towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
---
> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs "
26c26
< [1] "+proj=longlat +datum=WGS84 +no_defs"
---
> [1] "+proj=longlat +datum=WGS84 +no_defs "
28c28
< [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
+ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
+no_defs"
---
> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193 +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
40c40
< file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.6666666666667
+lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
+ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
---
> file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +datum=NAD27 +units=us-ft +no_defs
41c41
< file: cea.tif , SRS: +proj=cea +lat_ts=33.75
+lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
---
> file: cea.tif , SRS: +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
42c42
< file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30
+lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
---
> file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30 +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
43c43
< file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +ellps=WGS84
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
---
> file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +datum=WGS84 +units=m +no_defs
Running ‘test_proj.R’
comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
Running ‘tests.R’
comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
Running ‘tripup.R’
comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
266c266
< coords FALSE
---
> coords TRUE
267c267
< holes FALSE
---
> holes TRUE
273c273
< coords FALSE
---
> coords TRUE
274c274
< holes FALSE
---
> holes TRUE
Running vignettes for package ‘rgdal’
Running ‘OGR_shape_encoding.Rnw’
phase `check' succeeded after 18.7 seconds
--8<---------------cut here---------------end--------------->8---
Therefore, I do not confirm, I guess.
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 18:55:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
On Fri, 21 Feb 2020 at 13:13, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.
For other packages than r-rgdal depending on proj.4:
- ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
- not ok: libspatialite and libosmium
And some packages do not build at all with the default (proj.4):
mapnik and spatialite-gui. Well, it is more than on my machine. ;-)
http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/mapnik/3.0.18
http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/spatialite-gui/1.7.1
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 21:37:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> For other packages than r-rgdal depending on proj.4:
> - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
> - not ok: libspatialite and libosmium
Indeed, all packages don't yet support proj. We'll have to keep proj.4
around until their upstreams adds support for proj.
> And some packages do not build at all with the default (proj.4):
> mapnik and spatialite-gui. Well, it is more than on my machine. ;-)
These will have to be fixed too. Do open separate bug reports for
those. Please provide patches if possible.
Thanks!
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 21:41:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> You mean:
>
> guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!
Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.
> So after some CPU burning, I get:
>
> --8<---------------cut here---------------start------------->8---
> Testing examples for package ‘rgdal’
> Running specific tests for package ‘rgdal’
> Running ‘srs_rendering.R’
> comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
> 5c5
> < [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
> ---
>> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
> 7c7
> < [1] "GDAL 3.0.2, released 2019/10/28"
> ---
>> [1] "GDAL 2.4.0, released 2018/12/14"
> 11c11
> <
> scot_BNG
> ---
>> trin_inca_pl03
> 12c12
> < "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
> +y_0=-100000 +ellps=airy +units=m +no_defs"
> ---
>> NA
> 13c13
> <
> trin_inca_pl03
> ---
>> kiritimati_primary_roads
> 14c14
> <
> NA
> ---
>> "+proj=utm +zone=4 +datum=WGS84 +units=m +no_defs "
> 16c16
> <
> "+proj=longlat +datum=WGS84 +no_defs"
> ---
> <
> kiritimati_primary_roads
> ---
>> scot_BNG
> 18c18
> < "+proj=utm
> +zone=4 +datum=WGS84 +units=m +no_defs"
> ---
>> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs "
> 22c22
> < [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
> +towgs84=0,0,0,0,0,0,0 +no_defs"
> ---
>> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
> 24c24
> < [1] "+proj=utm +zone=23 +south +ellps=aust_SA
> +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
> ---
>> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs "
> 26c26
> < [1] "+proj=longlat +datum=WGS84 +no_defs"
> ---
>> [1] "+proj=longlat +datum=WGS84 +no_defs "
> 28c28
> < [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
> +k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
> +ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
> +no_defs"
> ---
>> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193 +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
> 40c40
> < file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.6666666666667
> +lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
> +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
> ---
>> file: SP27GTIF.TIF , SRS: +proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +datum=NAD27 +units=us-ft +no_defs
> 41c41
> < file: cea.tif , SRS: +proj=cea +lat_ts=33.75
> +lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> ---
>> file: cea.tif , SRS: +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> 42c42
> < file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30
> +lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> ---
>> file: erdas_spnad83.tif , SRS: +proj=tmerc +lat_0=30 +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> 43c43
> < file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> ---
>> file: scaleoffset.vrt , SRS: +proj=utm +zone=18 +datum=WGS84 +units=m +no_defs
> Running ‘test_proj.R’
> comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
> Running ‘tests.R’
> comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
> Running ‘tripup.R’
> comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
> 266c266
> < coords FALSE
> ---
>> coords TRUE
> 267c267
> < holes FALSE
> ---
>> holes TRUE
> 273c273
> < coords FALSE
> ---
>> coords TRUE
> 274c274
> < holes FALSE
> ---
>> holes TRUE
> Running vignettes for package ‘rgdal’
> Running ‘OGR_shape_encoding.Rnw’
> phase `check' succeeded after 18.7 seconds
> --8<---------------cut here---------------end--------------->8---
>
>
> Therefore, I do not confirm, I guess.
I don't understand. With proj instead of proj.4, it does work, doesn't
it? There are no errors and the check phase succeeds.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 22:15:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 39204 <at> debbugs.gnu.org (full text, mbox):
On Fri, 21 Feb 2020 at 22:36, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> > For other packages than r-rgdal depending on proj.4:
> > - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
> > - not ok: libspatialite and libosmium
>
> Indeed, all packages don't yet support proj. We'll have to keep proj.4
> around until their upstreams adds support for proj.
So it is difficult to deprecate proj.4, IMHO.
> > And some packages do not build at all with the default (proj.4):
> > mapnik and spatialite-gui. Well, it is more than on my machine. ;-)
>
> These will have to be fixed too. Do open separate bug reports for
> those. Please provide patches if possible.
I will do.
Thanks,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Fri, 21 Feb 2020 22:21:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 39204 <at> debbugs.gnu.org (full text, mbox):
On Fri, 21 Feb 2020 at 22:40, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> > You mean:
> >
> > guix build --with-input=proj.4=proj r-rgdal
> >
> > then it compiles a lot... and I do not understand why gdal is
> > recompiled. Anyway!
>
> Your command recursively replaces proj.4 with proj. So, some dependency
> of gdal might have been modified resulting in a rebuild of gdal.
Yes, but gdal already depends on proj and not proj.4.
Then I examined the graph and did not find the offending package.
That's why I do not understand why gdal is recompiled.
I mean, let find the intersection between "guix graph gdal" and "guix
graph -t reverse-package proj.4", and I do not understand because I
find it empty.
> > Therefore, I do not confirm, I guess.
>
> I don't understand. With proj instead of proj.4, it does work, doesn't
> it? There are no errors and the check phase succeeds.
I have try to replace proj.4 by proj in the inputs field and I get the
same error.
Well, it does not work for me. Maybe I am doing a mistake.
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Sat, 22 Feb 2020 19:43:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Let's try to debug the problem you are facing. After applying the
attached patch, please provide the complete outputs of the following
commands. If the output is too long, feel free to send it as an email
attachment.
$ ./pre-inst-env guix build r-gdal
$ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'
Thank you for your patience! Cheers! :-)
[0001-gnu-r-rgdal-Replace-proj.4-with-proj.patch (text/x-patch, inline)]
From 7b2430788c2d168bd2a8a848e488a0e03140057b Mon Sep 17 00:00:00 2001
From: Arun Isaac <arunisaac <at> systemreboot.net>
Date: Sun, 23 Feb 2020 00:46:32 +0530
Subject: [PATCH] gnu: r-rgdal: Replace proj.4 with proj.
* gnu/packages/cran.scm (r-rgdal)[inputs]: Replace proj.4 with proj.
---
gnu/packages/cran.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index b731ddc29e..05759459af 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -18,6 +18,7 @@
;;; Copyright © 2018, 2019 Brett Gilio <brettg <at> gnu.org>
;;; Copyright © 2019 Nicolò Balzarotti <anothersms <at> gmail.com>
;;; Copyright © 2019 Wiktor Żelazny <wzelazny <at> vurv.cz>
+;;; Copyright © 2020 Arun Isaac <arunisaac <at> systemreboot.net>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -15907,7 +15908,7 @@ effect size.")
(build-system r-build-system)
(inputs
`(("gdal" ,gdal)
- ("proj.4" ,proj.4)
+ ("proj" ,proj)
("zlib" ,zlib)))
(propagated-inputs
`(("r-sp" ,r-sp)))
--
2.23.0
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Mon, 24 Feb 2020 11:34:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
First, your patch does not apply. Because it should be line 21 and not
18 for the addition of your Copyright.
On Sat, 22 Feb 2020 at 20:42, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> $ ./pre-inst-env guix build r-rgdal
I get the same message than I previously sent:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26
> $ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'
--8<---------------cut here---------------start------------->8---
Loading required package: sp
rgdal: version: 1.4-8, (SVN revision 845)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 3.0.2, released 2019/10/28
Path to GDAL shared files:
GDAL binary built with GEOS: TRUE
Loaded PROJ.4 runtime: Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]
Path to PROJ.4 shared files: (autodetected)
Linking to sp version: 1.4-0
Source: "/gnu/store/m4rd975j3979zqqqfwg3b7s070i3n3h3-r-rgdal-1.4-8/site-library/rgdal/vectors",
layer: "cities"
Driver: ESRI Shapefile; number of rows: 606
Feature type: wkbPoint with 2 dimensions
Extent: (-165.27 -53.15) - (177.1302 78.2)
CRS: +proj=longlat +datum=WGS84 +no_defs
LDID: 0
Number of fields: 4
name type length typeName
1 NAME 4 40 String
2 COUNTRY 4 12 String
3 POPULATION 12 11 Integer64
4 CAPITAL 4 1 String
--8<---------------cut here---------------end--------------->8---
But as we have talked before, there is an issue about the upstream
test suite of the package (point 1. of [1]). So I am investigating...
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Mon, 24 Feb 2020 19:11:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 39204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> First, your patch does not apply. Because it should be line 21 and not
> 18 for the addition of your Copyright.
Sorry, I should have rebased with master.
> But as we have talked before, there is an issue about the upstream
> test suite of the package (point 1. of [1]). So I am investigating...
Ah, I understand our miscommunication now. You have been talking about
point 1 (bug in upstream test suite) and I've been talking about point 2
(segmentation fault when loading vector data). Yes, replacing proj.4
with proj only addresses point 2, not point 1.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Tue, 25 Feb 2020 15:50:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 39204 <at> debbugs.gnu.org (full text, mbox):
Hi Arun,
On Mon, 24 Feb 2020 at 20:10, Arun Isaac <arunisaac <at> systemreboot.net> wrote:
> > But as we have talked before, there is an issue about the upstream
> > test suite of the package (point 1. of [1]). So I am investigating...
>
> Ah, I understand our miscommunication now. You have been talking about
> point 1 (bug in upstream test suite) and I've been talking about point 2
> (segmentation fault when loading vector data). Yes, replacing proj.4
> with proj only addresses point 2, not point 1.
It is not segfaulting anymore, I agree.
But is it enough to know that everything is ok and the package is not broken?
I am mean looking at the output of the 'check' phase (see [1]), it
displays a diff and I am not confident if it is good or not. That's
why I did not confirm that changing from proj.4 to proj works. Maybe I
mispelled "error" in my previous answer and the correct words seem "I
get an lengthy message and I do not know if it is ok." :-)
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26
Cheers,
simon
Reply sent
to
Arun Isaac <arunisaac <at> systemreboot.net>:
You have taken responsibility.
(Mon, 12 Oct 2020 10:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Wiktor Żelazny <wz <at> freeshell.de>:
bug acknowledged by developer.
(Mon, 12 Oct 2020 10:23:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 39204-done <at> debbugs.gnu.org (full text, mbox):
Hi,
I pushed to master, my commit replacing proj.4 with proj. This fixes the
segfault issue. I also updated the package. If the issue with the check
phase still persists, please open a separate issue.
Cheers!
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Mon, 12 Oct 2020 16:24:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 39204-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Oct 12, 2020 at 03:52:30PM +0530, Arun Isaac wrote:
> I pushed to master, my commit replacing proj.4 with proj.
Hi Arun,
Believe it or not, but on Friday I tried the same thing. First,
replacing proj with proj.4 in GDAL, which declined to compile, demanding
version 6, then replacing proj.4 with proj in r-rgdal.
It kept spitting the error during the check phase, but I was
time-machined some months into the past. Maybe with current Guix version
the issue does not occur. I will check it out this or the next week.
Thank you for your work on this issue.
WŻ
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#39204; Package
guix.
(Tue, 13 Oct 2020 04:22:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 39204-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> It kept spitting the error during the check phase, but I was
> time-machined some months into the past. Maybe with current Guix version
> the issue does not occur. I will check it out this or the next week.
Sure, check it out and let me know.
> Thank you for your work on this issue.
My pleasure! :-)
[signature.asc (application/pgp-signature, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 10 Nov 2020 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 166 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.