[Bug 227669] Review Request: ppl-0.9 - A modern C++ library providing numerical abstractions

bugzilla at redhat.com bugzilla at redhat.com
Thu Jun 7 20:29:49 UTC 2007


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: ppl-0.9 - A modern C++ library providing numerical abstractions


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





------- Additional Comments From bagnara at cs.unipr.it  2007-06-07 16:29 EST -------
> NOTE: From next time, please bump (increment) the release number
>       of spec file each time you modify spec file.
>       http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes

OK.

> * Must/Should be fixed
> ! Notes
> ? Questions
> = Okay
> 
> Now I am reviewing formally. For 0.9-6:
> 
> * Source
>   - The source in your srpm differ from what I downloaded
>     from the URL on your spec file??
> -----------------------------------------------------------------
> [tasaka1 at localhost ppl]$ ls -al *gz */*gz
> -rw-rw-r-- 1 tasaka1 tasaka1 6330518 2007-02-11 05:43
> ppl-0.9-6.fc8/ppl-0.9.tar.gz
> -rw------- 1 tasaka1 tasaka1 6023797 2006-03-12 00:00 ppl-0.9.tar.gz
> [tasaka1 at localhost ppl]$ md5sum *gz */*gz
> 4096c2927b36fbf7c5329a53b035bc33  ppl-0.9.tar.gz
> 4c92a57a851b53e57d63aa64f2bd1f3a  ppl-0.9-6.fc8/ppl-0.9.tar.gz
> -----------------------------------------------------------------

Fixed.

> * rpmlint
>   The result of rpmlint for srpm, binary rpms and the installed
>   rpms is attached.
> 
>   SUMMARY:
>   * Undefined non-weak symbols
>     - Two libraries have undefined non-weak symbols. For rpms which want to
>       provide also -devel subpackages, this cannot be allowed because linkage
>       against these libraries fails because of these symbols.
> 
>   * devel packge dependency on non-devel package
>     - Please explain
>       * why ppl-swiprolog requires ncurses-devel

Sorry, I do not understand this question.

>       * why ppl-utils requires glpk-devel

Because one of the utilities requires the GLPK library and, as far as I know,
there is only one package providing it, which is glpk-devel.

>       Usually non-devel packages should not require devel related
>       packages.

I see.  What should I do then?

>     = All other rpmlint complaints can be ignored.
> 
> * Unwanted call of autotools after configure
>   - Mock build log (will attach) says:
> ----------------------------------------------------------
> + make
> cd . && /bin/sh /builddir/build/BUILD/ppl-0.9/missing --run aclocal-1.9 -I m4
> /builddir/build/BUILD/ppl-0.9/missing: line 51: aclocal-1.9: command not found
> WARNING: `aclocal-1.9' is missing on your system.  You should only need it if
> <snip>
> /bin/sh ./config.status --recheck
> ----------------------------------------------------------
>   - Automated call of autotools and recall of config.status
>     is wrong. Perhaps the timestamps of configure vs configure.ac
>     are incorrect.

Should be OK now.

> * Timestamps
>   - For make install, please use (for this package)
> ----------------------------------------------------------
> make DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p" install
> ----------------------------------------------------------

OK.

>     Actually this package tries to install many documentaion/
>     image files/etc..., which are not modified or created during
>     rebuild and keeping timestamps on those files is recommended.

I am not sure I understand this.

> * Definitions in header files
>   - Some definitions in some header files are very dangerous
>     and may easyly cause definition conflict.
>     For example, /usr/include/ppl.hh has some definitions such that
> -----------------------------------------------------------
> #define HAVE_SYS_TYPES_H 1
> #define HAVE_UNISTD_H 1
> -----------------------------------------------------------
>     ... etc. These definition names are too generic and may cause
>     conflicts on definition name space when other header files
>     from other packages are included.

These are standard Autoconf macros.  What is the right thing to do?

>     Generally, these types of generic "#define" macro should be
>     included in header files.
>     Remove unneeded (and dangerous) #define and #ifdef macros
>     or change the names of macros to less generic.
> 
>   - And note that #ifdef macros are generally unhappy. At least
>     please ensure that #ifdef judgment does not affect the ABI
>     of the libraries.
> 
>     (Same for /usr/include/pwl.hh in -pwl-devel package)

I am probably missing something here, so please be patient.
ppl.hh is a very complex object.  It is not only an interface
file: it is also an implementation file as it contains
all the inline functions/methods and all the template code.
I have no idea how we could not use #ifdef's and #define's there.

> * About libppl_gprolog.so:
> ---------------------------------------------------------
> [mockbuild at localhost ~]$ ppl_gprolog 
> ppl_gprolog: error while loading shared libraries: libppl_gprolog.so: cannot
> open shared object file: No such file or directory
> ---------------------------------------------------------
>   * ppl_gprolog is not launched. Perhaps
>     - ppl_gprolog should be moved to where is not included in
>       default path
>     - or libppl_gprolog.so should be moved to where ldconfig
>       checks
>     - or ppl_gprolog should have rpath for %{_libdir}/%{name}

This one.  I thought I had fixed it by adding an -rpath option,
ppl_gprolog works, but now I get the following:

+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
*******************************************************************************
*
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
*          to fail. To ignore these errors, you can set the '$QA_RPATHS'
*          environment variable which is a bitmask allowing the values
*          below. The current value of QA_RPATHS is 0x0000.
*
*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.
*    0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
*               nor relative filenames and can therefore be a SECURITY risk
*    0x0004 ... insecure RPATHs; these are relative RPATHs which are a
*               SECURITY risk
*    0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
*               RPATHs; this is just a minor issue but usually unwanted
*    0x0010 ... the RPATH is empty; there is no reason for such RPATHs
*               and they cause unneeded work while loading libraries
*    0x0020 ... an RPATH references '..' of an absolute path; this will break
*               the functionality when the path before '..' is a symlink
*          
*
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
*   $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
*   $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
*  
* 'check-rpaths' is part of 'rpmdevtools'.
*
*******************************************************************************
ERROR   0001: file '/usr/lib64/ppl/libppl_swiprolog.so' contains a standard
rpath '/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/lib64/ppl/ppl_yap.so' contains a standard rpath
'/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/lib64/ppl/libppl_gprolog.so' contains a standard rpath
'/usr/lib64' in [/usr/lib64]
ERROR   0001: file '/usr/bin/ppl-config' contains a standard rpath '/usr/lib64'
in [/usr/lib64]
ERROR   0001: file '/usr/bin/ppl_lcdd' contains a standard rpath '/usr/lib64' in
[/usr/lib64]
ERROR   0001: file '/usr/bin/ppl_lpsol' contains a standard rpath '/usr/lib64'
in [/usr/lib64]
error: Bad exit status from /var/tmp/rpm-tmp.59747 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.59747 (%install)

Net result: I am totally confused.  Anyway, the sources with which I am working are:

http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl.spec
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/ppl-0.9.tar.gz
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-docfiles.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-configure.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-makefiles.patch


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the Fedora-package-review mailing list