Bug 435015 - (gpp4) Review Request: gpp4 - LGPL CCP4 library
Review Request: gpp4 - LGPL CCP4 library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 435018
  Show dependency treegraph
 
Reported: 2008-02-26 15:26 EST by Tim Fenn
Modified: 2008-11-07 16:13 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 03:05:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mtasaka: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Tim Fenn 2008-02-26 15:26:20 EST
Spec URL: http://www.stanford.edu/~fenn/packs/gpp4.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-2.f8.src.rpm
Description: The ggp4 library is a v2.1 LGPL version of the 5.0.2 CCP4 library (http://www.ccp4.ac.uk/main.html), used in crystallography data storage and I/O routines. This version was patched by Ralf Grosse-Kunstleve to address some of the more serious deficiencies of the older libraries and a GNU autotools build environment developed by Paul Emsley and Morten Kjeldgaard.

Also see:
http://www.bioxray.dk/~mok/gpp4.php
http://www.ccp4.ac.uk/main.html
Comment 1 Tim Fenn 2008-05-26 19:44:51 EDT
Source RPM and spec file updated to bring RPM inline with current Fedora guidelines.

Spec URL: http://www.stanford.edu/~fenn/packs/gpp4.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-3.f8.src.rpm
Comment 3 Tim Fenn 2008-05-27 17:18:07 EDT
Removed static libs.

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
new srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-5.f8.src.rpm
Comment 4 Ralf Corsepius 2008-05-28 02:09:46 EDT
This package suffers from similar issues as mmdb and ssm.

Additional problem:
This package's naming is inconsistent and likely doesn't work.

The src.rpm uses "gpp4", the binary packages are called "gpp4" and "gpp4-devel",
gpp4-devel however "Requires: libgpp4 = %{version}-%{release}". This doesn't work.

If you want to call the binary packages "libgpp4" rsp. "libgpp4-devel" (Which,
as far as I understand, seems to be what you intend), you'll have to use rpm's
"-n <pkg-name>" construct in %files, %description and %package.
Comment 5 Tim Fenn 2008-05-28 21:41:32 EDT
(In reply to comment #4)
> This package suffers from similar issues as mmdb and ssm.
> 

Comments to ssm/mmdb propogated here.

> Additional problem:
> This package's naming is inconsistent and likely doesn't work.
> 
> The src.rpm uses "gpp4", the binary packages are called "gpp4" and "gpp4-devel",
> gpp4-devel however "Requires: libgpp4 = %{version}-%{release}". This doesn't work.
> 
> If you want to call the binary packages "libgpp4" rsp. "libgpp4-devel" (Which,
> as far as I understand, seems to be what you intend), you'll have to use rpm's
> "-n <pkg-name>" construct in %files, %description and %package.
> 

Fixed (also done with ssm/mmdb).

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
new srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-6.f8.src.rpm
Comment 6 Tim Fenn 2008-05-29 23:41:28 EDT
A few minor edits to address:

library-without-ldconfig-postin
library-without-ldconfig-postun

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
new srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-7.f8.src.rpm
Comment 7 Jason Tibbitts 2008-06-06 15:12:52 EDT
I'm wondering if it wouldn't just be simpler to call the package libgpp4 and
save yourself the trouble.  As it is, get things like this nice long
%description which doesn't actually make it into any of the packages.

Plenty of rpmlint spew worth looking at:

  W: file-not-utf8 /usr/share/doc/libgpp4-devel-1.0.4/doc/latex/csym_f_page.tex
doxygen creates this; I'm not sure if it's worth converting or if it even matters.

There are several complaints about the contents of the "test" directory being
packaged as documentation, which I think is particularly ill-advised.  Why
aren't the tests just called at build time in a %check section?

  W: spurious-executable-perm 
   /usr/share/doc/libgpp4-devel-1.0.4/test/load_syminfo
  W: doc-file-dependency 
   /usr/share/doc/libgpp4-devel-1.0.4/test/.libs/load_syminfo rtld(GNU_HASH)
  W: doc-file-dependency 
   /usr/share/doc/libgpp4-devel-1.0.4/test/.libs/load_syminfo libc.so.6()(64bit)
  W: doc-file-dependency 
   /usr/share/doc/libgpp4-devel-1.0.4/test/.libs/load_syminfo 
   libc.so.6(GLIBC_2.2.5)(64bit)
  W: doc-file-dependency 
   /usr/share/doc/libgpp4-devel-1.0.4/test/.libs/load_syminfo libm.so.6()(64bit)

  W: hidden-file-or-dir /usr/share/doc/libgpp4-devel-1.0.4/test/.libs
  W: hidden-file-or-dir /usr/share/doc/libgpp4-devel-1.0.4/test/.deps

  E: arch-dependent-file-in-usr-share 
   /usr/share/doc/libgpp4-devel-1.0.4/test/load_syminfo.o
  E: arch-dependent-file-in-usr-share 
   /usr/share/doc/libgpp4-devel-1.0.4/test/.libs/load_syminfo
Comment 8 Tim Fenn 2008-06-09 17:36:04 EDT
(In reply to comment #7)
> I'm wondering if it wouldn't just be simpler to call the package libgpp4 and
> save yourself the trouble.  As it is, get things like this nice long
> %description which doesn't actually make it into any of the packages.
> 

I agree - I'll try to get this change made upstream, along with the others I've
gathered here.

> Plenty of rpmlint spew worth looking at:
> 
>   W: file-not-utf8 /usr/share/doc/libgpp4-devel-1.0.4/doc/latex/csym_f_page.tex
> doxygen creates this; I'm not sure if it's worth converting or if it even matters.
> 

Not sure what the best course of action is here - could just have doxygen spit
out the html docs...

> There are several complaints about the contents of the "test" directory being
> packaged as documentation, which I think is particularly ill-advised.  Why
> aren't the tests just called at build time in a %check section?
> 

For now I've removed the test directory from the -devel package, and I'll make
some suggestions upstream to move the test folder to TESTS in automake.

updated spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
updated srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-8.f8.src.rpm
Comment 9 Mamoru TASAKA 2008-10-23 14:23:56 EDT
(Removing NEEDSPONSOR: bug 462250)
Comment 10 Mamoru TASAKA 2008-10-24 13:58:35 EDT
Umm.. I cannot guess why you want to name binary rpm names as
libgpp4 and libgpp4-devel. Simply gpp4 and gpp4-devel is better.

Debian seems to name binary debs providing system wide libraries
as libXXXXX (like libpango1.0-0) while Fedora simply names binary
rpms using source tarball name as much as possible (like pango)
(For me I maintain oniguruma while debian uses libonig as binary
 deb names...)
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#General_Naming

By the way rebuild fails on ppc64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=901509
Now that I am sponsoring you, you can try to rebuild arbitrary srpms
on koji by

$ koji build --scratch <target> <srpm_you_want_to_try>
where target can be dist-f11, dist-f10, dist-f9-updates-candidate
or dist-f8-updates-candidate.
If the build is successful, the rebuilt rpms and some logs are
put for one week or so under:
http://koji.fedoraproject.org/scratch/<your_FAS_name>/task_<task_id>
Comment 11 Jason Tibbitts 2008-10-24 14:04:07 EDT
(In reply to comment #10)
> Umm.. I cannot guess why you want to name binary rpm names as
> libgpp4 and libgpp4-devel. Simply gpp4 and gpp4-devel is better.

He's done that for mmdb as well; I had thought that eventually I would understand the reason for it but I haven't figured it out yet.
Comment 12 Mamoru TASAKA 2008-10-24 14:15:24 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > Umm.. I cannot guess why you want to name binary rpm names as
> > libgpp4 and libgpp4-devel. Simply gpp4 and gpp4-devel is better.
> 
> He's done that for mmdb as well; I had thought that eventually I would
> understand the reason for it but I haven't figured it out yet.

I guess Tim will reply in a few days.
Comment 13 Tim Fenn 2008-10-24 16:28:18 EDT
(In reply to comment #10)
> Umm.. I cannot guess why you want to name binary rpm names as
> libgpp4 and libgpp4-devel. Simply gpp4 and gpp4-devel is better.
> 

I'd be happy to rename it gpp4 and gpp4-devel (as I originally packaged it), but see comments 4-8 above - I'm a bit confused as to what is best here.

> 
> By the way rebuild fails on ppc64:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=901509
> Now that I am sponsoring you, you can try to rebuild arbitrary srpms
> on koji by
> 
> $ koji build --scratch <target> <srpm_you_want_to_try>
> where target can be dist-f11, dist-f10, dist-f9-updates-candidate
> or dist-f8-updates-candidate.
> If the build is successful, the rebuilt rpms and some logs are
> put for one week or so under:
> http://koji.fedoraproject.org/scratch/<your_FAS_name>/task_<task_id>

Many thanks for the tip, Mamoru.
Comment 14 Mamoru TASAKA 2008-10-24 22:48:45 EDT
(In reply to comment #13)
> (In reply to comment #10)
> > Umm.. I cannot guess why you want to name binary rpm names as
> > libgpp4 and libgpp4-devel. Simply gpp4 and gpp4-devel is better.
> > 
> 
> I'd be happy to rename it gpp4 and gpp4-devel (as I originally packaged it),
> but see comments 4-8 above - I'm a bit confused as to what is best here.

Both Ralf and Jason were saying that you seemed to have some reason
you want to name the binary rpm as libgpp4.

However as I said on Fedora it is preferable to use tarball name for
srpm/binary rpms as much as possible. And as you say you are happy with
naming binary rpms as gpp4/gpp4-devel please just use these names.
Comment 16 Mamoru TASAKA 2008-10-26 11:48:42 EDT
Some notes

? License
  - License tag can be okay with LGPLv2 as README file
    declares so, however all files under src/ directories
    are actually under LGPLv2+.
    Would you ask upstream about this? (as it is okay
    with LGPLv2, this is not a blocker)

* Source tarball
  - The tarball in the srpm differs from what I could
    download from the URL written as %SOURCE
------------------------------------------------------
514623 2008-06-10 05:21 gpp4-1.0.4-9.fc10.src/gpp4-1.0.4.tar.gz
498933 2007-09-03 00:00 orig/gpp4-1.0.4.tar.gz

48931781425a5b79a8255ebefaed24b3  orig/gpp4-1.0.4.tar.gz
7494566588545eb167b1c4c6e486cdf4  gpp4-1.0.4-9.fc10.src/gpp4-1.0.4.tar.gz
------------------------------------------------------

* Linkage error
  - rpmlint shows
------------------------------------------------------
gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 sincos
gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 sqrt
gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 rintf
gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 lrint
------------------------------------------------------
    For packages providing -devel subpackage these rpmlint warnings
    cannot be allowed because these will cause linkage error when
    using these libraries.
    I guess linking to libm.so (-lm) will remove these warnings.

    Note:
    You can use rpmlint also for installed rpms like:
    $ rpmlint gpp4
    which will show you these warnings.

* Duplicate documents
  - Generally there is no need to include a document file as %doc
    to both main and -devel packages.

* Timestamps
------------------------------------------------------
make install DESTDIR=$RPM_BUILD_ROOT install='install -p'
------------------------------------------------------
  - This should be "INSTALL='install -p'".

? Another rpmlint issue
------------------------------------------------------
gpp4-devel.i386: W: file-not-utf8 /usr/share/doc/gpp4-devel-1.0.4/doc/latex/csym_f_page.tex
------------------------------------------------------
  - Well it may be preferable to convert this file to UTF-8,
    however I am not sure if tex supports UTF-8 tex file
    (at least it is well-known that platex does not support
     Japanese UTF-8 tex files...)
Comment 17 Tim Fenn 2008-10-27 16:29:35 EDT
(In reply to comment #16)
> Some notes
> 
> ? License
>   - License tag can be okay with LGPLv2 as README file
>     declares so, however all files under src/ directories
>     are actually under LGPLv2+.
>     Would you ask upstream about this? (as it is okay
>     with LGPLv2, this is not a blocker)
> 

Will do - will report back on this asap.

> * Source tarball
>   - The tarball in the srpm differs from what I could
>     download from the URL written as %SOURCE
> ------------------------------------------------------
> 514623 2008-06-10 05:21 gpp4-1.0.4-9.fc10.src/gpp4-1.0.4.tar.gz
> 498933 2007-09-03 00:00 orig/gpp4-1.0.4.tar.gz
> 
> 48931781425a5b79a8255ebefaed24b3  orig/gpp4-1.0.4.tar.gz
> 7494566588545eb167b1c4c6e486cdf4  gpp4-1.0.4-9.fc10.src/gpp4-1.0.4.tar.gz
> ------------------------------------------------------
> 

ah, stupid mistake on my part (was using a .tar.gz from a "make build").  Fixed.

> * Linkage error
>   - rpmlint shows
> ------------------------------------------------------
> gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 sincos
> gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 sqrt
> gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 rintf
> gpp4.i386: W: undefined-non-weak-symbol /usr/lib/libgpp4.so.0.0.0 lrint
> ------------------------------------------------------
>     For packages providing -devel subpackage these rpmlint warnings
>     cannot be allowed because these will cause linkage error when
>     using these libraries.
>     I guess linking to libm.so (-lm) will remove these warnings.
> 

Fixed.

> 
> * Duplicate documents
>   - Generally there is no need to include a document file as %doc
>     to both main and -devel packages.
> 

Fixed.

> * Timestamps
> ------------------------------------------------------
> make install DESTDIR=$RPM_BUILD_ROOT install='install -p'
> ------------------------------------------------------
>   - This should be "INSTALL='install -p'".
> 

Fixed.

> ? Another rpmlint issue
> ------------------------------------------------------
> gpp4-devel.i386: W: file-not-utf8
> /usr/share/doc/gpp4-devel-1.0.4/doc/latex/csym_f_page.tex
> ------------------------------------------------------
>   - Well it may be preferable to convert this file to UTF-8,
>     however I am not sure if tex supports UTF-8 tex file
>     (at least it is well-known that platex does not support
>      Japanese UTF-8 tex files...)

From my experience with latex, a package has to be added to the document (utf8) in order for latex to understand it.

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
updated srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-10.f8.src.rpm
Comment 18 Mamoru TASAKA 2008-10-28 11:40:12 EDT
Some missing deps...
http://koji.fedoraproject.org/koji/taskinfo?taskID=909329
Comment 19 Mamoru TASAKA 2008-10-28 13:23:40 EDT
With fixing missing BuildRequires (automake, libtool), this
package is okay.

----------------------------------------------------------------------
    This package (gpp4) is APPROVED by mtasaka
----------------------------------------------------------------------
Comment 20 Tim Fenn 2008-10-28 20:11:04 EDT
(In reply to comment #19)
> With fixing missing BuildRequires (automake, libtool), this
> package is okay.
> 

Done.

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
updated srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-11.f8.src.rpm
Comment 21 Tim Fenn 2008-10-28 20:13:21 EDT
New Package CVS Request
=======================
Package Name: gpp4
Short Description: LGPL CCP4 library
Owners: timfenn
Branches: F-9 F-10 EL-5
InitialCC: timfenn
Comment 22 Kevin Fenzi 2008-10-29 17:34:01 EDT
cvs done.
Comment 23 Tim Fenn 2008-10-29 21:58:12 EDT
tagged/built for all branches.
Comment 24 Mamoru TASAKA 2008-10-30 03:05:37 EDT
Okay, please submit push request on bodhi for F-9 (and F-10 later).
Closing.
Comment 25 Mamoru TASAKA 2008-11-07 02:25:01 EST
Would you rebuild gpp4 and mmdb also for F-11 branch?

Also, please submit requests to push F-9/10 gpp4/mmdb packages into
repositories.
Comment 26 Mamoru TASAKA 2008-11-07 14:02:34 EST
(In reply to comment #25)
> Would you rebuild gpp4 and mmdb also for F-11 branch?
> 
> Also, please submit requests to push F-9/10 gpp4/mmdb packages into
> repositories.

Ah, I found F-11 gpp4/mmdb. So please submit requests to push F-9/10 gpp4/mmdb
into repositories.
Comment 27 Tim Fenn 2008-11-07 16:13:31 EST
(In reply to comment #26)
> (In reply to comment #25)
> > Would you rebuild gpp4 and mmdb also for F-11 branch?
> > 
> > Also, please submit requests to push F-9/10 gpp4/mmdb packages into
> > repositories.
> 
> Ah, I found F-11 gpp4/mmdb. So please submit requests to push F-9/10 gpp4/mmdb
> into repositories.

Done!

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