[Bug 427121] Review Request: grib_api - ECMWF encoding/decoding GRIB software
bugzilla at redhat.com
bugzilla at redhat.com
Sat Feb 23 01:18:31 UTC 2008
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: grib_api - ECMWF encoding/decoding GRIB software
https://bugzilla.redhat.com/show_bug.cgi?id=427121
------- Additional Comments From tibbs at math.uh.edu 2008-02-22 20:18 EST -------
Builds OK; rpmlint has many complaints about the .sh files in the
documentation being executable, for example:
grib_api-devel.x86_64: W: spurious-executable-perm
/usr/share/doc/grib_api-devel-1.3.0/examples/precision_fortran.sh
which, though I don't like executable documentation in general, I suppose are
OK as long as they don't generate additional dependencies. (They don't seem
to do so.)
Also,
grib_api-devel.x86_64: E: zero-length
/usr/share/doc/grib_api-devel-1.3.0/data/missing_new.grib2
which I guess is used by one of the examples and needs to be empty (although
you should verify this; we don't really want to be shipping empty files unless
there's some reason for it).
You should use a complete URL for Source0; this seems to work:
http://www.ecmwf.int/products/data/software/download/software_files/%{name}-%{version}.tar.gz
I note that 1.4.0 is out; did you want to update to it? A naive update fails
to build because __dist_doc seems to have been changed a bit.
I believe the software is LGPLv3; that's what the upstream web site says, and
the LICENSE and source files seem to agree:
* Licensed under the GNU Lesser General Public License which
* incorporates the terms and conditions of version 3 of the GNU
* General Public License.
although that language is kind of bizarre and they also package a copy of the
GPLv3 (and a second copy of LGPLv3 for good measure, I guess) all in the
top-level directory of the tarball. Can you check with upstream to see
if they intend one or the other? Without clarification from them I am
inclined to say that LGPLv3 is correct.
The API documentation is about 70% of the -devel package, but I don't think
that's big enough to warrant splitting the package.
* source files match upstream:
36f31407f0c4aa64991f65f5d362d2b3efd986ea25b0d8f214772b21665a170b
grib_api-1.3.0.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK (although some definition of "grib" might be considered to
be kind to the users.
* dist tag is present.
* build root is OK.
X license field matches the actual license.
* license is open source-compatible.
* license text included in package.
X latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* debuginfo package looks complete.
? rpmlint has one complaint which may be valid.
* final provides and requires are sane:
grib_api-1.3.0-1.fc9.x86_64.rpm
grib_api = 1.3.0-1.fc9
=
libjasper.so.1()(64bit)
grib_api-devel-1.3.0-1.fc9.x86_64.rpm
grib_api-static = 1.3.0-1.fc9
grib_api-devel = 1.3.0-1.fc9
=
/bin/sh
grib_api = 1.3.0-1.fc9
* %check is present and all tests pass:
All 19 tests passed
All 14 tests passed
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers.
* no pkgconfig files.
* static libraries are in the -devel package, which is OK because there are no
dynamic libraries provided. The -static provide is present as required.
* no libtool .la files.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the Fedora-package-review
mailing list