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@xxxxxxxxxxx 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@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@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@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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review