Bug 280541 - Review Request: setools - SELinux policy analysis tools
Review Request: setools - SELinux policy analysis tools
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
: 226409 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-06 10:12 EDT by Chris PeBenito
Modified: 2007-11-30 17:12 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-17 15:16:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mtasaka: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
rpmlint complaint for 3.3.1-1 (10.90 KB, text/plain)
2007-09-09 12:59 EDT, Mamoru TASAKA
no flags Details

  None (edit)
Description Chris PeBenito 2007-09-06 10:12:40 EDT
Spec URL: http://oss.tresys.com/projects/setools/chrome/site/dists/for-fedora/setools.spec

SRPM URL: http://oss.tresys.com/projects/setools/chrome/site/dists/for-fedora/setools-3.3.1-1.src.rpm

Description: GUI and command line tools for analyzing SELinux policy and monitoring.

This is a preexisting package that I'd like to take over maintenance of.  The current maintainer (Dan Walsh) is on board with this.
Comment 1 Chris PeBenito 2007-09-06 10:19:11 EDT
This is my first package, and Dan Walsh will be sponsoring me.
Comment 2 Mamoru TASAKA 2007-09-07 06:24:34 EDT
Once Blocking NEEDSPONSOR as Dan is not a sponsor member.
Comment 3 Mamoru TASAKA 2007-09-09 03:24:59 EDT
*** Bug 226409 has been marked as a duplicate of this bug. ***
Comment 4 Mamoru TASAKA 2007-09-09 12:59:28 EDT
Created attachment 191091 [details]
rpmlint complaint for 3.3.1-1

Well, for 3.3.1-1 there are not a few issues to be fixed.
Please check the following URLs for general packaging issue.

http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/Packaging/ReviewGuidelines

A. %description stage

* AutoReqProv
  - Please explain you want to disable AutoReqProv.

    The fact that you check the libraries' dependencies is _not_
    a good reason because even in the case it is still preferable
    that the dependency for libraries are _also_ automatically
    checked by __find_requires. Usually you must only write
    "version specific Requires" for libraries and leave the other 
    libraries' dependency to __find_requires unless you have special 
    reason you don't want to.

   - Also, please consider to remove redundant version
     specific dependency. For example, even FC6 has GTK 2.10.13
     and I don't find any reason you want to write
     "%define gtk_ver 2.8".

* EVR specific dependency
  - Dependency between subpackages must be EVR (epoch:version:*release*) 
    specific.

* Vertual provides
  - Please explain why you want to add vertual provides such as
    "Provides: libqpol = %{libqpol_ver}". This may cause some
    complicated problems for upgrade paths by yum.

* Typo
  - "sqlite >= ${sqlite_ver}" and so on are apparent typo.

B. %prep/%build/%install stage
* Timestamp
  - Please keep timestamp. When using "install" or "cp", use
    "-p" option.
  - Also,
--------------------------------------------------------
make DESTDIR=${RPM_BUILD_ROOT} INSTALL="install -p" install
--------------------------------------------------------
    is more preferable to keep timestamps on more files.

* Macros
  - Please use macros. For example, /usr/share must be %_datadir.
    http://fedoraproject.org/wiki/Packaging/RPMMacros

* Desktop file
  - desktop file must be installed by using "desktop-file-install"
    (BuildRequires: desktop-file-utils is needed).

C. %files
* defattr
  - Now we recommend %defattr(-,root,root,-)
  - Note: %defattr(0755,root,root) is usually wrong (see
    the debuginfo issue below).

* Directory ownership issue
  - Please make it ensure that all the directories created by
    setools related rpms are surely owned by setools related rpms.
    Actually many directories are not owned.
----------------------------------------------------
/usr/include/apol
/usr/include/poldiff
/usr/include/qpol
/usr/lib/python2.5/site-packages/setools/
.... (and many others)
----------------------------------------------------

  ! Note: When you write
----------------------------------------------------
%files
foo/
----------------------------------------------------
    (where foo is a directory), this means the directory foo/
    itself and all files/directories/etc.. under foo/.
    This way of writing %files entry cleans up and shorten
    %files entry and makes directory ownership issue more
    visible than writing verbose file lists.

* static archive
  - Static archive must be seperated from -devel subpackage
    and must be packages in another subpackage.

D. rpmlint
The result for rpmlint is attached (please check how rpmlint
complains before submitting)
You can get the explanation of each rpmlint by using
"rpmlint -I". For example:
--------------------------------------------------------
[tasaka1@localhost ~]$ rpmlint -I mixed-use-of-spaces-and-tabs
mixed-use-of-spaces-and-tabs :
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.
--------------------------------------------------------

