Bug 222042 - Review Request: GDAL - Geospatial Data Abstraction Library
Summary: Review Request: GDAL - Geospatial Data Abstraction Library
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
: 205955 (view as bug list)
Depends On: 222039 228134 229541 230608
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2007-01-09 19:12 UTC by Rick Niles
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-13 09:18:04 UTC
Type: ---
Embargoed:
mtasaka: fedora-review+
wtogami: fedora-cvs+


Attachments (Terms of Use)
EMail from EPSG group (6.27 KB, application/x-crossover-eml)
2007-01-19 22:12 UTC, Rick Niles
no flags Details
EMail from EPSG group (6.27 KB, application/x-crossover-eml)
2007-01-19 22:12 UTC, Rick Niles
no flags Details
Mock build log of gdal-1.4.0-1.fc7 (1.77 MB, text/plain)
2007-02-10 05:30 UTC, Mamoru TASAKA
no flags Details
mock build log of gdal-1.4.0-6.fc7 (76.79 KB, text/plain)
2007-02-21 18:33 UTC, Mamoru TASAKA
no flags Details
mockbuild log of gdal-1.4.0-7.fc7.i386 (1.15 MB, text/plain)
2007-02-23 15:59 UTC, Mamoru TASAKA
no flags Details
mock build log of gdal-1.4.0-9.fc7 (2.20 MB, text/plain)
2007-03-01 15:52 UTC, Mamoru TASAKA
no flags Details
build log on ppc64 using the last src rpm (753.52 KB, text/plain)
2007-03-02 11:06 UTC, flavio
no flags Details
mockbuild log of gdal-1.4.0-10.fc7.i386 (1.98 MB, text/plain)
2007-03-02 14:16 UTC, Mamoru TASAKA
no flags Details

Description Rick Niles 2007-01-09 19:12:29 UTC
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.)

Comment 1 Michael Schwendt 2007-01-09 19:38:10 UTC
FYI: bug 205955 comment 41

Comment 2 Mamoru TASAKA 2007-01-10 04:32:55 UTC
Also check bug 178162 comment 14

Comment 3 Rick Niles 2007-01-10 16:25:00 UTC
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?


Comment 4 Mamoru TASAKA 2007-01-10 17:01:06 UTC
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.

Comment 5 Mamoru TASAKA 2007-01-19 11:09:32 UTC
ping?

Comment 6 Rick Niles 2007-01-19 22:12:14 UTC
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???

Comment 7 Rick Niles 2007-01-19 22:12:28 UTC
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???

Comment 8 Mamoru TASAKA 2007-01-19 22:53:28 UTC
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

Comment 9 Mamoru TASAKA 2007-01-19 22:55:15 UTC
(Well, in order to remove "NEEDINFO", once I close this bug and
 reopen. Please don't be upset....)

Comment 10 Mamoru TASAKA 2007-02-07 05:27:26 UTC
*** Bug 205955 has been marked as a duplicate of this bug. ***

Comment 11 Mamoru TASAKA 2007-02-07 05:28:33 UTC
ping?

Comment 12 Balint Cristian 2007-02-07 11:19:52 UTC
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

Comment 13 Balint Cristian 2007-02-10 03:56:38 UTC
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

Comment 14 Mamoru TASAKA 2007-02-10 04:56:06 UTC
(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...

Comment 15 Balint Cristian 2007-02-10 05:00:42 UTC
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.

Comment 16 Mamoru TASAKA 2007-02-10 05:30:13 UTC
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.

Comment 17 Patrice Dumas 2007-02-10 09:48:02 UTC
(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?

Comment 18 Balint Cristian 2007-02-10 09:58:20 UTC
>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.


Comment 19 Patrice Dumas 2007-02-10 10:03:10 UTC
netcdf-devvel and hdf-devel provide -lnetcdf -lmfhdf and -ldf.
Maybe they are not searched for in the right directory.

Comment 20 Patrice Dumas 2007-02-10 11:30:58 UTC
GDAL doesn't built now because it doesn't find the ogdi 
include files.

Comment 21 Balint Cristian 2007-02-10 11:37:41 UTC
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

Comment 22 Patrice Dumas 2007-02-10 11:53:50 UTC
(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.

Comment 23 Balint Cristian 2007-02-10 11:57:51 UTC
Wait :-)

I got now a more final version of GDAL, it works with ogdi.
In minutes i will upload.

/cristian


Comment 24 Balint Cristian 2007-02-10 12:06:59 UTC
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.

Comment 25 Patrice Dumas 2007-02-10 12:08:45 UTC
(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?

Comment 26 Michael Schwendt 2007-02-10 12:11:44 UTC
> 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.

Comment 27 Balint Cristian 2007-02-10 12:44:32 UTC
> 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.


Comment 28 Mamoru TASAKA 2007-02-10 16:26:22 UTC
Well, ogdi is in the state of discussion, so would
you disable it?

I will check when you upload the next spec/srpm.

Comment 29 Balint Cristian 2007-02-10 16:54:55 UTC
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.



Comment 30 Mamoru TASAKA 2007-02-12 15:48:02 UTC
(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?

Comment 31 Balint Cristian 2007-02-12 15:56:11 UTC
r-path ?! 
hmm, ok. so r-path fixed.


Ok, fixed issues, so updated to -4. (same url)


Comment 32 Mamoru TASAKA 2007-02-12 17:00:01 UTC
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
-----------------------------------------------

Comment 33 Rick Niles 2007-02-14 16:30:54 UTC
Thanks again to Balint for taking up the effort on this.  Sorry I've been out of
touch.

Rick.


Comment 34 Mamoru TASAKA 2007-02-14 16:37:37 UTC
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.

Comment 35 Balint Cristian 2007-02-21 17:53:52 UTC
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 !

Comment 36 Mamoru TASAKA 2007-02-21 18:33:09 UTC
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.

Comment 37 Balint Cristian 2007-02-21 18:39:44 UTC
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.

Comment 38 Balint Cristian 2007-02-21 19:27:41 UTC
-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 ?!

Comment 39 Balint Cristian 2007-02-21 19:34:33 UTC
filled bz#229541 against libtool from fedora.

Comment 40 Balint Cristian 2007-02-23 12:37:24 UTC
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

Comment 41 Mamoru TASAKA 2007-02-23 15:59:21 UTC
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).

Comment 42 Mamoru TASAKA 2007-02-23 17:56:36 UTC
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...

Comment 43 Balint Cristian 2007-02-24 14:43:47 UTC
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 ;-)



Comment 44 Mamoru TASAKA 2007-02-24 17:15:38 UTC
I hope I can review -8 by tomorrow... (EST + 14h)

Comment 45 Mamoru TASAKA 2007-02-25 16:03:38 UTC
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?

Comment 46 Balint Cristian 2007-02-26 13:47:14 UTC
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.





Comment 47 Mamoru TASAKA 2007-02-26 15:54:17 UTC
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??

Comment 48 Balint Cristian 2007-02-26 16:07:24 UTC
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.


Comment 49 Mamoru TASAKA 2007-02-26 16:59:13 UTC
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.

Comment 50 Patrice Dumas 2007-02-26 19:20:34 UTC
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.

Comment 51 Balint Cristian 2007-02-28 00:37:15 UTC
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.


Comment 52 Balint Cristian 2007-02-28 00:40:37 UTC
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.

Comment 53 Balint Cristian 2007-02-28 00:43:05 UTC
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.

Comment 54 Mamoru TASAKA 2007-02-28 15:41:36 UTC
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.... 

Comment 55 flavio 2007-02-28 16:12:50 UTC
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

Comment 56 Balint Cristian 2007-02-28 22:44:13 UTC
(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


Comment 57 Mamoru TASAKA 2007-03-01 15:52:42 UTC
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.

Comment 58 Balint Cristian 2007-03-01 19:01:50 UTC
becouse latest perl sucks ...
filled bug report.


Comment 59 flavio 2007-03-02 11:06:26 UTC
Created attachment 149100 [details]
build log on ppc64 using the last src rpm

build log on ppc64

Comment 60 Balint Cristian 2007-03-02 11:55:46 UTC
(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.

Comment 61 Balint Cristian 2007-03-02 12:17:24 UTC
(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.


Comment 62 flavio 2007-03-02 12:30:32 UTC
(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       

Comment 63 Balint Cristian 2007-03-02 12:43:09 UTC
(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.




Comment 64 Balint Cristian 2007-03-02 13:25:53 UTC
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 ...




Comment 65 Mamoru TASAKA 2007-03-02 14:16:07 UTC
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.

Comment 66 Balint Cristian 2007-03-02 14:28:09 UTC
Thanks a lot Tasaka !
Yes its fine, no files are missing obviously from packages.

Can give help to review issues for final approval ?

Comment 67 Mamoru TASAKA 2007-03-02 15:38:12 UTC
Okay.
----------------------------------------------
  This package (gdal) is APPROVED by me.
----------------------------------------------

Comment 68 Balint Cristian 2007-03-02 15:46:58 UTC
New Package CVS Request
=======================
Package Name: gdal
Short Description: Geospatial Data Abstraction Library
Owners: cbalint
Branches: FC-5 FC-6 devel
InitialCC:

Comment 69 Valent Turkovic 2007-03-15 10:32:27 UTC
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.

Comment 70 Valent Turkovic 2007-03-15 10:34:23 UTC
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.

Comment 71 Valent Turkovic 2007-03-15 10:37:57 UTC
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.

Comment 72 Valent Turkovic 2007-03-15 10:45:45 UTC
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.

Comment 73 Mamoru TASAKA 2007-03-15 10:59:05 UTC
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/

Comment 74 Balint Cristian 2007-03-15 11:52:01 UTC
(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.



Comment 75 Balint Cristian 2007-03-15 12:14:23 UTC
(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.



Comment 76 Paul Howarth 2007-03-15 12:50:28 UTC
(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.


Comment 77 Balint Cristian 2007-03-15 13:19:31 UTC
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.

Comment 78 Valent Turkovic 2007-03-19 08:36:30 UTC
(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.

Comment 79 Valent Turkovic 2007-03-19 08:43:19 UTC
(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!



Comment 80 Mamoru TASAKA 2007-03-19 09:26:10 UTC
(In reply to comment #79)
> So when will gdal be ready for including in fedora 6 extra of fedora 7 
> repositories?

Already.


Note You need to log in before you can comment on or make changes to this bug.