From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: bug#39204: r-rgdal: Reading of vector GIS data causes segfault Date: Fri, 21 Feb 2020 19:53:22 +0100 Message-ID: References: <20200120154302.ijni47ou4fk4wd77@wzguix> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52909) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j5DR5-0007rX-LJ for bug-guix@gnu.org; Fri, 21 Feb 2020 13:54:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j5DR4-0003c1-E7 for bug-guix@gnu.org; Fri, 21 Feb 2020 13:54:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:42154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j5DR4-0003bx-98 for bug-guix@gnu.org; Fri, 21 Feb 2020 13:54:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j5DR4-0008RV-8o for bug-guix@gnu.org; Fri, 21 Feb 2020 13:54:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Arun Isaac Cc: 39204@debbugs.gnu.org Hi Arun, On Thu, 20 Feb 2020 at 18:11, Arun Isaac 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=3Dproj.4=3Dproj 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 =E2=80=98rgdal=E2=80=99 Running specific tests for package =E2=80=98rgdal=E2=80=99 Running =E2=80=98srs_rendering.R=E2=80=99 comparing =E2=80=98srs_rendering.Rout=E2=80=99 to =E2=80=98srs_rendering.= Rout.save=E2=80=99 ... 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=3Dtmerc +lat_0=3D49 +lon_0=3D-2 +k=3D0.9996012717 +x_0=3D400000 +y_0=3D-100000 +ellps=3Dairy +units=3Dm +no_defs" --- > = = NA 13c13 < trin_inca_pl03 --- > = kiritimat= i_primary_roads 14c14 < NA --- > = "+proj=3Dutm +zone=3D4 +datum=3DWGS8= 4 +units=3Dm +no_defs " 16c16 < "+proj=3Dlonglat +datum=3DWGS84 +no_defs" --- < kiritimati_primary_roads --- > = = scot_BNG 18c18 < "+proj=3Dutm +zone=3D4 +datum=3DWGS84 +units=3Dm +no_defs" --- > "+proj=3Dtmerc +lat_0=3D49 +lon_0=3D-2 +k=3D0.9996012717 +x_0=3D400000 +y= _0=3D-100000 +ellps=3Dairy +towgs84=3D446.448,-125.157,542.06,0.15,0.247,0.= 842,-20.489 +units=3Dm +no_defs " 22c22 < [1] "+proj=3Dlonglat +a=3D6378137.01 +rf=3D298.257223563 +towgs84=3D0,0,0,0,0,0,0 +no_defs" --- > [1] "+proj=3Dlonglat +ellps=3DWGS84 +towgs84=3D0,0,0,0,0,0,0 +no_defs " 24c24 < [1] "+proj=3Dutm +zone=3D23 +south +ellps=3Daust_SA +towgs84=3D-57,1,-41,0,0,0,0 +units=3Dm +no_defs" --- > [1] "+proj=3Dutm +zone=3D23 +south +ellps=3Daust_SA +towgs84=3D-57,1,-41,= 0,0,0,0 +units=3Dm +no_defs " 26c26 < [1] "+proj=3Dlonglat +datum=3DWGS84 +no_defs" --- > [1] "+proj=3Dlonglat +datum=3DWGS84 +no_defs " 28c28 < [1] "+proj=3Dlcc +lat_1=3D46.8 +lat_0=3D46.8 +lon_0=3D0 +k_0=3D0.999877420000019 +x_0=3D600000 +y_0=3D2200000.00000032 +ellps=3Dclrk80ign +pm=3Dparis +towgs84=3D-168,-60,320,0,0,0,0 +units=3Dm +no_defs" --- > [1] "+proj=3Dlcc +lat_1=3D46.8 +lat_0=3D46.8 +lon_0=3D0 +k_0=3D0.99987742= 00000193 +x_0=3D600000 +y_0=3D2200000.000000325 +a=3D6378249.2 +b=3D6356515= .000000472 +towgs84=3D-168,-60,320,0,0,0,0 +pm=3Dparis +units=3Dm +no_defs = " 40c40 < file: SP27GTIF.TIF , SRS: +proj=3Dtmerc +lat_0=3D36.6666666666667 +lon_0=3D-88.3333333333333 +k=3D0.999975 +x_0=3D152400.30480061 +y_0=3D0 +ellps=3Dclrk66 +towgs84=3D-8,160,176,0,0,0,0 +units=3Dus-ft +no_defs --- > file: SP27GTIF.TIF , SRS: +proj=3Dtmerc +lat_0=3D36.66666666666666 +lon= _0=3D-88.33333333333333 +k=3D0.9999749999999999 +x_0=3D152400.3048006096 +y= _0=3D0 +datum=3DNAD27 +units=3Dus-ft +no_defs 41c41 < file: cea.tif , SRS: +proj=3Dcea +lat_ts=3D33.75 +lon_0=3D-117.333333333333 +x_0=3D0 +y_0=3D0 +datum=3DNAD27 +units=3Dm +no_= defs --- > file: cea.tif , SRS: +proj=3Dcea +lon_0=3D-117.333333333333 +lat_ts=3D3= 3.75 +x_0=3D0 +y_0=3D0 +datum=3DNAD27 +units=3Dm +no_defs 42c42 < file: erdas_spnad83.tif , SRS: +proj=3Dtmerc +lat_0=3D30 +lon_0=3D-82.1666666666667 +k=3D0.9999 +x_0=3D200000 +y_0=3D0 +ellps=3DGRS8= 0 +towgs84=3D0,0,0,0,0,0,0 +units=3Dus-ft +no_defs --- > file: erdas_spnad83.tif , SRS: +proj=3Dtmerc +lat_0=3D30 +lon_0=3D-82.1= 6666666666667 +k=3D0.9999 +x_0=3D200000 +y_0=3D0 +ellps=3DGRS80 +towgs84=3D= 0,0,0,0,0,0,0 +units=3Dus-ft +no_defs 43c43 < file: scaleoffset.vrt , SRS: +proj=3Dutm +zone=3D18 +ellps=3DWGS84 +towgs84=3D0,0,0,0,0,0,0 +units=3Dm +no_defs --- > file: scaleoffset.vrt , SRS: +proj=3Dutm +zone=3D18 +datum=3DWGS84 +uni= ts=3Dm +no_defs Running =E2=80=98test_proj.R=E2=80=99 comparing =E2=80=98test_proj.Rout=E2=80=99 to =E2=80=98test_proj.Rout.sav= e=E2=80=99 ... OK Running =E2=80=98tests.R=E2=80=99 comparing =E2=80=98tests.Rout=E2=80=99 to =E2=80=98tests.Rout.save=E2=80= =99 ... OK Running =E2=80=98tripup.R=E2=80=99 comparing =E2=80=98tripup.Rout=E2=80=99 to =E2=80=98tripup.Rout.save=E2= =80=99 ... 266c266 < coords FALSE --- > coords TRUE 267c267 < holes FALSE --- > holes TRUE 273c273 < coords FALSE --- > coords TRUE 274c274 < holes FALSE --- > holes TRUE Running vignettes for package =E2=80=98rgdal=E2=80=99 Running =E2=80=98OGR_shape_encoding.Rnw=E2=80=99 phase `check' succeeded after 18.7 seconds --8<---------------cut here---------------end--------------->8--- Therefore, I do not confirm, I guess. All the best, simon