Summary:
* mixed-use-of-spaces-and-tabs
  - See above.

* non-executable-script
  - /usr/share/setools-3.3/seaudit-report-service must have
    executable permission

* script-without-shebang
  - Scripts without shebang must not have executable permission

* unstripped-binary-or-object
  - Setting executable permission by %attr like
--------------------------------------------------------------
%attr(755,root,root) %{pkgpyexecdir}/_qpol.so
--------------------------------------------------------------
    is actually not right.
    Unless binaries have executable permission at the time %install
    ends, the binaries are not stripped by find-debuginfo.sh or
    so.
    i.e. you have to change those binaries by the time %install
    ends "manually", not by trying to set executable permission
    by %attr.

* use-old-pam-stack
  - Using "pam_stack.so" is deprecated, and moreover, pam_stack.so
    module is *removed* from pam. So %_sysconfdir/pam.d/seaudit
    must be updated not to use pam_stack.so.

* invalid-desktopfile
  - See above (desktop-file-install)

* devel-file-in-non-devel-package
  - Symlinks %_libdir/*.so should be moved to -devel subpackage

* symlink-should-be-relative
  - Please change symlinks to relative, not absolute.
Comment 5 Mamoru TASAKA 2007-09-09 13:09:35 EDT
And also please consider to use %_dist macro.

http://fedoraproject.org/wiki/Packaging/DistTag
Comment 6 Chris PeBenito 2007-09-13 09:21:39 EDT
I updated the spec and srpm at the above links to fix the issues, except for the
static library comment.  Almost all of the static libraries on my rawhide system
are in the devel package.  The ones that arent are in the main package.
Comment 7 Mamoru TASAKA 2007-09-13 09:35:39 EDT
(In reply to comment #6)
> except for the
> static library comment.  Almost all of the static libraries on my rawhide system
> are in the devel package. 

No, please seperate static archives (or remove all of them if not
needed). Please check "Exclusion of Static Libraries" of
http://fedoraproject.org/wiki/Packaging/Guidelines

(In reply to comment #6)
> I updated the spec and srpm at the above links 
Please don't do this.

Change the release number every time you modify your spec file.
http://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes
Comment 9 Mamoru TASAKA 2007-09-13 11:27:37 EDT
Rebuild failed on dist-f8.

http://koji.fedoraproject.org/koji/taskinfo?taskID=157776
http://koji.fedoraproject.org/koji/getfile?taskID=157780&name=build.log

(I just tried to rebuild your -3 srpm and have not checked
 it yet....)

Note: on rawhide, for the categories
      "Application;System;Utilities;X-Red-Hat-Base;", the valid
      category is only "System".
Comment 10 Mamoru TASAKA 2007-09-14 13:16:36 EDT
For 3.3.1-3:
- Please check your rpms by rpmlint (in rpmlint package) 
  before submitting.

- And also consider to reduce total spec file. For example
  * Use glob (*) in %files entry when possible.
    This surely makes spec files more readable and
    reduces many mistakes.
  * Also, you can use %exclude macro 

Then:
* Redundant Requires
  - Please consider if explicit version requirements
    are really required.
    Currently we only support FC6+, and
---------------------------------------------------
Package     requirement by   FC6 version
            ths package
autoconf    2.59             2.59-12
gtk2        2.8              2.10.13-1.fc6
bwidegt     1.8              1.8.0-1.fc6
python      2.3              2.4.4-1.fc6
libsepol    1.12.27          1.15.3-1.fc6
libselinux  1.30             1.33.4-2.fc6
sqlite      3.2.0            3.3.6-2
swig        1.3.28           1.3.31-0.fc6
tcl         8.4.9            8.4.13-3.fc6
----------------------------------------------------

* Other requires issue
----------------------------------------------------
Requires: setools-libs >= %{version}-%{release}
----------------------------------------------------
  - Why is this >= ?

* unstripped ELF binaries
  - Still lots of ELF binaries are not stripped.
    For example
-----------------------------------------------------
[tasaka1@localhost ~]$ rpmlint setools-gui
setools-gui.i386: W: unstripped-binary-or-object
/usr/lib/setools/apol_tcl/libapol_tcl.so.4.1.1
-----------------------------------------------------
    And these binaries does not have executable permission,
    which must be fixed.
    As I said in my comment 4,
    - The permission of these binaries have to be fixed
      *manually* before %install stage finishes, like:
-----------------------------------------------------
chmod 0755 $RPM_BUILD_ROOT%_libdir/%name/apol_tcl/libapol_tcl.so.*.*.*
-----------------------------------------------------

* Unowned directories
  - Please check directory ownership again.
    For example, %_libdir/setools is not owned by any package.

   NOTE:
   - Please consider to write just directory name like:
------------------------------------------------------
%files
foo/
-------------------------------------------------------
     when possible. This means
     - the directory foo/ itself
     - and all files/directories/etc under foo/
     so this automatically checks directory ownership issue and
     this format surely reduces mistakes for directory ownership
     issue.


* python directories macro
-------------------------------------------------------
%define pkgpyexecdir %{_libdir}/python?.?/site-packages/setools
%define pkgpythondir %{_exec_prefix}/lib*/python?.?/site-packages/setools
-------------------------------------------------------
  - Use %python_sitelib or %python_sitearch.
    Check:
    http://fedoraproject.org/wiki/Packaging/Python

