Bug 227669

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

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.

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

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

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.

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

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?

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

> 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?

That refers to your original rpm:

> http://www.cs.unipr.it/~cimino/ppl-0.9-1.src.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. ;)

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.src.rpm
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-docfiles.patch

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

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.src.rpm

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-docfiles.patch

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.

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.src.rpm

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-docfiles.patch

Created attachment 156374 [details]
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

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

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-docfiles.patch

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

(In reply to comment #14)

> >       ppl-devel-static and ppl-pwl-devel-static
> 
> I 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

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.src.rpm

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-docfiles.patch

Created attachment 156450 [details]
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 )

> 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.src.rpm
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl.spec
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/ppl-0.9.tar.gz
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-docfiles.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-configure.patch

Assiging.

Created attachment 156485 [details]
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.

Created attachment 156487 [details]
mock build log of ppl-0.9-6 on F-devel i386

mock build log attached

> NOTE: From next time, please bump (increment) the release number
>       of spec file each time you modify spec file.
>       http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes

OK.

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

Fixed.

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

Sorry, I do not understand this question.

>       * why ppl-utils requires glpk-devel

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

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

I see.  What should I do then?

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

Should be OK now.

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

OK.

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

I am not sure I understand this.

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

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

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

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

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

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

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


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

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

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

The site above seems down for me...

It seems up now.

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

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

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

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

> (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.src.rpm
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl.spec
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/ppl-0.9.tar.gz
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-docfiles.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-configure.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-makefiles.patch

Created attachment 156598 [details]
Result of `rpmbuild -ba --sign ppl.spec'

Thank you, however, now I want to go to bed (I live in Japan).

I will recheck your newest spec/srpm this afternoon.

Only one comment:

For rpath issue, what if you don't apply ppl-0.9-makefiles.patch?

> For rpath issue, what if you don't apply ppl-0.9-makefiles.patch?

I get the same error.

[Good night.]

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.

Okay, undefined non-weak symbols disappeared. I will recheck
again. Please let me know if rpath issue disappears by comment 34.

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.

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

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

Great to hear!

Then would you upload new spec/srpm?

> 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.src.rpm
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl.spec
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/ppl-0.9.tar.gz
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-docfiles.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-configure.patch
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.9/RedHat/FC6/ppl-0.9-makefiles.patch

[I have read comment #37: I will double-check I have understood
it properly and come back to you.]

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.

ping?

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.

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

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.

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

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

Well, would you choose from newer review requests of others,
not choosing older ones? (Currently the newest review requests is
bug 246460)

OK: I will try to write a review for

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

I have written a pre-review of

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

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

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

New Package CVS Request
=======================
Package Name: ppl
Short Description: The Parma Polyhedra Library: a library of numerical abstractions
Owners: bagnara.it
Branches: F-7
InitialCC: ppl-devel.it

The InitialCC: address doesn't seem to have a bugzilla account... can you create
one for it and resubmit once thats done?

New Package CVS Request
=======================
Package Name: ppl
Short Description: The Parma Polyhedra Library: a library of numerical abstractions
Owners: bagnara.it
Branches: F-7
InitialCC: 

I think I have not understood the role of the InitialCC fiel.  Now I am caught
by a doubt: should I have mtasaka.u-tokyo.ac.jp there?

(In reply to comment #55)
> should I have mtasaka.u-tokyo.ac.jp there?
You don't have to.

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.

Package Change Request
======================
Package Name: ppl
Updated InitialCC: ppl-devel.it

Thanks for the explanation.  This (having copies of bugs emailed to the
developer's list) was precisely what I wanted to do.

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?

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

After rebuild is done, please let me know.

(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

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.

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?

(In reply to comment #64)
> 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?
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.

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

Well, Bodhi is needed for Fedora-7 branch, so first try to rebuild
this package also on F-7 branch.

The build on the F-7 branch completed successfully.

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.

cvs done.

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.

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.

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.

I have receive a message from buildsys 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.

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.

Thanks Mamoru.  It turned out to be a bug in gmp.spec:
https://bugzilla.redhat.com/show_bug.cgi?id=302221

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

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.

Now bug 302221 is fixed.