Bug 165955

It seems to me that the b in the version is really part of the version and that
the upstream use ascending ascii letters so it shouldn't be problematic.

Hi Patrice, I'll review this package ASAP.

Hi Patrice, I started to do a review of GrADS and immediately found the
opendap-devel BuildRequires.  Right now, opendap only builds on FC3.  It fails
to build on FC-4 and later (devel) since it has a number of problems with
respect to 64-bit cleanness, etc.  These problems prevent it from building on
x86_64 which then prevents it from building on Fedora Extras.

So, it seems that you have at least three options for GrADS:

 1) leave opendap-devel as a BuildRequires but only target FC-3

 2) remove the opendap-devel BuildRequires (will it still build?)

 3) help Tom Callaway cleanup opendap:
     https://www.redhat.com/archives/fedora-extras-list/2005-August/msg00091.html
     https://www.redhat.com/archives/fedora-extras-list/2005-August/msg00059.html
    so that it builds on FC-4 and later.

I think option #3 is by far the best, but you're free to do as you want.  
And I do hope to help out with the opendap cleanup but it depends on how 
busy (!) I am with work, etc.

I can't test a build on 64 bits so I can't help otherwise I would have tried to
help to build on 64 bits.

opendap is optionnal for grads, although it would be better to have it enabled.
I know some people that use grads as their dods client.

I have reposted a grads without opendap support and other changes, especially
those needed to build with the updated libsx.

http://www.environnement.ens.fr/docs/fc-srpms/grads-1.9b4-2.src.rpm

Hi Patrice, heres an incomplete review.  Please post an SRPM that builds
and I'll re-review (and probably approve since the fixes are minor).

needswork:
 - build fails with:
     Error: File not found:
       /var/tmp/grads-1.9b4-2-root-edhill/usr/bin/gradsdods
   which can be fixed by removing:
     %{_bindir}/gradsdods
 - lots of warnings about ignored return values from or implicit 
   re-definitions of fread, fwrite, sscanf, strncpy, etc. which 
   can perhaps be ignored but are worrisome
 - after removing "%{_bindir}/gradsdods", the package builds and 
   rpmlint reports:
      W: grads wrong-file-end-of-line-encoding 
         /usr/share/doc/grads-1.9b4/html/reference_card.pdf
      W: grads wrong-file-end-of-line-encoding 
         /usr/share/doc/grads-1.9b4/html/GrADS.css
      W: grads wrong-file-end-of-line-encoding 
         /usr/share/doc/grads-1.9b4/html/reference_card_scl.pdf
   which can probably be ignored

good:
 - source matches upstream
 - dir ownership and permissions look good
 - names and specfile look OK
 - license is included and looks OK
 - code not content
 - docs look OK
 - no need of -devel package

Hi Patrice. What's keeping you back from moving this package forward? The last
srpm you provided works for me after following Ed's comment on removing
'%{_bindir}/gradsdods' from spec file and also requiring libsx.  

There are some licencing issues. After I reported them (maybe without diplomacy)
on the gradsusr list, I got some feedbacks and clarifications for some files,
but not all. And the upstream doesn't seems to be very concerned by this issue.
I was hoping that after some time they would step up and clarify things, but it
didn't happen. The issue is that there are some files with licences incompatible
with the GPL which is the licence for most of the code. It is possible that the
copyright holders are ok with distributing their code under a GPL compatible
licence but don't care enough for doing a move.

Another (but less important) reason why I didn't move is that I submitted a
libdap that should integrate easily in fedora extras but Ed or Tom never
finished the reviewing.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167111

In case there is a libdap support there is a need to integrate a patch that
appeared on the gradsusr list, but I'll do that if needed.

Hi Patrice, now that libdap is in Extras are there any things you intend to 
update or add/remove here?  Please let me know what the status is and, when 
its ready, I'll give it a (hopefully!) last review.

Here is a new try:

http://www.environnement.ens.fr/perso/dumas/fc-srpms/grads-1.9b4-3.src.rpm

In that build, I have removed the files with GPL incompatible licences. I also
have applied the patch for a newer libnc-dap.

I have bundled the list of the files from src directory that have an
incompatible licence (in the file grads-removed-files-list), and added a shell
script, grads-remove-files, that removes the files. So to to regenerate the
sources, one could do something like:

spectool grads.spec
sh grads-remove-files

The previous srpm was certainly broken, or not what was intended. This one
should be right (with minor enhancements, removal of the data source as it is in
the tarball).

http://www.environnement.ens.fr/perso/dumas/fc-srpms/grads-1.9b4-4.src.rpm

Hi Patrice, I grabbed grads-1.9b4-4.src.rpm and took a closer look:

good:
 + source "matches" upstream in the sense that you've clearly spent a 
   lot of time carefully extracting only the files that have Fedora-
   compatible licenses and included them in a tarball derived from the 
   upstream tarball (and your extraction script for the un-ship-able 
   files was helpfully provided)
 + licenses are a mess but you've obviously put a lot of effort into 
   tracking down the licenses for every file that matters and have 
   correctly removed the ones that can't be in Extras
 + spec is legible and contains no obvious problems
 + builds in mock on FC-4
 + rpmlint reports:
     W: grads wrong-file-end-of-line-encoding \
        /usr/share/doc/grads-1.9b4/html/reference_card.pdf
     W: grads wrong-file-end-of-line-encoding \
        /usr/share/doc/grads-1.9b4/html/GrADS.css
     W: grads wrong-file-end-of-line-encoding  \
        /usr/share/doc/grads-1.9b4/html/reference_card_scl.pdf
   whiche are all ignore-able warnings
 + I installed and ran a few of the binaries and they worked 
   nicely--exactly per the tutorial

Congrats on beating this old software into an Extras package.  It 
doesn't look like the licensing was any fun to sort out.  In fact, 
the upstream maintainers are clearly linking together software with 
incompatible licenses and perhaps don't realize or even care.  Maybe 
they can contact the origianl authors (eg. Arlindo da Silva who is 
still apparently working at NASA Goddard) and get (some?) of the 
licenses changed so that more can be shipped.

In any case, I don't see any remaining blockers so its APPROVED.

The upstream maintainers are now fully aware and concerned by the licence
issues, so hopefully this should be solved in the future.

It builds in devel.

Package Change Request
======================
Package Name: grads
New Branches: EL-6
Owners: deji    


NOTE: I now maintain grads in Fedora, and Patrice (who takes care of the EPEL branches) does not want to maintain it in EL6, so I'm taking it up.

In case it matters, I am ok with Deji.

CVS done (by process-cvs-requests.py).