* files in setools metapackage
  - These files cannot be installed when setools package is explicitly
    excluded and in this case COPYING file and so on is not installed.

    All files in setools metapackage should be moved to other subpackages
    (mostly in -libs subpackage).

* desktop file check
  - Rebuild fails on desktop-file-install (as said in previous comment).

* libdir in pkgconfig .pc file
  - For example, even on x86_64, %_libdir/pkgconfig/libapol.pc says:
---------------------------------------------------------
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
----------------------------------------------------------
     On 64bits, libdir must be /usr/lib64, not /usr/lib.

* Macros
  - Still /usr/share is used on -gui %files entry.
Comment 11 Mamoru TASAKA 2007-09-19 12:09:50 EDT
ping?
Comment 12 Chris PeBenito 2007-09-20 10:44:39 EDT
(In reply to comment #10)
> For 3.3.1-3:
> * Redundant Requires
>   - Please consider if explicit version requirements
>     are really required.

They don't hurt, and if in the future explicit versioning is needed, maintenance
will be simpler to just fix the version in one place, rather than having to dig
around all of the requires.  Unless there is a rule about this, I strongly
prefer to keep these.

> * unstripped ELF binaries
>   - Still lots of ELF binaries are not stripped.

How is this supposed to be handled?  I see no explicit stripping in any spec
file in all of fedora.  And if you explicitly strip them, doesn't it break the
debuginfo rpm?

> * files in setools metapackage
>   - These files cannot be installed when setools package is explicitly
>     excluded and in this case COPYING file and so on is not installed.
> 
>     All files in setools metapackage should be moved to other subpackages
>     (mostly in -libs subpackage).

If I remove all of the files, no setools rpm is built, how can this be handled?
Comment 13 Mamoru TASAKA 2007-09-20 15:31:25 EDT
(In reply to comment #12)
> > * unstripped ELF binaries
> >   - Still lots of ELF binaries are not stripped.
> 
> How is this supposed to be handled? 
  - I wrote the method in my comment 10 (and also in my comment 4).
    You have to change the permission of those ELF binaries to 0755
    before %install section finishes.

> > * files in setools metapackage
> >   - These files cannot be installed when setools package is explicitly
> >     excluded and in this case COPYING file and so on is not installed.
> > 
> >     All files in setools metapackage should be moved to other subpackages
> >     (mostly in -libs subpackage).
> 
> If I remove all of the files, no setools rpm is built,
  - setools rpm is still created
-------------------------------------------------
%files
%defattr(-.root,root,-)
-------------------------------------------------
     creates a rpm with contains no files, which is a very
     common method for such metapackage.

Comment 14 Chris PeBenito 2007-09-24 09:06:51 EDT
(In reply to comment #13)
> (In reply to comment #12)
> > > * unstripped ELF binaries
> > >   - Still lots of ELF binaries are not stripped.
> > 
> > How is this supposed to be handled? 
>   - I wrote the method in my comment 10 (and also in my comment 4).
>     You have to change the permission of those ELF binaries to 0755
>     before %install section finishes.

I manually set all ELF objects executable at the end of the %install, and
objects are still not stripped.
Comment 15 Mamoru TASAKA 2007-09-24 13:55:12 EDT
Then would you upload a new spec/srpm (and write the URLs)?
Comment 19 manuel wolfshant 2007-10-01 19:38:51 EDT
Built fine for me in mock/x86_64/devel. However build ends with one warning
(which might be caused by my local modifications to mock.config):

  + cd /builddir/build/BUILD
  + rm -rf setools-3.3.1
  + exit 0
  error: Macro % has illegal name (%define)

rpmlint has one minor complaint which you should fix before comitting to CVS:
  setools.x86_64: W: incoherent-version-in-changelog 3.3.1-4.fc8 3.3.1-5.fc8
Comment 20 Mamoru TASAKA 2007-10-03 05:13:44 EDT
For 3.3.1-5:

* Dependency
  - For -devel subpackage
-------------------------------------------------
Requires: setools = %{version}-%{release}
-------------------------------------------------
    This means -devel subpackage requires -libs, -libs-tcl,
    -gui, -console subpackages?

* Desktop files
  - For example, /usr/share/applications/apol.desktop
    contains:
-------------------------------------------------
Categories=Application;System;X-Red-Hat-Base;
-------------------------------------------------
    Here the categories "Application" "X-Red-Hat-Base" are
    deprecated and they should be removed.

* Duplicate file entry
  You can check if duplicate file entry exists by checking
  "warning: File listed twice" message in build.log.

  - For -libs-python subpackage:
--------------------------------------------------
%{pkg_py_lib}/
%{pkg_py_arch}/
--------------------------------------------------
   This is the same directory on i386, x86_64 so these file
   entries are duplicate. The correct one is:
--------------------------------------------------
%{pkg_py_lib}/
%ifarch x86_64 ppc64
%{pkg_py_arch}/
%endif
--------------------------------------------------

  - For -gui subpackage:
--------------------------------------------------
%{tcllibdir}/apol_tcl/
%{tcllibdir}/apol_tcl/pkgIndex.tcl
--------------------------------------------------
    "%{tcllibdir}/apol_tcl/" entry contains
    "%{tcllibdir}/apol_tcl/pkgIndex.tcl"

Then:
-------------------------------------------------------------
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
------------------------------------------------------------
Comment 21 Chris PeBenito 2007-10-03 11:09:26 EDT
I looked at #314911, which ended up being tiny, and the only thing I saw was
that it didn't use %dist in the Release.  The package also doesn't match the
upstream package (tuncfg vs. tun).

Then I looked at #313361, which gets the errors:

RPM build errors:
    user jbowes does not exist - using root
    group jbowes does not exist - using root
    user jbowes does not exist - using root
    group jbowes does not exist - using root
    File not found by glob:
/var/tmp/python-zsi-2.0-1.fc8-root-root/usr/lib/python2.5/site-packages/*egg-info

so the files in the srpm need to have their ownership fixed, and the files
sections can be rewritten as:

%files
%defattr(-,root,root,-)
%doc CHANGES README
%{python_sitelib}/*
%exclude %{python_sitelib}/ZSI/twisted
%{_bindir}/*

%files twisted
%{python_sitelib}/ZSI/twisted

Then the permissions on scripts need to be fixed:
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/dispatch.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/schema.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/writer.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/wstools/c14n.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/TCnumbers.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/parse.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/auth.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/resolvers.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/wstools/__init__.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/TCtimes.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/ServiceContainer.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/client.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/TC.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/fault.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/TCapache.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/generate/wsdl2dispatch.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/__init__.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/digest_auth.py 0644
python-zsi.noarch: E: non-executable-script
/usr/lib/python2.5/site-packages/ZSI/TCcompound.py 0644

also the naming is different than the upstream (python-zsi vs. ZSI).
Comment 23 Mamoru TASAKA 2007-10-03 12:24:52 EDT
(In reply to comment #21)
> I looked at #314911, which ended up being tiny, and the only thing I saw was
> that it didn't use %dist in the Release.  The package also doesn't match the
> upstream package (tuncfg vs. tun).
> 
> Then I looked at #313361, which gets the errors:
> 
......

Please post your pre-review comments on those review requests,
not on this review requests so that the submitter of those
requests can check your comments and modify their srpms.

After that, I will check your pre-review commentts.
Comment 24 Chris PeBenito 2007-10-03 13:17:52 EDT
done(In reply to comment #23)
> (In reply to comment #21)
> > I looked at #314911, which ended up being tiny, and the only thing I saw was
> > that it didn't use %dist in the Release.  The package also doesn't match the
> > upstream package (tuncfg vs. tun).
> > 
> > Then I looked at #313361, which gets the errors:
> > 
> ......
> 
> Please post your pre-review comments on those review requests,
> not on this review requests so that the submitter of those
> requests can check your comments and modify their srpms.
> 
> After that, I will check your pre-review commentts.

Comments added to the respective bugs.
Comment 25 Mamoru TASAKA 2007-10-04 02:17:26 EDT
Well,

* This package is okay
* Your pre-review seems good for initial comments.

-----------------------------------------------------------
    This package (setools) is APPROVED by me
-----------------------------------------------------------

Please follow the procedure according to:
http://fedoraproject.org/wiki/PackageMaintainers/Join
from "Get a Fedora Account".
At a point a mail should be sent to sponsor members which notifies
that you need a sponsor (at the stage, please also write on
this bug for confirmation that you requested for sponsorship)
Then I will sponsor you.

If you want to import this package into Fedora 7, you also have
to look at
http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT
(after once you rebuilt this package on Fedora rebuilding system).

If you have questions, please ask me.
Comment 26 Mamoru TASAKA 2007-10-09 11:18:30 EDT
ping?
Comment 27 Chris PeBenito 2007-10-09 12:59:26 EDT
I have to have the fedora contributor license agreement reviewed first
(happening for the last few days).
Comment 28 Chris PeBenito 2007-10-10 09:43:01 EDT
Ok, I've gotten to the point for sponsoring
Comment 29 Mamoru TASAKA 2007-10-10 09:48:11 EDT
Now I should be sponsoring you.
Comment 30 Chris PeBenito 2007-10-12 09:26:03 EDT
So I can go ahead and follow the import instructions on
http://fedoraproject.org/wiki/PackageMaintainers/Join ?  I successfully checked
out the setools module, since it already exists.
Comment 31 Mamoru TASAKA 2007-10-12 09:34:43 EDT
Follow the procedure written on Join wiki.
Next you have to set up client tools and request CVS admin procedure
because now the owner of setools is not you.
Comment 32 Chris PeBenito 2007-10-12 11:08:28 EDT
Package Change Request
======================
Package Name: setools
Updated Fedora Owners: pebenito,dwalsh
Comment 33 Kevin Fenzi 2007-10-12 13:36:30 EDT
Can we get an official ack here from dwalsh? 
Also, did you want to take over both F-7 and devel branches? or just devel?
Comment 34 Daniel Walsh 2007-10-15 09:46:15 EDT
Yes this is acked by me.  He can take over f7 and devel.
Comment 35 Kevin Fenzi 2007-10-15 11:31:10 EDT
Thanks. Sorry for the delay, just wanted to make sure everything was good. 
cvs done.
Comment 36 Chris PeBenito 2007-10-17 15:16:38 EDT
Committed, and build completed successfully.

http://koji.fedoraproject.org/koji/taskinfo?taskID=200716
http://koji.fedoraproject.org/koji/buildinfo?buildID=21498
Comment 37 Chris PeBenito 2007-10-18 08:29:30 EDT
I got this message this morning, which doesn't make sense to me:

setools has broken dependencies in the development tree:
On ppc64:
        setools-libs - 3.3.1-6.fc8.ppc64 requires libstdc++.so.6
Please resolve this as soon as possible.

It does have c++, so this dependency makes sense.  I don't see how the build
could have succeeded if libstdc++ didn't exist.
Comment 38 Mamoru TASAKA 2007-10-18 08:48:28 EDT
This message means 
- that some libraries in setools-libs.ppc64 is linked with 
  libstdc++.so.6 (i.e. 32bit libstdc++.so.6), not 
  libstdc++.so.6()(64bit). 
- i.e. _perhaps_ some 32bit rpms got mixed when rebuilding setools
  on ppc64

It is very strange that this error does not seem to have occurred
on x86_64 build.
This may mean some mistakes in some other rpms, or yum's fault, or
koji's fault, or something else. You may want to ask for rel-eng team
about what is happening.
Comment 39 Bill Nottingham 2007-10-18 10:31:32 EDT
Spec is broken.
Comment 40 Mamoru TASAKA 2007-10-18 10:50:53 EDT
(In reply to comment #39)
> Spec is broken.

Actually... 
Chris, please fix this line (I should have noticed this mistake during
review, argh...)
----------------------------------------------------------------------
    43  Group: System Environment/Libraries
    44  Requires: libselinux >= %{selinux_ver} libsepol >= %{sepol_ver} sqlite
>= %{sqlite_ver} libstdc++.so.6
    45  BuildRequires: flex  bison  pkgconfig
----------------------------------------------------------------------
The line 44

Note You need to log in before you can comment on or make changes to this bug.