[Bug 227669] New: Review Request: <ppl-0.9> - <A modern C++ library providing numerical abstractions>
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
Summary: Review Request: <ppl-0.9> - <A modern C++ library providing numerical abstractions> Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: andreac81@hotmail.com QAContact: fedora-package-review@redhat.com
Spec URL: http://www.cs.unipr.it/~cimino/ppl.spec SRPM URL: http://www.cs.unipr.it/~cimino/ppl-0.9-1.src.rpm
Description: The Parma Polyhedra Library (PPL) is a modern C++ library providing numerical abstractions especially targeted at applications in the field of analysis and verification of complex systems. The PPL can handle all the convex polyhedra that can be defined as the intersection of a finite number of (open or closed) hyperspaces, each described by an equality or inequality (strict or non-strict) with rational coefficients. The PPL also handles restricted classes of polyhedra that offer interesting complexity/precision tradeoffs. The library also supports finite powersets of (any kind of) polyhedra and linear programming problems solved with an exact-arithmetic version of the simplex algorithm.
We are willing tho improve the .spec file to meet the Fedora standards.
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
bugs.michael@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: <ppl-0.9> - |Review Request: <ppl-0.9> - |<A modern C++ library |<A modern C++ library |providing numerical |providing numerical |abstractions> |abstractions> OtherBugsDependingO| |177841 nThis| |
------- Additional Comments From bugs.michael@gmx.net 2007-02-09 19:27 EST ------- The spec file needs *a lot* of work.
Let me try to cover many issues in this reply, although I'm afraid I will fail to catch all due to the sheer number of packaging problems. In particular, sub-packages are missing.
Run "rpmlint" with option -i on your src.rpm (and also the binary rpms!):
$ rpmlint ppl-0.9-1.src.rpm W: ppl summary-ended-with-dot The Parma Polyhedra Library: a C++ library for numerical abstractions. E: ppl no-changelogname-tag W: ppl invalid-license GPL v2 W: ppl hardcoded-packager-tag %{packager} W: ppl hardcoded-prefix-tag /usr W: ppl setup-not-quiet W: ppl mixed-use-of-spaces-and-tabs (spaces: line 12, tab: line 1)
All findings are worth fixing. "setup-not-quiet" can be ignored, but when adding the -q option to the %setup line of the spec file, the build logs get more readable as the contents of the extracted source archive are not included.
"no-changelogname-tag" means that your spec file is missing a standard %changelog section where you sum up important changes applied to the spec file.
%define builddir $RPM_BUILD_DIR/%{name}-%{version}
This is unused in the spec file, so don't define it.
%define name ppl %define version 0.9 %define release 1
Don't. All macros are defined in the lines below. Here:
Name: %{name} Version: %{version} Release: %{release}
Fill in the values in those lines, instead of redefining macros via macros. Do this:
Name: ppl Version: 0.9 Release: 1
It defines %name, %version, and %release. You can move these lines to the top of the spec file and improve readability.
Vendor: ppl-devel@cs.unipr.it Packager: %{packager}
Don't. Build systems need to be able to override these, so only define them in your local configuration. You don't want anybody, who builds broken binary rpms from your src.rpm, to mark them as coming from you. The included spec %changelog is an entirely different thing.
License: GPL v2
It's just "GPL".
Requires: gmp >= 4.1.3, gcc-c++ >= 4.0.2
Both are wrong. Instead, you want "BuildRequires: gmp-devel", provided that you want to compile with GNU MP. If so, the dependency on the GNU MP library soname is automatically inserted by rpmbuild.
Prefix: /usr
This means that you want to mark the packages as relocatable. Whether it really is relocatable remains to be seen after bringing it into shape first. You can safely delete this line unless you insist on making it relocatable.
%setup -n %{name}-%{version}
Just %setup -q is fine, since -n %{name}-%{version} is the default.
%build CXXFLAGS="$RPM_OPT_FLAGS" ./configure --enable-shared \
[snip]
Instead of this long command-line, simply run the %configure macro and add any options to it, which it doesn't set automatically.
%configure --enable-shared
Look at rpm --eval %configure to see what it does. For example, it sets CXXFLAGS for you, too.
%install if [ -d $RPM_BUILD_ROOT ] then rm -rf $RPM_BUILD_ROOT fi mkdir -p $RPM_BUILD_ROOT
Not needed and superfluous. Use just:
%install rm -rf $RPM_BUILD_ROOT
make prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir} \
[snip]
With standard GNU autotools packages, prefer this line
make DESTDIR=$RPM_BUILD_ROOT install
over the rather long command-line in your spec file. When it doesn't work (unlikely with well-maintained autotools code), there is the %makeinstall macro, which can be used instead. Look at rpm --eval %makeinstall to see what it would do. But prefer the DESTDIR install.
%files
The main "ppl" package contains a mixture of files. Split off a "ppl-devel" package, which contains the files needed only for software development (include files, the libppl.so symlink, documentation for developers, ppl-config, and so on). The "ppl" package should only contain the main library files, the licence, and any files relevant to the library run-time.
Don't include static libraries. If possible, disable them at configure time with --disable-static or just delete them in %install. Also don't include libtool archive files *.la.
%files c
Same here. A "ppl-c-devel" package is missing. But doesn't it make sense to put C and C++ library and API into the "ppl" and "ppl-devel" packages?
%files gprolog %defattr(-,root,root) %{_bindir}/ppl_gprolog %{_libdir}/ppl/ppl_gprolog.pl
The directory %{_libdir}/ppl/ is not included. You can add %dir %{_libdir}/ppl in the right package which should own this directory entry.
%files sicstus
Same here and the other sub-packages. They also contain an orphaned %_libdir/ppl directory.
%post /sbin/ldconfig
%postun /sbin/ldconfig
%post c /sbin/ldconfig
%postun c /sbin/ldconfig
Better:
%post -p /sbin/ldconfig %postun -p /sbin/ldconfig %post c -p /sbin/ldconfig %postun c -p /sbin/ldconfig
That executes /sbin/ldconfig directly instead of via /bin/sh, and it creates a dependency on /sbin/ldconfig automatically.
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
bagnara@cs.unipr.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bagnara@cs.unipr.it
------- Additional Comments From bagnara@cs.unipr.it 2007-02-10 09:40 EST ------- Thank you very much for the detailed report. We have now fixed all the problems indicated by `rpmlint -i' and most of the issues you pointed out. We would need further advice for the following items though.
Requires: gmp >= 4.1.3, gcc-c++ >= 4.0.2
Both are wrong. Instead, you want "BuildRequires: gmp-devel", provided that you want to compile with GNU MP. If so, the dependency on the GNU MP library soname is automatically inserted by rpmbuild.
Right. I have added "BuildRequires: gmp-devel". But shouldn't we also have "Requires: gmp-devel"? I mean, the PPL header files include the GMP header files, so to use the library (as well as to build it) the GMP header files must be present. Moreover, building the library also requires gcc, gcc-c++ and probably many other tools: should these all be listed? Also, using the library certainly requires libstdc++ and building requires libstdc++-devel. What is the rationale here?
Prefix: /usr
This means that you want to mark the packages as relocatable. Whether it really is relocatable remains to be seen after bringing it into shape first. You can safely delete this line unless you insist on making it relocatable.
I have temporarily commented it out. As you say, we can see later whether the packages are relocatable.
Don't include static libraries. If possible, disable them at configure time with --disable-static or just delete them in %install.
Is this really necessary? Some applications require static libraries. What if we put the static libraries in the *-devel packages? This is what is done in, e.g., the gmp-devel package.
Also don't include libtool archive files *.la.
OK.
%files c
Same here. A "ppl-c-devel" package is missing. But doesn't it make sense to put C and C++ library and API into the "ppl" and "ppl-devel" packages?
The PPL consists of one core library and several interfaces (C++, C plus 6 Prolog dialects; in forthcoming version 0.10 there are also an OCaml and a Java interface). The interfaces are all independent from one another and most user will only need one or perhaps two of them. So it seemed a good idea to have them separate, also because they have quite stringent and different requirements. What is the policy? Should all the packages be split in a pair made up of "package" and "package-devel"? I ask this because, we may end up producing lots of packages:
ppl base library code (C++ shared library), license ppl-devel ppl-config, documentation ppl-cxx-devel C++ interface header file and static library ppl-c C interface shared library ppl-c-devel C interface header file and static library ppl-java ... ppl-java-devel ppl-ocaml ppl-ocaml-devel ppl-some-prolog ppl-some-prolog-devel [the last two items multiplied by 6]
To these we should probably add
ppl-lpsol a program that also depends on glpk-devel
I don't know if this is the way to go. A few observations:
1) ppl-cxx is not present in the list above because I don't know what it could contain that is not already in the base ppl package. 2) It is possible to reduce the number of packages by merging the C and the C++ interfaces: the only drawback is that those who only use one of the two interfaces would waste some disk space. 3) To reduce the number of packages further, the distinction between base and devel packages could be dropped for the other interfaces: it is quite likely that those who need ppl-some-prolog will need also ppl-some-prolog-devel.
Of course, if the number of packages is not something we should worry about we could go for the cleanest solution and split the library as indicated above.
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 bugs.michael@gmx.net 2007-02-10 10:19 EST -------
I have added "BuildRequires: gmp-devel". But shouldn't we also have "Requires: gmp-devel"? I mean, the PPL header files include the GMP header files, so to use the library (as well as to build it) the GMP header files must be present.
Right. Then a "Requires: gmp-devel" must be added to "ppl-devel" as soon as it exists.
Moreover, building the library also requires gcc, gcc-c++ and probably many other tools: should these all be listed?
No. C/C++ compilers and a set of other development tools belong into the default build environment and are expected to be present: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions
Also, using the library certainly requires libstdc++ and building requires libstdc++-devel. What is the rationale here?
As above, these belong also into the set of packages, which is a minimal environment for software development. E.g. gcc-c++ "Requires: libstdc++ libstdc++-devel" already, and it's similar for the C compiler and the C Standard Library.
[no static libs]
Is this really necessary?
This is what the Packaging Committee works on: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
The PPL consists of one core library and several interfaces (C++, C plus 6 Prolog dialects; in forthcoming version 0.10 there are also an OCaml and a Java interface).
Still, C++ and C are close relatives, and when the main "ppl" package contains the C++ ppl, it doesn't hurt to include the C ppl, too. For the C++/C stuff you then have only two packages: ppl and ppl-devel
For the other languages, sub-packages are better, as they likely create additional dependencies on language-specific packages. And you don't want that the C++ programmer needs to install packages for many other languages.
- To reduce the number of packages further, the distinction between
base and devel packages could be dropped for the other interfaces: it is quite likely that those who need ppl-some-prolog will need also ppl-some-prolog-devel.
This would be in violation of the packaging guidelines. It would be a problem, when run-time components would depend on -devel components which is not allowed.
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 pertusus@free.fr 2007-02-10 10:30 EST ------- (In reply to comment #3)
[no static libs]
Is this really necessary?
This is what the Packaging Committee works on: http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage
I didn't looked at the package itself, but from the description it seems that it would be ok to provide static libraries, it seems the usual case of numerical software where static libraries may be useful and are not harmful. They should be put in a -static subpackage, however.
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@cs.unipr.it 2007-02-10 16:08 EST ------- Thanks. We are restructuting everything along the lines you suggested.
Actually, I have spent the good part of this afternoon trying to solve the rpath problem. I thought it was enough to do something like
%build %configure --enable-shared --disable-rpath make
But it is not: I still see link commands like
/bin/sh ../libtool --tag=CXX --mode=link g++ -W -Wall -g -O2 \ -o libppl.la -rpath /usr/lib64 -version-info 6:0:0 ...
I tried with google and I only got more confused: it is a bug of libtool; it is no longer a bug of libtool; it is because something is wrong with /etc/ld.so.conf; an autoreconf -f -i would solve it (but it did not in my case); and so on and so forth.
Can you please point me in the right direction?
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 bugs.michael@gmx.net 2007-02-10 16:37 EST ------- And the RPATH is also in the binaries?
[...]
%build CXXFLAGS="$RPM_OPT_FLAGS" ./configure --enable-shared \
With ppl-0.9-1.src.rpm the code does not compile with $RPM_OPT_FLAGS. Something in the configure script overrides the flags with -W -Wall -g -O2 ...
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@cs.unipr.it 2007-02-10 17:09 EST -------
And the RPATH is also in the binaries?
Ehm, no. How embarassing: I kept looking at the compilation log (seeing the the -rpath option was passed to libtool) without checking again with rpmlint -i. Thanks!
%build CXXFLAGS="$RPM_OPT_FLAGS" ./configure --enable-shared \
With ppl-0.9-1.src.rpm the code does not compile with $RPM_OPT_FLAGS. Something in the configure script overrides the flags with -W -Wall -g -O2 ...
Sorry, I don't understand. Where did you take "CXXFLAGS="$RPM_OPT_FLAGS" ./configure ..."? Are you saying that in the spec file I should replace
%build %configure --enable-shared --disable-rpath make
with
%build CXXFLAGS="$RPM_OPT_FLAGS" ./configure --enable-shared --disable-rpath make
?
In configure.ac there is the following:
# If we are using GCC we want to compile with warnings enabled. if test x"$GCC" = xyes then CFLAGS="-W -Wall $CFLAGS" fi if test x"$GXX" = xyes then CXXFLAGS="-W -Wall $CXXFLAGS" fi
Plus the following code implementing the --enable-optimization configure option.
arch=no enableval=standard AC_MSG_CHECKING([whether to enable optimizations]) AC_ARG_ENABLE(optimization, AC_HELP_STRING([--enable-optimization], [enable compiler optimizations])) case "${enableval}" in sspeed) AC_MSG_RESULT(sspeed) OPT_FLAGS="$OPT_FLAGS -O3 -fomit-frame-pointer" arch=yes ;; speed) AC_MSG_RESULT(speed) OPT_FLAGS="$OPT_FLAGS -O3" arch=yes ;; size) AC_MSG_RESULT(size) OPT_FLAGS="$OPT_FLAGS -Os" arch=yes ;; standard | yes) AC_MSG_RESULT(standard) OPT_FLAGS="$OPT_FLAGS -O2" ;; mild) AC_MSG_RESULT(mild) OPT_FLAGS="$OPT_FLAGS -O1" ;; zero) AC_MSG_RESULT(zero) OPT_FLAGS="$OPT_FLAGS -O0" ;; no) AC_MSG_RESULT(no) ;; *) AC_MSG_ERROR([bad value ${enableval} for --enable-optimization, needs sspeed, speed, size, standard, mild, zero, yes or no]) ;; esac
From what you write I gather this is not good. What can we do to improve the
situation?
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 bugs.michael@gmx.net 2007-02-10 17:33 EST ------- That refers to your original rpm:
The way CXXFLAGS are passed in from the outside, it doesn't succeed:
$ grep CXX ppl.spec CXXFLAGS="$RPM_OPT_FLAGS" ./configure --enable-shared \
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../src -W -Wall -g -O2 -MT Bounding_Box .lo -MD -MP -MF .deps/Bounding_Box.Tpo -c Bounding_Box.cc -fPIC -DPIC -o .libs/ Bounding_Box.o
$ rpm --eval %optflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables
And concluding from that, the %configure macro (which sets CXXFLAGS, CFLAGS and FFLAGS) will not succeed either, because something overrides CXXFLAGS.
I haven't yet looked into it. ;)
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@cs.unipr.it 2007-02-18 06:34 EST ------- Hi there,
in one week we have made considerable progress. Now, with the source rpm
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-2.sr... which comes from
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-docf...
I obtain the following:
$ rpmlint -i /home/roberto/rpm/SRPMS/ppl-0.9-2.src.rpm $ rpmlint -i /home/roberto/rpm/RPMS/x86_64/ppl*.rpm W: ppl-gprolog-devel no-dependency-on ppl-gprolog W: ppl-swiprolog-devel no-dependency-on ppl-swiprolog W: ppl-yap-devel no-dependency-on ppl-yap
I don't know if the three residual warnings are acceptable. The point is that the C/C++ model appears to be different from the one used in Prolog. Before I changed the names of the packages from `*' to `*-devel' I had lots of warnings concerning text files and static libraries in non-devel packages, but that files need to be there in order for the interfaces to be generally usable. Having both a non-devel and a devel package for these interfaces does not make sense from the user point of view. To summarize:
- To make rpmlint happy it seems one should have both `*' to `*-devel', but then what to put in each of those? They should both installed to end up with something usable. - If we can afford living with an unhappy rpmlint, then should we name the packages `*' or `*-devel'?
Coming back to the C/C++ world, there is the issue of where to put the static libraries. They are now in the ppl-devel package and ppl-pwl-devel packages. Should I move them to
ppl-devel-static and ppl-pwl-devel-static
or to
ppl-static and ppl-pwl-static
?
This would bring us to have 11 packages for PPL 0.9 and at least 13 for PPL 0.10. Many thanks again,
Roberto
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@cs.unipr.it 2007-02-22 06:53 EST ------- Thanks to a freshly installed FC6 system I spotted several dependency problems and I believe I have fixed them all. The revised source RPM is
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-3.sr...
and this comes from
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-docf...
The issue of the *-static packages is still pending. I am also considering the possibility of having *-doc packages, but I prefer to wait for your advice concerning the number of subpackages that is tolerable.
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@cs.unipr.it 2007-02-25 12:50 EST ------- Thinking more about it, having a ppl-docs package seemed reasonable. The revised source RPM is
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-4.sr...
This has been obtained from
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-docf...
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
bugzilla@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |medium Priority|normal |medium
tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: <ppl-0.9> - |Review Request: ppl-0.9 - A |<A modern C++ library |modern C++ library providing |providing numerical |numerical abstractions |abstractions> |
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-06 13:41 EST ------- Created an attachment (id=156374) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156374&action=vie...) mock build log of ppl-0.9-4 on F-devel i386
(I have not read the previous discussion in detail. Just from having watched the newest spec file...)
Some notes:
* Static archive - Please explain why you want to include static archives in -devel package first. Usually this must not be done for several reasons (maintainance, security, etc) and if you want to ship static archives (with reasonable reason), split all static archives into different subpackages.
* macros - Please use macros. For example, /usr/include should be replaced with %{_includedir} and perhaps /usr/lib won't be useful for x86_64 or ppc64 arch.
* Documentation directory - should usually be %{_datadir}/doc/%{name}-%{version} ^^^^^^^^^^^^ - and currently /usr/share/doc/ppl/ is not owned by any package.
* defattr - Currently we recommend %defattr(-,root,root,-)
* Mockbuild - fails on F-devel i386
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@cs.unipr.it 2007-06-06 16:43 EST -------
(I have not read the previous discussion in detail. Just from having watched the newest spec file...)
Many thanks for having resurrected this issue: my last n messages remained unanswered and I had stopped working on that for lack of feedback.
Some notes:
- Static archive
- Please explain why you want to include static archives in -devel package first. Usually this must not be done for several reasons (maintainance, security, etc) and if you want to ship static archives (with reasonable reason), split all static archives into different subpackages.
The reasons why we need (and routinely use) static libraries are explained in the discussion above. In addition, the PPL can be interfaced to several Prolog engines and some of them require to link the library statically. Concerning the package naming, let me reproduce what I wrote in the discussion above:
Coming back to the C/C++ world, there is the issue of where to put the static libraries. They are now in the ppl-devel package and ppl-pwl-devel packages. Should I move them to
ppl-devel-static and ppl-pwl-devel-static
or to
ppl-static and ppl-pwl-static
?
This would bring us to have 11 packages for PPL 0.9 and at least 13 for PPL 0.10.
Actually, if we follow that route, the number of packages for PPL 0.10 could reach 15.
- macros
- Please use macros. For example, /usr/include should be replaced with %{_includedir} and perhaps /usr/lib won't be useful for x86_64 or ppc64 arch.
Right: we use %{_includedir} and %{_libdir} instead.
- Documentation directory
- should usually be %{_datadir}/doc/%{name}-%{version} ^^^^^^^^^^^^
We are now using %{_datadir}/doc/%{name} instead of /usr/share/doc/ppl. Including the version would require too many changes (including changing the web pages of the project) and is better postponed to PPL 0.10.
- and currently /usr/share/doc/ppl/ is not owned by any package.
What can I do to fix that?
- defattr
- Currently we recommend %defattr(-,root,root,-)
Fixed.
- Mockbuild
- fails on F-devel i386
This is a bug in the SWI-Prolog (pl) package: it requires readline-devel. Should we work around that bug and require readline-devel ourselves?
I am copying the revised source RPM to
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-5.sr...
This comes from
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-docf...
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-07 03:22 EST ------- (In reply to comment #13)
Some notes:
- Static archive
- Please explain why you want to include static archives in -devel package first. Usually this must not be done for several reasons (maintainance, security, etc) and if you want to ship static archives (with reasonable reason), split all static archives into different subpackages.
The reasons why we need (and routinely use) static libraries are explained in the discussion above. In addition, the PPL can be interfaced to several Prolog engines and some of them require to link the library statically. Concerning the package naming, let me reproduce what I wrote in the discussion above:
Coming back to the C/C++ world, there is the issue of where to put the static libraries. They are now in the ppl-devel package and ppl-pwl-devel packages. Should I move them to
ppl-devel-static and ppl-pwl-devel-static
I prefer this naming style.
- Documentation directory
- should usually be %{_datadir}/doc/%{name}-%{version} ^^^^^^^^^^^^
Including the version would require too many changes (including changing the web pages of the project) and is better postponed to PPL 0.10.
Then I leave it for now.
- and currently /usr/share/doc/ppl/ is not owned by any package.
What can I do to fix that?
Simpy add %dir %{_datadir}/doc/%{name} Also: -------------------------------------------------- %doc %{_datadir}/doc/%{name}/ppl-user-0.9-html/* -------------------------------------------------- (in -docs subpackage) is wrong. In this style, the directory %{_datadir}/doc/ppl-user-0.9-html itself is not owned by any package.
For this case, simply change to -------------------------------------------------- %doc %{_datadir}/doc/%{name}/ppl-user-0.9-html/ -------------------------------------------------- The file entry -------------------------------------------------- foo/ -------------------------------------------------- (where foo/ is a directory) means the directory foo/ itself and all files/directories/etc under foo/
This is a bug in the SWI-Prolog (pl) package: it requires readline-devel. Should we work around that bug and require readline-devel ourselves?
Please do a work-around. I cannot do a formal review unless mockbuild succeeds. Also, if it is a bug of pl side, please file a bug report against pl.
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 pertusus@free.fr 2007-06-07 04:09 EST ------- (In reply to comment #14)
ppl-devel-static and ppl-pwl-devel-staticI prefer this naming style.
There was a clarification and guidelines state now that it should be ppl-static and ppl-pwl-static I think it should be better to stick to the guidelines: http://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryChanges
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@cs.unipr.it 2007-06-07 06:29 EST -------
All the static archives are now in `*-static' packages.
- and currently /usr/share/doc/ppl/ is not owned by any package.
What can I do to fix that?
Simpy add %dir %{_datadir}/doc/%{name}
Done.
Also:
%doc %{_datadir}/doc/%{name}/ppl-user-0.9-html/*
(in -docs subpackage) is wrong. In this style, the directory %{_datadir}/doc/ppl-user-0.9-html itself is not owned by any package.
For this case, simply change to
%doc %{_datadir}/doc/%{name}/ppl-user-0.9-html/
The file entry
foo/
(where foo/ is a directory) means the directory foo/ itself and all files/directories/etc under foo/
Done.
This is a bug in the SWI-Prolog (pl) package: it requires readline-devel. Should we work around that bug and require readline-devel ourselves?
Please do a work-around. I cannot do a formal review unless mockbuild succeeds.
Done.
Also, if it is a bug of pl side, please file a bug report against pl.
Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243084
The revised files are:
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-6.sr...
This comes from
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-docf...
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-07 07:43 EST ------- Created an attachment (id=156450) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156450&action=vie...) mock build log of ppl-0.9-6 on F-devel i386 (readline-devel added)
Still does not get compiled: * BuildRequires - (As a workaround,) readline-devel is missing for BuildRequires
* Unneeded libtool .la archive - Please remove these (see the bottom of the build log)
* compilatin flags - Fedora specific compilation flags are not honored. -------------------------------------------------------------- make all-recursive make[1]: Entering directory `/builddir/build/BUILD/ppl-0.9' Making all in utils make[2]: Entering directory `/builddir/build/BUILD/ppl-0.9/utils' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/glpk -I/usr/lib/gprolog-1.3.0/include -I/usr/include/Yap -W -Wall -g -O2 -MT timi ngs.o -MD -MP -MF ".deps/timings.Tpo" -c -o timings.o timings.cc; \ -------------------------------------------------------- Please check fedora compilation flags by `rpm --eval %optflags' (and the section "Compiler flags" of http://fedoraproject.org/wiki/Packaging/Guidelines )
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@cs.unipr.it 2007-06-07 10:38 EST -------
Still does not get compiled:
- BuildRequires
- (As a workaround,) readline-devel is missing for BuildRequires
Done.
- Unneeded libtool .la archive
- Please remove these (see the bottom of the build log)
Done.
- compilatin flags
- Fedora specific compilation flags are not honored.
make all-recursive make[1]: Entering directory `/builddir/build/BUILD/ppl-0.9' Making all in utils make[2]: Entering directory `/builddir/build/BUILD/ppl-0.9/utils' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/glpk -I/usr/lib/gprolog-1.3.0/include -I/usr/include/Yap -W -Wall -g -O2 -MT timi ngs.o -MD -MP -MF ".deps/timings.Tpo" -c -o timings.o timings.cc; \
Please check fedora compilation flags by `rpm --eval %optflags' (and the section "Compiler flags" of http://fedoraproject.org/wiki/Packaging/Guidelines )
It should be OK now. The revised files are:
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-6.sr... 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-docf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-conf...
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
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@fedoraproject.org |mtasaka@ioa.s.u-tokyo.ac.jp OtherBugsDependingO|163776 |163778 nThis| | Flag| |fedora-review?
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-07 11:37 EST ------- Assiging.
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-07 13:09 EST ------- Created an attachment (id=156485) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156485&action=vie...) rpmlint check result for ppl 0.9-6
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
* 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 ----------------------------------------------------------------- * 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 * why ppl-utils requires glpk-devel Usually non-devel packages should not require devel related packages.
= 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.
* Timestamps - For make install, please use (for this package) ---------------------------------------------------------- make DESTDIR=$RPM_BUILD_ROOT INSTALL="%{__install} -p" install ---------------------------------------------------------- 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.
* 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.
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)
* 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} - or something else?
========================================================= I have not checked for documentation yet, but please fix above.
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
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #156450|0 |1 is obsolete| |
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-07 13:12 EST ------- Created an attachment (id=156487) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156487&action=vie...) mock build log of ppl-0.9-6 on F-devel i386
mock build log attached
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@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@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-docf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-conf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-make...
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-08 01:59 EST ------- The site above seems down for me...
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@cs.unipr.it 2007-06-08 05:04 EST ------- It seems up now.
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@cs.unipr.it 2007-06-08 11:49 EST -------
- 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. 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 have started addressing this problem for PPL 0.10. As you can see from
http://www.cs.unipr.it/pipermail/ppl-devel/2007-June/010880.html http://www.cs.unipr.it/pipermail/ppl-devel/2007-June/010879.html
this requires changing many files that PPL 0.9 (our stable release) is better left alone (also because no user has complained up to now).
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-08 12:28 EST ------- (In reply to comment #22)
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.
This means: ----------------------------------------------------------- -bash-3.2# ldd -r /usr/lib/libppl.so | sort undefined symbol: __gmpz_cmp (/usr/lib/libppl.so) undefined symbol: __gmpz_mul (/usr/lib/libppl.so) undefined symbol: __gmpn_popcount (/usr/lib/libppl.so) undefined symbol: __gmpq_equal (/usr/lib/libppl.so) <snip> ----------------------------------------------------------- For example, /usr/lib/libppl.so contains undefined non-weak symbols. For this library, perhaps linkage against /usr/lib/libgmp??.so is missing.
- devel packge dependency on non-devel package
- Please explain
- why ppl-swiprolog requires ncurses-devel
Sorry, I do not understand this question.
----------------------------------------------------------- %package swiprolog Summary: The SWI-Prolog interface of the Parma Polyhedra Library Group: Development/Libraries BuildRequires: pl >= 5.6.0, readline-devel Requires: ppl = %{version}-%{release}, ppl-pwl = %{version}-%{release}, pl >= 5.6.0, readline-devel ----------------------------------------------------------- So ppl-swiprolog has readline-devel for "Requires". As said above, normally non-devel package should not have dependency for -devel package without reasonable reason.
* why ppl-utils requires glpk-develBecause 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
No. GLPK *library* is provided by glpk rpm and if you worry about library dependencies, then they are checked by rpmbuild automatically and so the explicit Requires for glpk-devel should be removed.
Usually non-devel packages should not require devel related packages.I see. What should I do then?
If you have reasonable reasons, it can be ignored as exceptions.
- Definitions in header files
- Some definitions in some header files are very dangerous and may easyly cause definition conflict.
I will check the discussion above.
- About libppl_gprolog.so:
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
*******************************************************************************
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]
<snip>
Net result: I am totally confused.
Your newest spec file uses --disable-rpath + adds ppl-0.9-makefiles.patch to add rpath on ppl_gprolog. Do you see this rpath problem on the newest spec file?
Anyway, the sources with which I am working are:
I will appreciate it if you also upload the srpm, thanks!
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@cs.unipr.it 2007-06-08 12:52 EST -------
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.
This means:
-bash-3.2# ldd -r /usr/lib/libppl.so | sort undefined symbol: __gmpz_cmp (/usr/lib/libppl.so) undefined symbol: __gmpz_mul (/usr/lib/libppl.so) undefined symbol: __gmpn_popcount (/usr/lib/libppl.so) undefined symbol: __gmpq_equal (/usr/lib/libppl.so)
<snip> ----------------------------------------------------------- For example, /usr/lib/libppl.so contains undefined non-weak symbols. For this library, perhaps linkage against /usr/lib/libgmp??.so is missing.
Thanks for the tip. I will investigate this immediately.
- devel packge dependency on non-devel package
- Please explain
- why ppl-swiprolog requires ncurses-devel
Sorry, I do not understand this question.
%package swiprolog Summary: The SWI-Prolog interface of the Parma Polyhedra Library Group: Development/Libraries BuildRequires: pl >= 5.6.0, readline-devel Requires: ppl = %{version}-%{release}, ppl-pwl = %{version}-%{release}, pl >= 5.6.0, readline-devel
So ppl-swiprolog has readline-devel for "Requires".
I see. The problem was that above you wrote "ncurses-devel".
As said above, normally non-devel package should not have dependency for -devel package without reasonable reason.
You asked me to add this as a workaround. As a reminder, `pl' should require `readline-devel', but it doesn't. You asked me to file a bug for `pl' (which I did) and to work around that problem (which I did by requiring `readline-devel' myself). Perhaps I misunderstood you.
* why ppl-utils requires glpk-develBecause 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
No. GLPK *library* is provided by glpk rpm and if you worry about library dependencies, then they are checked by rpmbuild automatically and so the explicit Requires for glpk-devel should be removed.
I am probably misunderstanding again. Here I see only the packages
glpk-devel-4.13-1.fc6 glpk-utils-4.13-1.fc6
Where do you get the `glpk' package from?
Usually non-devel packages should not require devel related packages.I see. What should I do then?
If you have reasonable reasons, it can be ignored as exceptions.
My only reason is that I thought the `glpk' package did not exist.
- About libppl_gprolog.so:
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
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]
<snip> > Net result: I am totally confused. Your newest spec file uses --disable-rpath + adds ppl-0.9-makefiles.patch to add rpath on ppl_gprolog. Do you see this rpath problem on the newest spec file?
Yes.
Anyway, the sources with which I am working are:
I will appreciate it if you also upload the srpm, thanks!
Because of the error above, the srpm is not generated.
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-08 13:18 EST ------- (In reply to comment #27)
- devel packge dependency on non-devel package
- Please explain
- why ppl-swiprolog requires ncurses-devel
Sorry, I do not understand this question.
%package swiprolog Summary: The SWI-Prolog interface of the Parma Polyhedra Library Group: Development/Libraries BuildRequires: pl >= 5.6.0, readline-devel Requires: ppl = %{version}-%{release}, ppl-pwl = %{version}-%{release}, pl >= 5.6.0, readline-devel
So ppl-swiprolog has readline-devel for "Requires".
I see. The problem was that above you wrote "ncurses-devel".
Very sorry... well, yes, I meant "readline-devel"...
As said above, normally non-devel package should not have dependency for -devel package without reasonable reason.
You asked me to add this as a workaround. As a reminder, `pl' should require `readline-devel', but it doesn't. You asked me to file a bug for `pl' (which I did) and to work around that problem (which I did by requiring `readline-devel' myself). Perhaps I misunderstood you.
No, you did *not mis*understand me. Okay for this.
* why ppl-utils requires glpk-devel
Please ignore this question, sorry again... I mistook BuildRequires for Requires.
- About libppl_gprolog.so:
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
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]
<snip> > Net result: I am totally confused. Your newest spec file uses --disable-rpath + adds ppl-0.9-makefiles.patch to add rpath on ppl_gprolog. Do you see this rpath problem on the newest spec file?
Yes.
Please attach the full build log. I am i386 user and currently I don't have this problem.
Anyway, the sources with which I am working are:
I will appreciate it if you also upload the srpm, thanks!
Because of the error above, the srpm is not generated.
rpmbuild -bs foo.spec just do so.
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@cs.unipr.it 2007-06-08 14:15 EST -------
(In reply to comment #22)
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.
This means:
-bash-3.2# ldd -r /usr/lib/libppl.so | sort undefined symbol: __gmpz_cmp (/usr/lib/libppl.so) undefined symbol: __gmpz_mul (/usr/lib/libppl.so) undefined symbol: __gmpn_popcount (/usr/lib/libppl.so) undefined symbol: __gmpq_equal (/usr/lib/libppl.so)
<snip> ----------------------------------------------------------- For example, /usr/lib/libppl.so contains undefined non-weak symbols. For this library, perhaps linkage against /usr/lib/libgmp??.so is missing.
This should be solved now.
- About libppl_gprolog.so:
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
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]
<snip> > Net result: I am totally confused. Your newest spec file uses --disable-rpath + adds ppl-0.9-makefiles.patch to add rpath on ppl_gprolog. Do you see this rpath problem on the newest spec file?
Yes.
Please attach the full build log. I am i386 user and currently I don't have this problem.
I will attach it.
Anyway, the sources with which I am working are:
I will appreciate it if you also upload the srpm, thanks!
Because of the error above, the srpm is not generated.
rpmbuild -bs foo.spec just do so.
Right. The files are
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-7.sr... 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-docf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-conf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-make...
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@cs.unipr.it 2007-06-08 14:17 EST ------- Created an attachment (id=156598) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=156598&action=vie...) Result of `rpmbuild -ba --sign ppl.spec'
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-08 14:23 EST ------- Thank you, however, now I want to go to bed (I live in Japan).
I will recheck your newest spec/srpm this afternoon.
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-08 14:29 EST ------- Only one comment:
For rpath issue, what if you don't apply ppl-0.9-makefiles.patch?
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@cs.unipr.it 2007-06-08 14:53 EST -------
For rpath issue, what if you don't apply ppl-0.9-makefiles.patch?
I get the same error.
[Good night.]
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 mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-09 11:13 EST ------- Well, for rpath, try to disable system-wide rpath by removing hardcode_libdir_flag_spec from libtool. Even after that, ppl_gprolog should have rpath for %_libdir/ppl because of ppl-0.9-makefiles.patch.
For concrete, ----------------------------------------------------------- %configure sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool ----------------------------------------------------------- I suppose this will work for this package (the section "Removing rpath" in http://fedoraproject.org/wiki/Packaging/Guidelines). After doing this, ppl-0.9-makefiles.patch should be needed.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: ppl-0.9 - A |Review Request: ppl - A |modern C++ library providing|modern C++ library providing |numerical abstractions |numerical abstractions
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-09 11:33 EST ------- Okay, undefined non-weak symbols disappeared. I will recheck again. Please let me know if rpath issue disappears by comment 34.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-09 13:25 EST ------- Well, for 0.9-7:
* %check - This package contains test/ directory and some check programs seem to be executed. If "make check" makes sense, please add: -------------------------------------------------- %check make check -------------------------------------------------- (Well, this is very very long...)
* Documentation - It seems that README.configure is for people who want to rebuild ppl by themselves (i.e. who want to call configure by themselves) and so IMO this document should be removed for rpm user.
- IMO TODO should be added to documents.
* %description - Please refrect static archive split. For example, -devel package says: --------------------------------------------------- %description devel The header files, documentation and static libraries for developing ^^^^^^^^^^^^^^^^^^^^ ---------------------------------------------------
* rpath issue - As said above, please let me know if rpath issue is resolved by hacking libtool.
All other things are okay.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-09 13:27 EST ------- Well, as this is sponsor needed ticket:
------------------------------------------------------------- NOTE: Before being sponsored:
This package will be accepted with another few work. But before I accept this package, someone (I am a candidate) must sponsor you.
Once you are sponsored, you have the right to review other submitters' review requests and approve the packages formally. For this reason, the person who want to be sponsored (like you) are required to "show that you have an understanding of the process and of the packaging guidelines" as is described on : http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored
Usually there are two ways to show this. A. submit other review requests with enough quality. B. Do a "pre-review" of other person's review request (at the time you are not sponsored, you cannot do a formal review)
When you have submitted a new review request or have pre-reviewed other person's review request, please write the bug number on this bug report so that I can check your comments or review request.
Fedora package collection review requests which are waiting for someone to review can be checked on: http://fedoraproject.org/PackageReviewStatus/NEW.html (NOTE: please don't choose "Merge Review")
Review guidelines are described mainly on: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/ScriptletSnippets ------------------------------------------------------------
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-06-12 14:27 EST -------
For concrete,
%configure sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
I suppose this will work for this package (the section "Removing rpath" in http://fedoraproject.org/wiki/Packaging/Guidelines). After doing this, ppl-0.9-makefiles.patch should be needed.
It works!
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-12 14:37 EST ------- Great to hear!
Then would you upload new spec/srpm?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-06-12 15:40 EST -------
Well, for 0.9-7:
- %check
- This package contains test/ directory and some check programs seem to be executed. If "make check" makes sense, please add:
%check make check
(Well, this is very very long...)
I guess it is way too long (from a few hours to a full day, depending on the machine): it does a very thorough test of all the library functionalities. I would leave it out for the moment. For PPL 0.10 we may considering having a light `make check' and anchor the current regression-testing facilities to another make target.
- Documentation
- It seems that README.configure is for people who want to rebuild ppl by themselves (i.e. who want to call configure by themselves) and so IMO this document should be removed for rpm user.
This file provides useful documentation for the user. It is needed, for instance, to interpret the output of `ppl-config --configure-options'. Some users may realize that they need to rebuild the PPL by themselves: I estimate the RPM package can cover 95% of the uses, not all of them.
- IMO TODO should be added to documents.
Added.
- %description
- Please refrect static archive split. For example, -devel package says:
%description devel The header files, documentation and static libraries for developing ^^^^^^^^^^^^^^^^^^^^
Fixed.
- rpath issue
- As said above, please let me know if rpath issue is resolved by hacking libtool.
The rpath issue is resolved.
All other things are okay.
Great! Thanks a lot. Here are the revised files:
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-8.sr... 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-docf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-conf... http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-make...
[I have read comment #37: I will double-check I have understood it properly and come back to you.]
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-13 12:52 EST ------- Okay,
* For this package, the last remaining is (I just found): --------------------------------------------------------------- /usr/share/doc/ppl/NEWS: ISO-8859 English text /usr/share/doc/ppl/TODO: ISO-8859 English text --------------------------------------------------------------- Please change to UTF-8 (by iconv for example).
* For pre-review/other review submit: - If you want to do a pre-review of other person's review request, even if you reviewed a package but you did not find any problems with the package, it is okay if you pre-reviewed it with care. Actually I want to approve this package as soon as possible.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
bugzilla@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Fedora Extras |Fedora
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Flag| |needinfo?(andreac81@hotmail. | |com)
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-06-21 10:21 EST ------- ping?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-06-22 07:45 EST ------- I am sorry for the delay. I am currently traveling and busy preparing and giving talks. I will be back on July 1st: from that date I will start again working on this issue.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-02 08:50 EST ------- (In reply to comment #41)
Okay,
- For this package, the last remaining is (I just found):
/usr/share/doc/ppl/NEWS: ISO-8859 English text /usr/share/doc/ppl/TODO: ISO-8859 English text
Please change to UTF-8 (by iconv for example).
Done. I have simply changed
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-docf...
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-02 09:43 EST ------- Well, please create a new spec/srpm and upload anyway.
And please do a pre-review of other person's review request or submit a new package review request.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-02 10:48 EST ------- (In reply to comment #45)
Well, please create a new spec/srpm and upload anyway.
New SPEC: http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl.spec
New SRPM: http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-9.sr...
And please do a pre-review of other person's review request or submit a new package review request.
I am trying to select a project for which I have a minimum of qualification, but I am having problems: all such projects seem to have requests that are either stuck (e.g., https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227933, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227570) or by people that is unlikely to need my reviewe (e.g., https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208679). I am confused about how to proceed: any hints? Meanwhile I am reading again the packaging guidelines.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-02 12:11 EST ------- Well, would you choose from newer review requests of others, not choosing older ones? (Currently the newest review requests is bug 246460)
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-02 13:04 EST ------- OK: I will try to write a review for
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244597
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-03 09:51 EST ------- I have written a pre-review of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244597
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED OtherBugsDependingO|163778 |163779 nThis| | Flag|fedora-review?, |fedora-review+ |needinfo?(andreac81@hotmail.| |com) |
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-03 11:37 EST ------- * For pre-review: - Well, it seems you chose one of difficult review requests. For your pre-review: * When you want to use check-list style, please also write the summary which shows what are the issues to be left so that everyone can read your review easily. * For ldconfig. where is rkward.so installed? If this is installed under %{_libdir}/R/library/%{name}, then ldconfig is not needed because this directory is not standard paths.
Well, okay. ------------------------------------------------------------ This package (ppl) is APPROVED by me ------------------------------------------------------------
Please follow the procedure written on http://fedoraproject.org/wiki/PackageMaintainers/Join from "Get a Fedora Account" When you requested someone to sponsor you (in the procedure above), please make a note on this bug that you did so.
If you want to push this package also on F-7, you also have to check: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT after the URL above.
If you have some questions, please let me know.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-03 12:17 EST -------
For your pre-review: * When you want to use check-list style, please also write the summary which shows what are the issues to be left so that everyone can read your review easily.
OK.
* For ldconfig. where is rkward.so installed? If this is installed under %{_libdir}/R/library/%{name}, then ldconfig is not needed because this directory is not standard paths.
You are right: I updated 244597 consequently.
Well, okay.
This package (ppl) is APPROVED by me
Thanks!
Please follow the procedure written on http://fedoraproject.org/wiki/PackageMaintainers/Join from "Get a Fedora Account" When you requested someone to sponsor you (in the procedure above), please make a note on this bug that you did so.
Done: I need a sponsor for membership in the cvsextras group and I need approval for membership in the fedorabugs group.
If you want to push this package also on F-7, you also have to check: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT after the URL above.
Will do.
If you have some questions, please let me know.
Thanks a lot.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
bagnara@cs.unipr.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?
------- Additional Comments From bagnara@cs.unipr.it 2007-07-03 14:43 EST ------- New Package CVS Request ======================= Package Name: ppl Short Description: The Parma Polyhedra Library: a library of numerical abstractions Owners: bagnara@cs.unipr.it Branches: F-7 InitialCC: ppl-devel@cs.unipr.it
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs-
------- Additional Comments From kevin@tummy.com 2007-07-03 21:40 EST ------- The InitialCC: address doesn't seem to have a bugzilla account... can you create one for it and resubmit once thats done?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
bagnara@cs.unipr.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs- |fedora-cvs?
------- Additional Comments From bagnara@cs.unipr.it 2007-07-04 01:27 EST ------- New Package CVS Request ======================= Package Name: ppl Short Description: The Parma Polyhedra Library: a library of numerical abstractions Owners: bagnara@cs.unipr.it Branches: F-7 InitialCC:
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-04 06:23 EST ------- I think I have not understood the role of the InitialCC fiel. Now I am caught by a doubt: should I have mtasaka@ioa.s.u-tokyo.ac.jp there?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-04 07:19 EST ------- (In reply to comment #55)
should I have mtasaka@ioa.s.u-tokyo.ac.jp there?
You don't have to.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
------- Additional Comments From kevin@tummy.com 2007-07-04 14:21 EST ------- InitialCC is a list of addresses that will be added to the CC field in bugzilla for any bugs filed against that package. In order for bugzilla to add it and send email, the email address must be associated with a bugzilla account.
So, for copies of bugs to be emailed to your list, you will have to create a bugzilla.redhat.com account for that list with that email address.
cvs done.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
bagnara@cs.unipr.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs+ |fedora-cvs?
------- Additional Comments From bagnara@cs.unipr.it 2007-07-04 14:54 EST ------- Package Change Request ====================== Package Name: ppl Updated InitialCC: ppl-devel@cs.unipr.it
Thanks for the explanation. This (having copies of bugs emailed to the developer's list) was precisely what I wanted to do.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-04 16:37 EST ------- I have requested a build and it fails for ppc64. The reason is:
No Package Found for gprolog >= 1.2.19
I have checked and, indeed, gprolog.spec containts the line
ExclusiveArch: %{ix86} x86_64 ppc
If at all possible, I would like to avoid to esclude ppc64 altogether, since only the GNU Prolog interface is problematic. Is there a way I could disable the gprolog subpackage for ppc64?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 00:11 EST ------- Well, you can try it using %ifnarch macro.
i.e. For example ---------------------------------------------------- %ifnarch ppc64 # gprolog is not available on ppc64 package gprolog Summary: The GNU Prolog interface of the Parma Polyhedra Library ......... %endif .........
%build CPPFLAGS="-I%{_includedir}/glpk" %ifnarch ppc64 CPPFLAGS="$CPPFLAGS -I%{_libdir}/gprolog-`gprolog --version ****`/include" %endif CPPFLAGS="$CPPFLAGS -I%{_includedir}/Yap" %configure *** CPPFLAGS=$CPPFLAGS ****
......... %ifnarch ppc64 %files gprolog .......... %endif --------------------------------------------------------------
NOTE: - Please write a comment in a spec file briefly why you disable gprolog support on ppc64 (like I wrote) - Don't write --------------------------------------------------------------- # gprolog is not available on ppc64 <- Don't write comment here! Here is in the %description of previous subpackage. %ifnarch ppc64 %package gprolog ........... %endif ----------------------------------------------------------------
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 00:14 EST ------- After rebuild is done, please let me know.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 00:20 EST ------- (In reply to comment #60)
NOTE:
- Please write a comment in a spec file briefly why you disable gprolog support on ppc64 (like I wrote)
- Don't write
# gprolog is not available on ppc64 <- Don't write comment here! Here is in the %description of previous subpackage. %ifnarch ppc64 %package gprolog ........... %endif
Oh.. I also made a mistake... The correct way is: %ifnarch ppc64 %package gprolog # gprolog is not available on ppc64 <- please write comment here ......... %endif
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-05 02:38 EST ------- Now there is a problem with x86_64, which I cannot reproduce even if x86_64 is my main development platform. On the Fedora build machine, make dies with
g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginS.o .libs/ppl_yap.o -lYap ../../../src/.libs/libppl.so -L/usr/lib64 ../../../Watchdog/src/.libs/libpwl.so -lgmpxx -lgmp -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o -m64 -mtune=generic -Wl,-soname -Wl,ppl_yap.so -o .libs/ppl_yap.so /usr/bin/ld: /usr/lib/libYap.a(c_interface.o): relocation R_X86_64_32S against `Yap_REGS' can not be used when making a shared object; recompile with -fPIC /usr/lib/libYap.a: could not read symbols: Bad value collect2: ld returned 1 exit status
Whereas the very same command succeeds on my machine:
g++ -shared -nostdlib /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtbeginS.o .libs/ppl_yap.o -lYap ../../../src/.libs/libppl.so -L/usr/lib64 ../../../Watchdog/src/.libs/libpwl.so -lgmpxx -lgmp -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o -m64 -mtune=generic -Wl,-soname -Wl,ppl_yap.so -o .libs/ppl_yap.so ar cru .libs/ppl_yap.a ppl_yap.o ranlib .libs/ppl_yap.a creating ppl_yap.la (cd .libs && rm -f ppl_yap.la && ln -s ../ppl_yap.la ppl_yap.la) make[4]: Leaving directory `/home/roberto/rpm/BUILD/ppl-0.9/interfaces/Prolog/YAP' ...
It seems /usr/lib/libYap.a on the build machine has not been compiled so as to be generally usable. I am unsure about how to proceed.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-05 03:02 EST ------- Found:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246815
Now, what is the best course of action? Should I wait and hope that bug is fixed soon or work around the problem by, e.g., temporarily disabling the YAP interface?
There is a related problem: I had to work around a `pl' packaging problem due to a missing dependency on `readline-devel'. Now this bug has been fixed by the `pl' maintainer (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243084). The question is: should I keep my workaround or should I remove it and make the dependency from `pl' stricter, requiring at least the first version with the fix?
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 03:53 EST ------- (In reply to comment #64)
Found:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246815Now, what is the best course of action? Should I wait and hope that bug is fixed soon or work around the problem by, e.g., temporarily disabling the YAP interface?
I guess you want to disable YAP support now, and I also want to have this rebuilt once anyway. (If you want to disable YAP support, write a comment in the spec file like: ---------------------------------------------------------- # disable YAP support on x86_64 until bug 246815 is fixed ----------------------------------------------------------
There is a related problem: I had to work around a `pl' packaging problem due to a missing dependency on `readline-devel'. Now this bug has been fixed by the `pl' maintainer The question is: should I keep my workaround or should I remove it and make the dependency from `pl' stricter, requiring at least the first version with the fix?
Yes, pl dependency for readline-devel is fixed now and you can revert the workaround for this.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-05 09:11 EST -------
I guess you want to disable YAP support now, and I also want to have this rebuilt once anyway. (If you want to disable YAP support, write a comment in the spec file like:
# disable YAP support on x86_64 until bug 246815 is fixed
Done. I think bug 246815 will be fixed pretty soon: I will re-enable YAP then.
Yes, pl dependency for readline-devel is fixed now and you can revert the workaround for this.
Done. I have completed a successful build with the above two changes.
I will study Bodhi now.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 09:48 EST ------- Well, Bodhi is needed for Fedora-7 branch, so first try to rebuild this package also on F-7 branch.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-07-05 10:54 EST ------- The build on the F-7 branch completed successfully.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 11:07 EST ------- Okay. Then you should request to push ppl to Fedora 7 repository by using bodhi: https://admin.fedoraproject.org/updates/ After that, you can close this bug as "CLOSED NEXTRELEASE"
It may take one or two days before this package is pushed to Fedora 7 formally.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
------- Additional Comments From kevin@tummy.com 2007-07-05 12:04 EST ------- cvs done.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From updates@fedoraproject.org 2007-07-05 15:13 EST ------- ppl-0.9-12.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
mtasaka@ioa.s.u-tokyo.ac.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE OtherBugsDependingO|177841 | nThis| |
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-07-05 22:31 EST ------- Next don't forget to again request on bodhi to move ppl from testing to stable.
Closing as NEXTRELEASE. If you have some questions, please feel free to ask me, or you can ask them on fedora devel/maintainers mailing lists.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
------- Additional Comments From updates@fedoraproject.org 2007-07-12 19:37 EST ------- ppl-0.9-12.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669
updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |CLOSED Resolution|NEXTRELEASE |ERRATA Fixed In Version| |0.9-12.fc7
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-09-23 09:39 EST ------- I have receive a message from buildsys@fedoraproject.org containing the text below. However, I don't know what to do: nothing changed in the ppl package lately. In particular, the minimal version of GMP required did not change. Can someone please explain to me what the problem is?
ppl has broken dependencies in the development tree: On ppc: ppl-swiprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 On x86_64: ppl-swiprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) On i386: ppl-swiprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc64: ppl-swiprolog - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) On ppc: ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) On x86_64: ppl - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) On i386: ppl - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc64: ppl - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) On ppc: ppl-devel - 0.9-14.fc8.ppc requires libgmpxx.so.3 On x86_64: ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 On i386: ppl-devel - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc64: ppl-devel - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) On ppc: ppl-yap - 0.9-14.fc8.ppc requires libgmpxx.so.3 On x86_64: ppl-yap - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) On i386: ppl-yap - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc64: ppl-yap - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) On ppc: ppl-gprolog - 0.9-14.fc8.ppc requires libgmpxx.so.3 On x86_64: ppl-gprolog - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) On i386: ppl-gprolog - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc: ppl-utils - 0.9-14.fc8.ppc requires libgmpxx.so.3 On x86_64: ppl-utils - 0.9-14.fc8.x86_64 requires libgmpxx.so.3()(64bit) On i386: ppl-utils - 0.9-14.fc8.i386 requires libgmpxx.so.3 On ppc64: ppl-utils - 0.9-14.fc8.ppc64 requires libgmpxx.so.3()(64bit) Please resolve this as soon as possible.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-09-23 10:53 EST ------- Rawhide gmp is upgraded to 4.2.2 and then soversion of libgmpxx.so changed. At least you have to rebuild ppl against newest gmp.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From bagnara@cs.unipr.it 2007-09-23 11:11 EST ------- Thanks Mamoru. It turned out to be a bug in gmp.spec: https://bugzilla.redhat.com/show_bug.cgi?id=302221
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-09-23 11:31 EST ------- (In reply to comment #76)
Thanks Mamoru. It turned out to be a bug in gmp.spec: https://bugzilla.redhat.com/show_bug.cgi?id=302221
No, after bug 302221 is solved, you have to rebuild ppl against newest gmp. As broken deps check says, currently ppl requires libgmpxx.so.3, but current rawhide gmp provides libgmpxx.so.4, not .3.
The bug you quoted is saying that libgmpxx.so is linked against libgmpxx.so.3, which does not exist and the link should be targeted against libgmpxx.so.4. So after the bug you quoted is fixed, you have to rebuild against the gmp.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-09-23 11:39 EST ------- By the way, if you don't want to wait until bug 302221 is solved, you can * create a temporary directory (say named as foo) * and create a symlink in the directory named libgmpxx.so which links to %_libdir/libgmpxx.so.4 * and add the directory (foo) to LDFLAGS by some way.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
------- Additional Comments From mtasaka@ioa.s.u-tokyo.ac.jp 2007-09-24 05:45 EST ------- Now bug 302221 is fixed.
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 - A modern C++ library providing numerical abstractions
https://bugzilla.redhat.com/show_bug.cgi?id=227669
bugzilla@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|devel |rawhide
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla