Bug 205955
Summary: | Review Request: gdal - A translator library for raster geospatial data formats | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Joost Soeterbroek <joost.soeterbroek> |
Component: | Package Review | Assignee: | Mamoru TASAKA <mtasaka> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | cbalint, lemenkov, pertusus, silke |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-02-07 05:26:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 201449 | ||
Attachments: |
Description
Joost Soeterbroek
2006-09-10 18:58:48 UTC
Okay. I will review this package. First review: 1. From http://fedoraproject.org/wiki/Packaging/Guidelines : * License: - Well, how can I know that this package can be distributed under MIT? It seems that main package does not include any licence document. * rpmlint: - is not silent. W: gdal macro-in-%changelog configure W: gdal macro-in-%changelog configure W: gdal mixed-use-of-spaces-and-tabs - Use %% in changelog so as the description in changelog is not expanded. - if it is difficult finding where tabs are used, use "sed -i -e 's|\t| |g' gdal.spec", which automatically changes tabs in spec file into two spaces. * Tags: - use %?dist tag * Requires: - -python package requires python-numeric as gdal_merge.py includes the line: "import Numeric" (this dependency cannot be automatically checked). * BuildRequires: - libjpeg-devel, zlib-devel, netcdf-devel <- required by hdf-devel (ditto requires for -devel package) * Encoding - Several text files are encoded in ISO-8859. Change the encoding to UTF-8 unless it is necessary. - ./gdal-1.3.2-1/usr/share/gdal/seed_2d.dgn: Microstation ./gdal-1.3.2-1/usr/share/gdal/seed_3d.dgn: data Well, what are these files? * Why the %makeinstall macro should not be used - Don't use %makeinstall * Timestamps - These (gdal) package contains lots of text files, so keeping timestamps is preferable. Keep timestamps of those files (usually 'make install' accepts the option 'INSTALL="install -c -p"'. * File and Directory Ownership - Don't own the directory %python_sitearch itself. 2. From http://fedoraproject.org/wiki/Packaging/ReviewGuidelines * MUST: The sources used to build the package must match.... - Specify the URL of the source. I cannot verify is the source is correct. * MUST: Packages must NOT contain any .la libtool archives, - /usr/lib/python2.4/site-packages/_gdalmodule.la - should be removed. * SHOULD: The reviewer should test that the package functions as described - I have not yet checked if these packages functionally work well as desired. Please give me some simple examples if you can. 3. Other things I have noticed: * Packaging issue: - in %prep stage: - %patch0 -p0: it is preferable that the suffix for original files is specified. - cd %{_builddir}/%{name}-%{version} is not necessary. The working directory at this stage is it. - in file entry: - Don't use %exclude unless there is no way to avoid using %exclude (such as %exclude %{_bindir}/*.pyc) as it makes file entry somewhat complicate. For example, specify %{_bindir}, %{_mandir}/man1/ entry so as not to use %exclude. Especially: - Explicitly REMOVE the files which are not included in any packages in %install stage (such as static archive) - I doubt that -devel package should have html directory. Owning files under html directory is sufficient. i.e: I suspect that %doc html should be %doc html/* (In reply to comment #1) > Okay. I will review this package. > First review: > > 1. From http://fedoraproject.org/wiki/Packaging/Guidelines : > > * License: > - Well, how can I know that this package can be distributed under > MIT? It seems that main package does not include any licence > document. By checking/examining the source files - Only them are legally binding. (In reply to comment #1) > Okay. I will review this package. Thank you for reviewing. I have fixed most, but not all, issues (see replies below for details): ----------------------------------------- Spec URL: http://www.soeterbroek.com/linux/fedora/extras/gdal/gdal.spec SRPM URL: http://www.soeterbroek.com/linux/fedora/extras/gdal/gdal-1.3.2-2.fc6.src.rpm * Sun Sep 10 2006 Joost Soeterbroek <fedora> 1.3.2-2 - change macros in changelog to prevent expansion - use %%{?dist} tag - change all tabs into two spaces - remove python-abi req - add python-numeric req to -python package - drop %%makeinstall macro - add timestamps to make install with option 'INSTALL="install -c -p"' - drop %%{python_sitearch} from %%files python - add full URL to Source - exclude /usr/lib/python2.4/site-packages/_gdalmodule.la - fixed misc. packaging issues ----------------------------------------- > First review: > > 1. From http://fedoraproject.org/wiki/Packaging/Guidelines : > > * License: > - Well, how can I know that this package can be distributed under > MIT? It seems that main package does not include any licence > document. see comment #2 > * rpmlint: > - is not silent. > W: gdal macro-in-%changelog configure > W: gdal macro-in-%changelog configure > - Use %% in changelog so as the description in changelog is not > expanded. done > W: gdal mixed-use-of-spaces-and-tabs > - if it is difficult finding where tabs are used, use > "sed -i -e 's|\t| |g' gdal.spec", which automatically changes > tabs in spec file into two spaces. done > * Tags: > - use %?dist tag done > * Requires: > - -python package requires python-numeric as gdal_merge.py includes > the line: "import Numeric" (this dependency cannot be automatically > checked). done > * BuildRequires: > - libjpeg-devel, zlib-devel, netcdf-devel <- required by hdf-devel > (ditto requires for -devel package) I am unsure what you mean with this one. Afaik all BuildRequires are allready present in the spec file. > * Encoding > - Several text files are encoded in ISO-8859. Change the encoding > to UTF-8 unless it is necessary. > - ./gdal-1.3.2-1/usr/share/gdal/seed_2d.dgn: Microstation > ./gdal-1.3.2-1/usr/share/gdal/seed_3d.dgn: data > Well, what are these files? Could you give me some examples? I am not really clear on what I am supposed to do here. > * Why the %makeinstall macro should not be used > - Don't use %makeinstall done > * Timestamps > - These (gdal) package contains lots of text files, so keeping > timestamps is preferable. Keep timestamps of those files (usually > 'make install' accepts the option 'INSTALL="install -c -p"'. done > * File and Directory Ownership > - Don't own the directory %python_sitearch itself. done > 2. From http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > > * MUST: The sources used to build the package must match.... > - Specify the URL of the source. I cannot verify is the source is > correct. done > * MUST: Packages must NOT contain any .la libtool archives, > - /usr/lib/python2.4/site-packages/_gdalmodule.la - should be removed. done > * SHOULD: The reviewer should test that the package functions as described > - I have not yet checked if these packages functionally work well > as desired. Please give me some simple examples if you can. Ok, I'll play around with some of the example data files in ftp://ftp.remotesensing.org/pub/gdal/data/. I will need some help from (upstream) community though, in order to make some sense of input and (expected) output data. > 3. Other things I have noticed: > * Packaging issue: > - in %prep stage: > - %patch0 -p0: it is preferable that the suffix for original files is > specified. done > - cd %{_builddir}/%{name}-%{version} is not necessary. The working > directory at this stage is it. done > - in file entry: > - Don't use %exclude unless there is no way to avoid > using %exclude (such as %exclude %{_bindir}/*.pyc) > as it makes file entry somewhat complicate. > For example, specify %{_bindir}, %{_mandir}/man1/ > entry so as not to use %exclude. > Especially: > - Explicitly REMOVE the files which are not included in any > packages in %install stage (such as static archive) done > - I doubt that -devel package should have html directory. > Owning files under html directory is sufficient. i.e: > I suspect that %doc html should be %doc html/* done One major issue I still have is with some programs in the *-bin package: $ gdalinfo mkdir: cannot create directory `/usr/bin/.libs': Permission denied /usr/bin/ld: cannot open output file /usr/bin/.libs/22786-lt-gdalinfo: No such file or directory collect2: ld returned 1 exit status Before checking 1.3.2-2: (In reply to comment #3) > > * BuildRequires: > > - libjpeg-devel, zlib-devel, netcdf-devel <- required by hdf-devel > > (ditto requires for -devel package) > > I am unsure what you mean with this one. Afaik all BuildRequires are allready > present in the spec file. I meant that: "libjpeg-devel, zlib-devel, netcdf-devel" is required by hdf-devel, so adding "libjpeg-devel, zlib-devel, netcdf-devel" for BuildRequires (or Requires on -devel package) is unnecessary because hdf-devel pulls them anyway. > > > * Encoding > > - Several text files are encoded in ISO-8859. Change the encoding > > to UTF-8 unless it is necessary. > Could you give me some examples? Well, gdal-1.3.2-1/usr/share/gdal/cubewerx_extra.wkt: ISO-8859 English text, with very long lines gdal-1.3.2-1/usr/share/gdal/s57expectedinput.csv: ISO-8859 English text gdal-1.3.2-1/usr/share/gdal/prime_meridian.csv: ISO-8859 text gdal-debuginfo-1.3.2-1/usr/src/debug/gdal-1.3.2/frmts/rmf/rmfdataset.cpp: ISO-8859 English text gdal-devel-1.3.2-1/usr/include/gdal/cpl_win32ce_api.h: ISO-8859 English text gdal-devel-1.3.2-1/usr/include/gdal/cpl_wince.h:ISO-8859 English text Also, one file has wrong end-of-line encoding. gdal-debuginfo-1.3.2-1/usr/src/debug/gdal-1.3.2/frmts/nitf/nitffile.c: ASCII English text, with CRLF, LF line terminators > > - ./gdal-1.3.2-1/usr/share/gdal/seed_2d.dgn: Microstation > > ./gdal-1.3.2-1/usr/share/gdal/seed_3d.dgn: data > > Well, what are these files? I simply want to know what these files are. done > > One major issue I still have is with some programs in the *-bin package: > > $ gdalinfo > mkdir: cannot create directory `/usr/bin/.libs': Permission denied > /usr/bin/ld: cannot open output file /usr/bin/.libs/22786-lt-gdalinfo: No such > file or directory > collect2: ld returned 1 exit status > I will check this after. Created attachment 136100 [details] Patch to install binary, not corrupted shell script (In reply to comment #4) > (In reply to comment #3) > > > > One major issue I still have is with some programs in the *-bin package: > > > > $ gdalinfo > > mkdir: cannot create directory `/usr/bin/.libs': Permission denied > > /usr/bin/ld: cannot open output file /usr/bin/.libs/22786-lt-gdalinfo: No such > > file or directory > > collect2: ld returned 1 exit status > > > > I will check this after. > Well, all the bash shell scripts under /usr/bin in -bin rpm are corrupted. Check if this patch fixes this issue. Created attachment 136101 [details]
gdal.spec I used
gdal.spec I used.
I have not checked this in detail, so please check my spec,
verify if the patch above work, and resubmit. Then I will
review it again.
Created attachment 136103 [details]
Patch to install binary, not corrupted shell script (modified)
Well, the previous patch is not sufficient.
Please use this patch and verify the result.
Created attachment 136104 [details]
gdal.spec I used (modified)
And the spec file I used (again modified)
* cfitsio support could be enabled (builds and is available in extras). * in my eyes libgeotiff should be compiled with external library (its currently under review). * pc raster support is currently compiled with internal library (should it stay like that?) Joost, please check my patch and spec file (in comment #7 and in comment #8), add some needed change you think, and re-sumbit spec and srpm. I will then re-check your spec. At least: %exclude %{_libdir}/*.la %exclude %{_libdir}/*.a %exclude %{_libdir}/python*/site-packages/*.a %exclude %{_libdir}/python*/site-packages/*.la Well, don't do these ways. Explicitly remove these files at %install stage. i.e. add rm -f %{buildroot}%{_libdir}/*.{a,la} rm -f %{buildroot}%{_libdir}/python*/site-packages/*.{a,la} to %install stage and don't use %exclude if it is possible. ( %exclude %{_bindir}/*.pyc %exclude %{_bindir}/*.pyo is needed anyway) And check my previous comment (comment #4 and comment #1). Also, I want to know your opinion against comment #9 (by Rudolf). Spec URL: http://www.soeterbroek.com/linux/fedora/extras/gdal/gdal.spec SRPM URL: http://www.soeterbroek.com/linux/fedora/extras/gdal/gdal-1.3.2-3.fc6.src.rpm * Wed Sep 13 2006 Joost Soeterbroek <fedora> 1.3.2-3 - enable cfitsio support, add cfitsio-devel BuildRequires - remove unwated files in %%install phase (rather than exclude in %%files) * Tue Sep 12 2006 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> 1.3.2-2.3 - Fix corrupted shell scripts problem more. * Tue Sep 12 2006 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> 1.3.2-2.2 - Fix BuildRequires, encoding, end-of-line encoding. - Install binary in -bin rpm, not corrupted shell scripts. (In reply to comment #9) > * cfitsio support could be enabled (builds and is available in extras). done in 1.3.2-3 > * in my eyes libgeotiff should be compiled with external library (its currently > under review). I have no idea/preference either way > * pc raster support is currently compiled with internal library (should it stay > like that?) I have no idea/preference either way (In reply to comment #12) > (In reply to comment #9) > I have no idea/preference either way It is always very preferable to have external tools, it is very hard to fix bugs, and especially security bugs when internal libraries are used. There are exception, when the internal library isn't really an independent project, and when the internal library is patched. well if the external library is completly forked alright... otherwise in my eyes those patches should rather be brought into the upstream library. just my opinion. (In reply to comment #14) > well if the external library is completly forked alright... otherwise in my > eyes those patches should rather be brought into the upstream library. just my > opinion. I'll leave it as it is for the time being.. (In reply to comment #13 and comment #14) Well, generally I agree with your comments. Joost, generally you must consider using external libraries when it is available (mainly for security reasons, see http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90 ). However, 1. both libcsf (pcraster) and libgeotiff are not available in FC/FE. So this is NOT a blocker. 2. Apparantly the internal pcraster library seems newer than the one available (and some many modifications are made on internal libraries) 3. When libgeotiff is available on FE, you should consider using external libgeotiff libraries. It seems that the codes included in this package and libgeotiff project package are actually SAME. However, currently this is not a blocker. So, anyway I won't make extenal/internal issue block this bug. Well, again I will check this package (in the comment #11) Before checking comment #11: Well, build log says: LIBTOOL support: yes LIBZ support: external GRASS support: no CFITSIO support: external PCRaster support: internal NETCDF support: yes LIBPNG support: external LIBTIFF support: external LIBGEOTIFF support: internal LIBJPEG support: external LIBGIF support: external OGDI support: no HDF4 support: no HDF5 support: yes KAKADU support: no JASPER support: no ECW support: no MrSID support: no POSTGRESQL support: yes MySQL support: yes XERCES support: no ODBC support: yes OCI support: no SDE support: no DODS support: no SQLite support: yes DWGdirect support no PANORAMA GIS support: no GEOS support: yes Statically link PROJ.4: no Traditional Python: yes NG SWIG Bindings: enable OGR building: yes ... It seems that jasper-devel-1.701.0 seems available on extras. I quite don't know about this package, however, if you want consider to support jasper support. (In reply to comment #17) > Before checking comment #11: > > Well, build log says: > > HDF4 support: no hdf4 is in extras (hdf/hdf-devel). > DODS support: no DODS is also in extras, more precisely, opendap is there, which is what replace DODS. It is possible that gdal looks for older versions (as a side note, I took some code from gdal m4 macros to do a detection of old dods version in a macro for detection of dods/dap, it is in upstream libdap...). Packages are libdap/libdap-devel for the C++ interface or libnc-dap/libnc-dap-devel for the nectdf dods enabled interface. (In reply to comment #18) > > HDF4 support: no > > hdf4 is in extras (hdf/hdf-devel). Strange. In spec file (in comment #11), it says: <snip> BuildRequires: hdf-devel <snip> %configure \ <snip> --with-hdf4=yes \ <snip> So I think that Joost want to support JDF4 support. Well, Joost, can you check what is happening? (In reply to comment #16) > 1. both libcsf (pcraster) and libgeotiff are not available in FC/FE. So this > is NOT a blocker. libgeotiff is blocked by a legal issue, so it is something that should be looked at carefully... Is there the same issue for the internal geotiff of gdal? The problem with libgeotiff seems to be the license on the data distributed as part of the package. Is that data included here? If not, there shouldn't be a problem, but then there shouldn't be a problem with getting just the library portion of libgeotiff in either. (In reply to comment #20 and comment #21) Patrice and Jason, good catch, thank you. Actually libgeotiff part in gdal code REALLY USES EPSG/POSC database. "REALLY USES" I said means that: Under gdal-1.3.2/frmts/gtiff/libgeotiff, the EPSG/POSC database epsg*.inc exist and these files are included in geonames.h, geovalues.h and these header files are used in .c source code. So, if using libgeotiff part in gdal code, it is ALSO legal issue. Joost, will you remove libgeotiff support? Third review. 1. From http://fedoraproject.org/wiki/Packaging/Guidelines : * Legal - Legal issue needs checking (as argued above). * Code Vs Content - Well, again, what are the following files? /usr/share/gdal/seed_2d.dgn (in gdal) /usr/share/gdal/seed_3d.dgn (in gdal) I don't know what these files are. If you also don't know what these are, remove these files. 2. From http://fedoraproject.org/wiki/Packaging/ReviewGuidelines : = Nothing. 3. Other things I have noticed: * Well, when including man files in rpm package, the format like "gdal_contour.1*" (not gdal_contour.1.gz) is prefered. * Also, when includes all .py, .pyo, .pyc files, the format like "%{python_sitearch}/gdal.py*" (not writing 3 files seperately) is prefered. * Check again what you want to support. * Perhaps it must be considered why HDF4 support is disabled. Created attachment 136274 [details]
support for libdap and fix for hdf
This fix the hdf4 issue, and add support for dods/libdap.
This should work for devel libdap, for previous FC releases
`dap-config --client-libs` should not be in LDFLAGS
(and shouldn't need to be in LDFLAGS).
(In reply to comment #24) > Created an attachment (id=136274) [edit] > support for libdap and fix for hdf I forgaot to add a Requires: libdap-devel for gdal-devel (In reply to comment #22) > (In reply to comment #20 and comment #21) > So, if using libgeotiff part in gdal code, it is ALSO > legal issue. Joost, will you remove libgeotiff support? Ok, I will. If I understand the configure options correctly, this would translate in these options (among others): --with-libtiff=no --with-geotiff=no --with-geos=yes Correct? (In reply to comment #24) > This should work for devel libdap, for previous FC releases > `dap-config --client-libs` should not be in LDFLAGS > (and shouldn't need to be in LDFLAGS). My dap-config does not have '--client-libs' option: $ dap-config --client-libs unknown option: --client-libs Suppose I should use: $ dap-config --libs -L/usr/lib -ldap -L/usr/lib -lcurl -L/usr/kerberos/lib -lssl -lcrypto -ldl -lz -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz -L/usr/lib -lxml2 -lz -lm -lpthread (In reply to comment #26) > (In reply to comment #22) > > (In reply to comment #20 and comment #21) > > > So, if using libgeotiff part in gdal code, it is ALSO > > legal issue. Joost, will you remove libgeotiff support? > > Ok, I will. > If I understand the configure options correctly, this would translate in these > options (among others): > > --with-libtiff=no > --with-geotiff=no > --with-geos=yes > > Correct? > Actually, using options: --with-libtiff=yes --with-geotiff=no results in configure error: using pre-installed libtiff. checking for XTIFFClientOpen in -lgeotiff... no configure: error: We require at least GeoTIFF 1.2.1. Consider using the one supplied with GDAL (In reply to comment #28) > Actually, using options: > > --with-libtiff=yes > --with-geotiff=no > > results in configure error: > > using pre-installed libtiff. > checking for XTIFFClientOpen in -lgeotiff... no > configure: error: We require at least GeoTIFF 1.2.1. Consider using the one > supplied with GDAL > > Well, actually I have the same error. I suppose this needs a patch. I will check it. And... adding "dap-config --client-libs" will not enable DODS support. I will check is "dap-config --libs" works. Then, will someone review my review request: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206487 ? (In reply to comment #29) > > And... adding "dap-config --client-libs" will not enable DODS support. > I will check is "dap-config --libs" works. > Sorry, DODS support was enabled by including libdap-devel. Well, again sorry. For me, "dap-config --client-libs" works. Created attachment 136286 [details]
gdal.spec I used
gdal.spec I used.
The big problem left is how to disable libgeotiff support.
(In reply to comment #31) > Well, again sorry. For me, "dap-config --client-libs" works. I am using libdap-devel-3.6.0-1.fc5: $ /usr/bin/dap-config --client-libs unknown option: --client-libs Well, it is found that: * on FC5, 'dap-config --libs' is okay (and 'dap-config --client-libs' bears error) * on FC6-devel, 'dag-config --libs' won't work!! /bin/sh /builddir/build/BUILD/gdal-1.3.2/libtool --mode=link g++ ogrinfo.o /builddir/build/BUILD/gdal-1.3.2/libgdal.la -o ogrinfo g++ ogrinfo.o -o .libs/ogrinfo /builddir/build/BUILD/gdal-1.3.2/.libs/libgdal.so -L/usr/lib/netcdf-3 -L/usr/lib/hdf -L/usr/lib -L/usr/kerberos/lib -lgeos -lodbc -ljasper -lhdf5 -lmfhdf -ldf -lgif -ljpeg -ltiff -lpng -lnetcdf -L/usr/include/cfitsio -L/usr/include/cfitsio/lib -lcfitsio -lpq -lrt -ldap -lcurl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv -ldl -lidn -lxml2 -lpthread -lsqlite3 -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lssl -lcrypto /builddir/build/BUILD/gdal-1.3.2/.libs/libgdal.so: undefined reference to `AISConnect::AISConnect(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /builddir/build/BUILD/gdal-1.3.2/.libs/libgdal.so: undefined reference to `RCReader::instance()' collect2: ld returned 1 exit status make[1]: *** [ogrinfo] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/gdal-1.3.2/ogr' make: *** [ogr-apps] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.80418 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.80418 (%build) on FC6-devel, it must "dap-config --client-libs". So, a switch is needed so if dap-config accepts '--client-libs', use it and otherwise, use '--libs' (In reply to comment #34) > Well, it is found that: > > * on FC5, 'dap-config --libs' is okay (and 'dap-config --client-libs' bears > error) This is what is done by the configure.in, so on fc5 there is nothing to add in LDFLAGS to have dap support. > * on FC6-devel, 'dag-config --libs' won't work!! In the version in devel the libdap library has been split in 3: libdapclient, libdapserver and libdap. gdal needs to link against what is provided by libdapclient. In that version `dap-config --libs` provides only libdap. So it doesn't work, and that's why dap-config --clients-libs has to be added in LDFLAGS. In the previous version (in FC5), the libdap library is linked with dap-config --libs and since it is not split everything is okay. > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.80418 (%build) > > on FC6-devel, it must "dap-config --client-libs". > > So, a switch is needed so if dap-config accepts '--client-libs', use > it and otherwise, use '--libs' That's approximately what is done in the latest autoconf macro. I'll propose a patch for the spec file shortly. Created attachment 136299 [details]
fix hdf link, and add support for libdap for FC5 and devel
I haven't tested on FC5, only on devel
Well, no way to fix for libgeotiff dependency. Now I make this bug block FE-legal. Further issues: * BLOCKER: gdal-devel ships an autoheader-generated header file (/usr/include/gdal/cpl_config.h). This violates autoconf's working principles and prevents autoconf-based packages from using gdal. * SHOULDFIX: The way cfitsio is being configed is broken: ATM, you pass --with-cfitsio=/usr/include/cfitso This causes gdal to use -I/usr/include/cfits and -L/usr/include/cfits/lib. The latter is incorrect. A proper way would be to pass --with-cfitsio and to append -I/usr/include/cfitsio to CPPFLAGS *** Bug 168719 has been marked as a duplicate of this bug. *** Removing FE-Legal blocker as spot checked this license issue (and declared that this package is surely wrong with license issue). Umm.. for now I will have to close this bug as "WONTFIX" as libgeotiff review request (bug 178162) was closed as "NOTABUG" due to EPSG data license problem. I have already contacted libgeotiff upstream to resolve license problem, however I have not yet received any response. Closing as WONTFIX, removing the blocker for FE-REVIEW and adding the blocker for FE-DEADREVIEW. When I receive any response from upstream, I will report it. Why cant we disable geotiff ? is some tehnical reason ? ok. Tooked latest gdal-1.4.0, made a patch that add --with-geotiff=no option. It compiles fine, we can get rid of geotiff, till we have update on licence issue. Anyone interested for a respin on this gdal ? I am really looking forward to add grass http://grass.itc.it/ into -extras. ~cristian Hi Cristian, http://www.mammothpostgresql.org/browser/mammothpostgresql/FC6/SRPMS/grass-6.0.2-1CMD.src.rpm?format=raw may be a good starting point for grass. I have packaged it for our product some monts ago. Regards, Devrim Hello, Cristian and Devrim: Currently another person submitted another GDAL review request, so I close this bug as DUPLICATE. Please attach a patch on the bug if you have a patch, thanks. *** This bug has been marked as a duplicate of 222042 *** |