Spec URL: http://www.gnupooh.org/RPM/gdal.spec SRPM URL: http://www.gnupooh.org/RPM/gdal-1.4.0-1.src.rpm Description: New packager, reviewer needed. I believe this SPEC file (or one very similar to it) was submitted a few years ago and rejected because it had some conflict with GRASS. However, this is a very important library for lots of GIS applications and I would like to try to resolve whatever issues are present. (GRASS 'borrowed' some of this library and thus there was two shared objects with the same name in two different packages.)
FYI: bug 205955 comment 41
Also check bug 178162 comment 14
Well, I guess whom ever tried to get the EPSG license changed didn't try very hard. I sent an e-mail to the contact on the website and they responsed right away and explicitly said it was not there intention to limit derived works and would like to change the wording to reflect that. They are asking for suggested wording. I would like to get someone more familar with the legal issues to work with them. Is there a contact (maybe at Red Hat?) that I can forward their response to?
Well, as long as we discussed on bug 178162 , unless * EPSG declares explicitly that they changed their license written on http://www.epsg.org/CurrentDB.html to be "free" enough to meet Fedora guidelines * and explicitly declare that the new license can be applied to the old database already used we cannot accept libgeotiff (then gdal), as Tom "spot" Callaway says "this is not accepted". Well, would you attach here the content of mail which the EPSG upstream sent to you? Then we may be able to ask Tom to check it again.
ping?
Created attachment 146041 [details] EMail from EPSG group I've got both the FSF (including RMS) and the current GeoTiff maintainer Frank Warmerdam all exchanging e-mail. The EPSG is planning on issuing an official statement after their next meeting ("in a few weeks"). They are working with Frank and Stallman about the exact wording that would be acceptable. Perhaps we can move on assuming this will all work it's way out???
Created attachment 146042 [details] EMail from EPSG group I've got both the FSF (including RMS) and the current GeoTiff maintainer Frank Warmerdam all exchanging e-mail. The EPSG is planning on issuing an official statement after their next meeting ("in a few weeks"). They are working with Frank and Stallman about the exact wording that would be acceptable. Perhaps we can move on assuming this will all work it's way out???
Interesting. I hope that EPSG and FSF would make some pleasant decision. Then.... Well, I almost forgot my previous review, however, * The default is "all make the option active which can be available". I forgot what option GDAL has, however, at least ------------------------------------------ --without-netcdf \ ------------------------------------------ if you _really_ want to do for some reason, please explain why because netcdf is available from Fedora Extras. Well, a spec file written by me is left on bug 205955 comment 32. (For this spec file, I don't think that we should make "-bin" subpackage). * Related to this, the use of internal copy of other libraries are forbidden on Fedora when they (the libraies) are available seperately. For example you have to submit another "libgeotiff" review request and make this package use libgeotiff package you created. * I forgot why -python subpackage is created, however, consider to make -python subpackage if it is of any sense. For packaging issue : * Well, there are several issues which must be fixed... please read http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ReviewGuidelines http://fedoraproject.org/wiki/Packaging/Python
(Well, in order to remove "NEEDINFO", once I close this bug and reopen. Please don't be upset....)
*** Bug 205955 has been marked as a duplicate of this bug. ***
look into bz#227646. I pend grass package over this gdal. If we still have no progress on this gdal, we can pack a geotiff-less one. I will try help out with this but only once Tom Callaway looks over this first. ~cristian
update, reworked on gathered files from this bugreport. Spec URL: http://openrisc.rdsor.ro/RPM/gdal.spec SRPM URL: http://openrsic.rdsor.ro/RPM/gdal-1.4.0-1.src.rpm - disable geotiff (untill license sorted out) - enable all options aviable from extras - pack perl and python modules - kill r-path from libs - pack all docs posible Can take a look ? Please feel free to update over. I disabled geotiff for now, and not included those uncertain EPSG data. Perl module are shiped too, and frmt documentations are shiped. Anyway, hdf-devel and netcdf-devel seems to not provide shared libs yet, i filled bug report against, i try to help tham get shared stuff. /cristian
(In reply to comment #13) > update, reworked on gathered files from this bugreport. > > Spec URL: http://openrisc.rdsor.ro/RPM/gdal.spec > SRPM URL: http://openrsic.rdsor.ro/RPM/gdal-1.4.0-1.src.rpm gets 404...
updated. Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-1.src.rpm sorry ... was too tired.
Created attachment 147829 [details] Mock build log of gdal-1.4.0-1.fc7 (In reply to comment #15) > updated. > Spec URL: http://openrisc.rdsor.ro/gdal.spec > SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-1.src.rpm Mockbuild failed on FC7 i386.
(In reply to comment #13) > Anyway, hdf-devel and netcdf-devel seems to not provide shared libs yet, > i filled bug report against, i try to help tham get shared stuff. I don't think hdf will ever support shared libraries, for netcdf, this is planned by upstream for next release, so if the netcdf-3 api is kept this will be solved. How is it relevant for gdal anyway?
>How is it relevant for gdal anyway? "hakcs" .. Do you "like" this: -------------/////-----> # err, remove -lnetcdf,-lmfhdf -extras netcdf-devel,hdf-devel not provide (yet). sed -e 's/-lnetcdf//' -e 's/-lmfhdf//' -e 's/-ldf//' < GDALmake.opt > GDALmake.opt.tmp mv -f GDALmake.opt.tmp GDALmake.opt <---------////------------ BTW, is it so hard to add shlib support ? I mean a -devel package something that: 1) can provide shdlib at lasta with a sane soname versioning. 2) can provide at last a pkg-config script to be able check what flags i need to use for that particular -devel lib. But anyway, we can live with "hakcs" ;-) people loves that.
netcdf-devvel and hdf-devel provide -lnetcdf -lmfhdf and -ldf. Maybe they are not searched for in the right directory.
GDAL doesn't built now because it doesn't find the ogdi include files.
ogdi is on its way for proposal/submit. Please grab/build it from: bz#222039 /cristian I still work on GDAL right now, has more issues with stupid -L/ includes and other goodies like that. ETA ~1hour
(In reply to comment #21) > ogdi is on its way for proposal/submit. > > Please grab/build it from: bz#222039 That's what I used.
Wait :-) I got now a more final version of GDAL, it works with ogdi. In minutes i will upload. /cristian
updated. Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-2.src.rpm can review ? anyway it stops at: /usr/src/redhat/BUILD/gdal-1.4.0/install-sh -c .libs/libgdal.lai /var/tmp/gdal-1.4.0-root/usr/lib64/libgdal.la install: .libs/libgdal.lai does not exist make: *** [install-lib] Error 1 becouse i removed rpath is this failure. if have a chance to look into would be fine, i try too to look into, but it will take a while.
(In reply to comment #24) > anyway it stops at: > /usr/src/redhat/BUILD/gdal-1.4.0/install-sh -c .libs/libgdal.lai /var/tmp/gdal-1.4.0-root/usr/lib64/libgdal.la > install: .libs/libgdal.lai does not exist > make: *** [install-lib] Error 1 > > becouse i removed rpath is this failure. Are you sure? Isn't it an issue with parallel build?
> BTW, is it so hard to add shlib support ? In a fork done by the packager? Yes. It can be hard to get it right, because some upstream developers prefer static libs as long as they like to break the API/ABI often. In that case, the package maintainer would need to examine upstream releases very closely and bump the SONAMEs appropriately. If not done correctly, e.g. if a simple libfoo.so or libfoo.so.0 is used and if all deps are rebuild with every new release of the library, there is hardly any added value in using custom shared libs. In a worst case, upstream publishes shared libs later, which conflict with the packager's fork in what SONAMEs are used.
> Are you sure? Isn't it an issue with parallel build? no, isn't smp flag. but can look into it. > bugs.michael well, right. No comment. Shlib implies soname and implies versioning wich will may break ABI.So better try upstream people convince to add shlib to their source.
Well, ogdi is in the state of discussion, so would you disable it? I will check when you upload the next spec/srpm.
updated. Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-3.src.rpm I disabled ogdi. Try to work on it olso, i think Patrice had a good suggestion for ogdi and i deal right now to do it.
(In reply to comment #24) > anyway it stops at: > /usr/src/redhat/BUILD/gdal-1.4.0/install-sh -c .libs/libgdal.lai /var/tmp/gdal-1.4.0-root/usr/lib64/libgdal.la > install: .libs/libgdal.lai does not exist > make: *** [install-lib] Error 1 > > becouse i removed rpath is this failure. > if have a chance to look into would be fine, i try too to look into, > but it will take a while. By the way, why did you remove rpath? libtool uses rpath, and when I disabled to remove rpath, compilation succeeded and the created binaries don't seem to have rpath (checked by /usr/lib/rpm/check-rpaths-worker). For -3: * doxygen is needed for BuildRequires * And why doxygen is needed for Requires of main package? * Why -python package needs development package for Requires?
r-path ?! hmm, ok. so r-path fixed. Ok, fixed issues, so updated to -4. (same url)
Ah.. I have forgotton to comment: * Use "rm -rf " for removing directories. ---------------------------------------------- + mv /var/tmp/gdal-1.4.0-root/usr/lib/Geo /var/tmp/gdal-1.4.0-root/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/ + rm /var/tmp/gdal-1.4.0-root/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Geo/GDAL rm: cannot remove `/var/tmp/gdal-1.4.0-root/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi/Geo/GDAL': Is a directory error: Bad exit status from /var/tmp/rpm-tmp.36948 (%install) ---------------------------------------------- ---------------------------------------------- %clean rm -r $RPM_BUILD_ROOT ----------------------------------------------- Also please use "rm -rf". For me "rm -r" causes hang up (I don't know the reason). And.. again to comment 30, why -python subpackage has the following? ----------------------------------------------- Requires: proj-devel ogdi-devel geos-devel netcdf-devel hdf5-devel Requires: jasper-devel cfitsio-devel hdf-devel libdap-devel librx-devel -----------------------------------------------
Thanks again to Balint for taking up the effort on this. Sorry I've been out of touch. Rick.
Well, then Balint, please update your spec/srpm for this package, too. Currently mockbuild doesn't pass because of some minor reason. Please check my comment 32.
Updated. Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-6.src.rpm More docs included, and busted out rpath forever by simply using external libtool.It builds fine in mock, rpmlint not complain. Please help with a review !
Created attachment 148521 [details] mock build log of gdal-1.4.0-6.fc7 Mockbuild of gdal-1.4.0-6 fails on FC7 i386 at least due to missing libtool.
Updated. Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-7.src.rpm sorry. i forgot to require libtool.
-devel will not build this in mock ... libtool from -devel contain: sys_lib_search_path_spec=`echo " /usr/lib/gcc/x86_64-redhat-linux/4.1.1/ /usr/lib/gcc/x86_64-redhat-linux/4.1.1/ /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../x86_64-redhat-linux/lib/x86_64-redhat-linux/4.1.1/ /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../x86_64-redhat-linux/lib/ /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../x86_64-redhat-linux/4.1.1/ /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../ /lib/x86_64-redhat-linux/4.1.1/ /lib/ /usr/lib/x86_64-redhat-linux/4.1.1/ /usr/lib/" | $SED -e "s@${gcc_dir}@\${gcc_dir}@g;s@${gcc_ver}@\${gcc_ver}@g"` and -devel use gcc 4.1.2 ... fill bugreport for -devel ?!
filled bz#229541 against libtool from fedora.
libtool fixed upstream. mock now build gdal against fedora-devel. Notice that not all mirror have latest libtool so safest is to grab latest libtool from download.fedora.redhat.com. latest is: libtool-1.5.22-10.x86_64.rpm, i download it by hand and install it on mock session. the link: Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-7.src.rpm
Created attachment 148675 [details] mockbuild log of gdal-1.4.0-7.fc7.i386 mockbuild of gdal-1.4.0-7 passed anyway on FC-devel i386. I will check later (well, this packge is large and it may take some time).
Well, for 1.4.0-7.fc7: * BuildRequires - mockbuild log says: ------------------------------------------------------- checking for Xerces C++... disabled ------------------------------------------------------- Can this be enabled by xerces-c-devel? * User dependent rebuild condition? - mockbuild log says: ------------------------------------------------------- Writing /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Geo/GDAL/Const/.packlist Appending installation info to /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod /bin/sh: /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod: Permission denied make[3]: [doc_site_install] Error 1 (ignored) make[3]: Leaving directory `/builddir/build/BUILD/gdal-1.4.0/swig/perl' make -f Makefile_Geo__OGR install ------------------------------------------------------- Well, this can be ignored for mockbuild, however, is this dangerous on rebuilding this package as root? * BuildRoot - BuildRoot does not follow current Fedora guideline (please check "Build root tag" section of http://fedoraproject.org/wiki/Packaging/Guidelines) * Header files location - Well, I think all the header files in -devel package should be hidded under %{_includedir}/%{name} to avoid namespace conflict. - And I suggest to fix %{_bindir}/gdal-config accordingly. - By the way what does "CONFIG_DEP_LIBS" in gdal-config mean? * Directory structure - Well, --------------------------------------------------------- # move python in the right path mv %{buildroot}%{_bindir}/*.py %{buildroot}%{_datadir}/gdal cp -p pymod/samples/*.py %{buildroot}%{_datadir}/gdal --------------------------------------------------------- Just explain why putting these python scripts under %{_bindir} is not right? * .la files - The following files are installed. ---------------------------------------------------------- /usr/lib/python2.5/site-packages/_gdalmodule.la ---------------------------------------------------------- * Redundant dependency - Currently the following explicit dependency are rather redundant. ---------------------------------------------------------- Requires: python >= 2.4 Requires: perl >= 5.8 ---------------------------------------------------------- Check for documentation files and source files may take more time...
update: Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-8.src.rpm *mock fedora-devel builds it fine. *rpmlint complain nothing. include my fixes by the review: (In reply to comment #42) > Well, for 1.4.0-7.fc7: > > * BuildRequires > - mockbuild log says: > ------------------------------------------------------- > checking for Xerces C++... disabled > ------------------------------------------------------- > Can this be enabled by xerces-c-devel? yes. enabled. (lots of stupid hardcoded paths, so workaround configure script) > > * User dependent rebuild condition? > - mockbuild log says: > ------------------------------------------------------- > Writing > /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Geo/GDAL/Const/.packlist > Appending installation info to > /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod > /bin/sh: /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod: Permission > denied > make[3]: [doc_site_install] Error 1 (ignored) > make[3]: Leaving directory `/builddir/build/BUILD/gdal-1.4.0/swig/perl' > make -f Makefile_Geo__OGR install > ------------------------------------------------------- > Well, this can be ignored for mockbuild, however, is this > dangerous on rebuilding this package as root? busted away into > /dev/null the generation of those files. > > * BuildRoot > - BuildRoot does not follow current Fedora guideline > (please check "Build root tag" section of > http://fedoraproject.org/wiki/Packaging/Guidelines) fixed. i apologise for this, its elementary thing :-( > * Header files location > - Well, I think all the header files in -devel package should > be hidded under %{_includedir}/%{name} to avoid namespace > conflict. moved. > - And I suggest to fix %{_bindir}/gdal-config accordingly. > - By the way what does "CONFIG_DEP_LIBS" in gdal-config mean? dont know, but can say _sure_ that grass use it ;-) ! (fixed other minor nits with it, so that long paths looks coherently now) > * Directory structure > - Well, > --------------------------------------------------------- > # move python in the right path > mv %{buildroot}%{_bindir}/*.py %{buildroot}%{_datadir}/gdal > cp -p pymod/samples/*.py %{buildroot}%{_datadir}/gdal > --------------------------------------------------------- > Just explain why putting these python scripts under %{_bindir} > is not right? 1) ok. i leave in bindir those in -python package. 2) but samples/* moved (-x mode) in docs section of -python package. > > * .la files > - The following files are installed. > ---------------------------------------------------------- > /usr/lib/python2.5/site-packages/_gdalmodule.la > ---------------------------------------------------------- excluded. > * Redundant dependency > - Currently the following explicit dependency are rather > redundant. > ---------------------------------------------------------- > Requires: python >= 2.4 > Requires: perl >= 5.8 > ---------------------------------------------------------- removed those. obviously unnessesary. > Check for documentation files and source files may take more > time... Included more docs, i think _all_ posible of tham. Olso included some autogenerated pdf flavors but only from folders where tetex pdf make not crash ;-)
I hope I can review -8 by tomorrow... (EST + 14h)
Well, for -8: * rpmlint - some rpmlint complaint: ------------------------------------------------------- E: gdal-debuginfo script-without-shebang /usr/src/debug/gdal-1.4.0/alg/gdal_tps.cpp W: gdal-debuginfo spurious-executable-perm /usr/src/debug/gdal-1.4.0/frmts/jpeg/gdalexif.h ------------------------------------------------------- perhaps permisson issue * python scripts in %{_bindir} - byte-compiled files are not needed and please %exclude them. ("Unnecessary Byte compilation" section of http://fedoraproject.org/wiki/Packaging/Python ) * man files triage - Please "triage" man files according to the corresponding binaries. It seems that some man files should be installed in -python subpackage. * License - LGPL codes seem to be included -------------------------------------------------------- ./ogr/ogrsf_frmts/ili/iom/LICENSE.lgpl (and around this file) ./ogr/ogrsf_frmts/shape/LICENSE.LGPL (and around this file) ./pymod/gdal2xyz.py (and around this file) ./pymod/samples/histrep.py -------------------------------------------------------- - Note: not used for fedora package, however having different license: -------------------------------------------------------- ./swig/php/php_osr.h (and around this file) - PHP 2.02 -------------------------------------------------------- - Well, there are lots of "TO_RESOLVE" issues written on PROVENANCE.TXT. We can leave as it is expecting that upstream would solve these issues?? Especially, the license of the files under ./data is unclear. * ogdi - As ogdi passed the review, would you enable ogdi again?
Tasaka, 1) Do you think have some chance to include this in with those license issues, just remove pieces of code like i did for geotiff ? 2) How would you do act with this package in this long license issues case ? And my statement: Anyway, i contacted author, wich seems to be the same like for ogdi (and he is really kind and understanded my issues, at last ogdi is solved), and hardwork to get rid of license issues in whatever the cost will be.
Well, actually I wonder to what degree we must try to resolve license problem by ourselves... * Fedora thinks that it is okay if no issues are found except that the package contains some codes and we don't know for now where the codes came from? * Or Fedora won't admit a package until the license of all codes included in the package became clear??
Is it a way to remove those questionable code from tarball ? and re-pack it ? Many of questioned code anyway reffer to proprietary formats like microstation,autocad balh blah, so even a stripped down gdal may be pretty usefull. I can do this. On the other side author promised that will contact all those people and try to count down that list to zero. Basicly he wrote all code from there, just have to ask for some sources that he used from various companies.
I feel that we can leave the may-be-problems issues to upstream for now because according to your comment you and the upstream are communicating well and upstream are trying hard to clarify the license issue.
If the problematic code may result in somebody suing fedora because of license violation, this is not acceptable, in my opinion. If it is just an issue of incompatible licenses because the authors made mistakes, this is acceptable, still in my opinion.
update: Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-8.src.rpm In an update please notice srpm that this as a complete repack of upstram gdal to a license safe fedora gdal source tarball. I explained every things in detail in PROVENANCE.TXT-fedora inside the tarball. Is this acceptable ? (we did so like this on xmms e.g) Is there a similar procedure for this kind of cases when need repack source? (In reply to comment #45) > Well, for -8: > > * rpmlint > - some rpmlint complaint: > ------------------------------------------------------- > E: gdal-debuginfo script-without-shebang /usr/src/debug/gdal-1.4.0/alg/gdal_tps.cpp > W: gdal-debuginfo spurious-executable-perm > /usr/src/debug/gdal-1.4.0/frmts/jpeg/gdalexif.h > ------------------------------------------------------- > perhaps permisson issue fixed all. > > * python scripts in %{_bindir} > - byte-compiled files are not needed and please %exclude them. > ("Unnecessary Byte compilation" section of > http://fedoraproject.org/wiki/Packaging/Python ) excluded. > > * man files triage > - Please "triage" man files according to the corresponding binaries. > It seems that some man files should be installed in -python subpackage. sorted out by their correct place. > > * License > - LGPL codes seem to be included > -------------------------------------------------------- > ./ogr/ogrsf_frmts/ili/iom/LICENSE.lgpl (and around this file) this plugin is removed from source acording to -fedora tarball > ./ogr/ogrsf_frmts/shape/LICENSE.LGPL (and around this file) ^^^^ hmm, authors problem. If its still unacceptable i remove olso plugin. please (overcomment) > ./pymod/gdal2xyz.py (and around this file) ^^^ didnt see nothing. (please overcomment) > ./pymod/samples/histrep.py ^^^ didnt see nothing. (please overcomment) > -------------------------------------------------------- > - Note: not used for fedora package, however having different > license: > -------------------------------------------------------- > ./swig/php/php_osr.h (and around this file) - PHP 2.02 > -------------------------------------------------------- removed whole php folder, acording to -fedora tarball > - Well, there are lots of "TO_RESOLVE" issues written on PROVENANCE.TXT. > We can leave as it is expecting that upstream would solve these issues?? > Especially, the license of the files under ./data is unclear. > > * ogdi sorted out each piece and removed those in a new tarbal repack. > - As ogdi passed the review, would you enable ogdi again? ogdi enabled.
remark: As tarball is 100% same as upstream tarball except some removed files, i didnt touch any other files inside tarball, so in this case in a separate manner i added inside the spec a separate patch to fix the compile process becouse those missing files due to uncompilable thing.
sorry the right path is: Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-9.src.rpm so its -9 indeed.
Well, now I am trying to update my rawhide system and I think this may take long because around 300 (or more?) update packages are released....
hi , i tried to compile this version: http://openrisc.rdsor.ro/gdal-1.4.0-9.src.rpm on fedora core 6 - ppc64 and i got this error: /usr/bin/ld: skipping incompatible /usr/lib64/libcom_err.so when searching for -lcom_err /usr/bin/ld: skipping incompatible /usr/lib64/libcom_err.a when searching for -lcom_err /usr/bin/ld: cannot find -lcom_err
(In reply to comment #55) > hi , i tried to compile this version: http://openrisc.rdsor.ro/gdal-1.4.0-9.src.rpm > I will ignore this, for several reason, so to help me please: 1) fill attachment with a pure mock session debug on ppc64 ! 2) make sure you use pure mock session from the scratch, and not a mixed biarch stuff, i cannot trust your ppc64 fedora install ! Anyway in fedora build system this will go through mock, wich is a clean pure distilled build-root, if on that fail i am sure its a bug otherwise i cannot trust any other 'custom' buildroot especialy biarch ones ! > on fedora core 6 - ppc64 and i got this error: > > > /usr/bin/ld: skipping incompatible /usr/lib64/libcom_err.so when searching for > -lcom_err > /usr/bin/ld: skipping incompatible /usr/lib64/libcom_err.a when searching for > -lcom_err > /usr/bin/ld: cannot find -lcom_err Yeah. same on sparc64 where 32bit is default, unless you make sure force true 32 bit mode and do: setarch ppc; su -; rpmbuild gdal.spec --target=ppc so, i am looking forward for a pure mock build ! I will test ppc64 tomorrow, but i am right now 99% sure you tryed a simple rpmbuild from 64bit land and your rpmbuild session is setted somehow to build default 32bit because from your logs for some reason it looks after 64 bit libs wich is abnormaly rejected for your 32 bit build .... Please let me know. /cristian
Created attachment 149019 [details] mock build log of gdal-1.4.0-9.fc7 mockbuild of gdal-1.4.0-9 fails on FC-devel i386.
becouse latest perl sucks ... filled bug report.
Created attachment 149100 [details] build log on ppc64 using the last src rpm build log on ppc64
(In reply to comment #59) > Created an attachment (id=149100) [edit] > build log on ppc64 using the last src rpm > > build log on ppc64 still ignore this. one nit: /var/tmp/rpm-tmp.60412: line 48: ogdi-config: command not found You havent build this in mock again !!! can you show me output of this: yum list installed | grep e2fsprogs-devel Please wait for -10 becouse i need update this package for latest python plus perl changes in devel.
(In reply to comment #58) > becouse latest perl sucks ... > filled bug report. > ok perl is solved nowdays perl-devel is required. Now python sucks it report wrong lookup paths (old 2.4) instead of 2.5 ... I still fight to look into, so will come up with -11 shortly.
(In reply to comment #60) > one nit: > /var/tmp/rpm-tmp.60412: line 48: ogdi-config: command not found > > You havent build this in mock again !!! > > can you show me output of this: > yum list installed | grep e2fsprogs-devel > > Please wait for -10 becouse i need update this package for latest python plus > perl changes in devel. yum list installed | grep e2fsprogs-devel e2fsprogs-devel.ppc64 1.39-7.fc6 installed
(In reply to comment #62) > (In reply to comment #60) > > > one nit: > > /var/tmp/rpm-tmp.60412: line 48: ogdi-config: command not found > > > > You havent build this in mock again !!! > > > > can you show me output of this: > > yum list installed | grep e2fsprogs-devel > > > > Please wait for -10 becouse i need update this package for latest python plus > > perl changes in devel. > > yum list installed | grep e2fsprogs-devel > e2fsprogs-devel.ppc64 1.39-7.fc6 installed ah you miss this 32 bit lib ! 'yum install e2fsprogs-devel.ppc' please install it and than post result. But i would like remind you to build it from scratch in mock session.
updated Spec URL: http://openrisc.rdsor.ro/gdal.spec SRPM URL: http://openrisc.rdsor.ro/gdal-1.4.0-10.src.rpm should build x86_64, i386 in mock. oh, please do 'setarch i686' before launch your mock session for i386 ...
Created attachment 149114 [details] mockbuild log of gdal-1.4.0-10.fc7.i386 This time mockbuild on FC-devel i386 is okay (1.4.0-10). Check the log if this is what you expect.
Thanks a lot Tasaka ! Yes its fine, no files are missing obviously from packages. Can give help to review issues for final approval ?
Okay. ---------------------------------------------- This package (gdal) is APPROVED by me. ----------------------------------------------
New Package CVS Request ======================= Package Name: gdal Short Description: Geospatial Data Abstraction Library Owners: cbalint Branches: FC-5 FC-6 devel InitialCC:
As I see gdal-1.4 will be soon available in Fedora Core 6 ande Fedora 7. Will you please make gpsdrive available soon afterwards because gdal is the mail dependency for it. Thank you.
and now for the spell checked version :) As I see gdal-1.4 will be soon available in Fedora Core 6 and Fedora 7. Will you please make gpsdrive available as soon as possible because gdal is the main dependency for gpsdrive. Thank you.
I tried building rpm and got dependencies missing on Fedora Core 6, so I installed missing dependencies: # yum install libungif-devel libjpeg-devel libtiff-devel unixODBC-devel mysql- devel sqlite-devel postgresql-devel proj-devel geos-devel netcdf-devel hdf5- devel ogdi-devel jasper-devel cfitsio-devel hdf-devel libdap-devel librx-devel perl-devel xerces-c-devel I tried again: $ rpmbuild gdal.spec error: Failed build dependencies: perl-devel >= 5.8 is needed by gdal-1.4.0-10.i386 I don't see perl-devel in fedora core 6 repositories.
The newest is -13 (still not released). If you want to try, you can download them from: http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/gdal/1.4.0-13.fc6/
(In reply to comment #72) > I tried building rpm and got dependencies missing on Fedora Core 6, so I > installed missing dependencies: > > # yum install libungif-devel libjpeg-devel libtiff-devel unixODBC-devel mysql- > devel sqlite-devel postgresql-devel proj-devel geos-devel netcdf-devel hdf5- > devel ogdi-devel jasper-devel cfitsio-devel hdf-devel libdap-devel librx-devel > perl-devel xerces-c-devel > > I tried again: > $ rpmbuild gdal.spec > error: Failed build dependencies: > perl-devel >= 5.8 is needed by gdal-1.4.0-10.i386 It builds in mock ! look in spec: %if "%{?dist}" == ".fc7" BuildRequires: perl-devel >= 5.8 %elseif BuildRequires: perl %endif but ?dist var make sense in mock build enviroment only. If you want just leave 'perl' instead of 'perl-devel' by hand than go rpmbuild-it, or otherwise i suggest to build it in mock enviroment. BTW, if have better idea to workaround FC6 let me know. > > I don't see perl-devel in fedora core 6 repositories.
(In reply to comment #71) > and now for the spell checked version :) > > As I see gdal-1.4 will be soon available in Fedora Core 6 and Fedora 7. > Will you please make gpsdrive available as soon as possible because gdal is the main dependency for gpsdrive. Well, i personaly not. Already maintain ogdi/gdal/ and soon grass. already got a list of infinite problemes with these, and the correct and right thing is to help olso upstream, so i think another gpsdrive (wich looks pretty biggy) would be an overload, and i dont know how that tool work in fact. Valent, why you dont try to go through submission proccess ? if you really want that tool in -extra, maybe you can help us with that ! The tool indeed looks great, so just a maintainer for -extras is needed :-) BTW, as start, read please the gdal -fedora comment form docs inside the package and keep in mind is a bit stripped version of upstream gdal, due to license problems. > > Thank you.
(In reply to comment #74) > look in spec: > > %if "%{?dist}" == ".fc7" > BuildRequires: perl-devel >= 5.8 > %elseif > BuildRequires: perl > %endif > > but ?dist var make sense in mock build enviroment only. > > If you want just leave 'perl' instead of 'perl-devel' by hand than go > rpmbuild-it, or otherwise i suggest to build it in mock enviroment. > > BTW, if have better idea to workaround FC6 let me know. Try this: BuildRequires: perl(ExtUtils::MakeMaker) This should work for both FC-6 and devel.
Sweet !!(In reply to comment #76) > (In reply to comment #74) > > look in spec: > > > > %if "%{?dist}" == ".fc7" > > BuildRequires: perl-devel >= 5.8 > > %elseif > > BuildRequires: perl > > %endif > > > > but ?dist var make sense in mock build enviroment only. > > > > If you want just leave 'perl' instead of 'perl-devel' by hand than go > > rpmbuild-it, or otherwise i suggest to build it in mock enviroment. > > > > BTW, if have better idea to workaround FC6 let me know. > > Try this: > > BuildRequires: perl(ExtUtils::MakeMaker) sweet !! Thx a ton Paul ! I go update, anyway there is another reason to include pkgconfig file olso ! > This should work for both FC-6 and devel.
(In reply to comment #73) > The newest is -13 (still not released). If you want to try, > you can download them from: > > http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/gdal/1.4.0- 13.fc6/ I get an error for this link.
(In reply to comment #75) > (In reply to comment #71) > > and now for the spell checked version :) > > > > As I see gdal-1.4 will be soon available in Fedora Core 6 and Fedora 7. > > Will you please make gpsdrive available as soon as possible because gdal is > the main dependency for gpsdrive. > > Well, i personaly not. Already maintain ogdi/gdal/ and soon grass. > already got a list of infinite problemes with these, and the correct and right > thing is to help olso upstream, so i think another gpsdrive (wich looks pretty > biggy) would be an overload, and i dont know how that tool work in fact. Thank you for your time and the will for maintaining these packages. > Valent, why you dont try to go through submission proccess ? if you > really want that tool in -extra, maybe you can help us with that ! > The tool indeed looks great, so just a maintainer for -extras is needed :-) You really don't wan't me maintaining anything :) I don't have the skills necessary for it. I'm a middle ground linux user/admin. But I can go to all formal channels and bug other people in fedora community to pick it up and do start mainaining it. So when will gdal be ready for including in fedora 6 extra of fedora 7 repositories? > BTW, as start, read please the gdal -fedora comment form docs inside the > package and keep in mind is a bit stripped version of upstream gdal, due > to license problems. > > > > > Thank you. Thank you!
(In reply to comment #79) > So when will gdal be ready for including in fedora 6 extra of fedora 7 > repositories? Already.