Bug 435015 (gpp4)

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

More updates as per

https://bugzilla.redhat.com/show_bug.cgi?id=435017#c2

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
new srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-4.f8.src.rpm

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

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.

(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

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

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

(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

(Removing NEEDSPONSOR: bug 462250)

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>

(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.

(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.

(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.

(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.

(In reply to comment #10)
> By the way rebuild fails on ppc64:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=901509

Patched and fixed:

https://koji.fedoraproject.org/koji/taskinfo?taskID=903353

I also changed the naming to gpp4 and gpp4-devel, I'll do the same with:
https://bugzilla.redhat.com/show_bug.cgi?id=435016
https://bugzilla.redhat.com/show_bug.cgi?id=435017

new spec: http://www.stanford.edu/~fenn/packs/gpp4.spec
updated srpm: http://www.stanford.edu/~fenn/packs/gpp4-1.0.4-9.f8.src.rpm

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...)

(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

Some missing deps...
http://koji.fedoraproject.org/koji/taskinfo?taskID=909329

With fixing missing BuildRequires (automake, libtool), this
package is okay.

----------------------------------------------------------------------
    This package (gpp4) is APPROVED by mtasaka
----------------------------------------------------------------------

(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

New Package CVS Request
=======================
Package Name: gpp4
Short Description: LGPL CCP4 library
Owners: timfenn
Branches: F-9 F-10 EL-5
InitialCC: timfenn

cvs done.

tagged/built for all branches.

Okay, please submit push request on bodhi for F-9 (and F-10 later).
Closing.

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.

(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.

(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!