This requires a createrepo that is only available via fasttrack.
How do we wish to handle this? These aren't generally available to a
user unless they have added this to their list of channels (either in
CentOS or RHN).

I wonder if it needs something more explicite than just thunderbird.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

Everything in one mail would be even better. ;) It can be achieved by
concatenating the repoclosure output prior to running the report script on
it. That also reduces the number of private mails the packagers receive.

> mlvirsh-0.3.3.0-6.el5.i386 requires libvirt.so.0
>
> ocaml-libvirt-0.3.3.0-6.el5.i386 requires libvirt.so.0
>
> ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip)
> virt-top-0.3.3.0-6.el5.i386 requires libvirt.so.0
>
This looks like they need more channels added to check against what is
closed or not. I think that this is in the yet another virtualization
channel.

On Wed, Feb 27, 2008 at 04:17:15PM -0700, Stephen John Smoogen
wrote:
> > mlvirsh-0.3.3.0-6.el5.i386 requires libvirt.so.0
> >
> > ocaml-libvirt-0.3.3.0-6.el5.i386 requires libvirt.so.0
> >
> > ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip)
> > virt-top-0.3.3.0-6.el5.i386 requires libvirt.so.0
> >
>
> This looks like they need more channels added to check against what is
> closed or not. I think that this is in the yet another virtualization
> channel.
That's right. Do I need to do anything about these?

Hi Richard. I don't think so. I think we need to figure out a way to
get the build system to know all the channels so we can handle this
properly in the future runs of the script.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

On Fri, Feb 29, 2008 at 8:08 AM, Richard W.M. Jones
<rjones(a)redhat.com&gt; wrote:
> On Wed, Feb 27, 2008 at 04:17:15PM -0700, Stephen John Smoogen wrote:
> > > mlvirsh-0.3.3.0-6.el5.i386 requires libvirt.so.0
> > >
> > > ocaml-libvirt-0.3.3.0-6.el5.i386 requires libvirt.so.0
> > >
> > > ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip)
> > > virt-top-0.3.3.0-6.el5.i386 requires libvirt.so.0
> > >
> >
> > This looks like they need more channels added to check against what is
> > closed or not. I think that this is in the yet another virtualization
> > channel.
>
> That's right. Do I need to do anything about these?
>
Hi Richard. I don't think so. I think we need to figure out a way to
get the build system to know all the channels so we can handle this
properly in the future runs of the script.

The RHEL virtualisation pkgs are in a separate repo. This is
missing in the yum cfg.
As why perl(Archive::Zip) is missing in RHEL5 and not CentOS5
puzzles me (right now -- I've not examined it). Same applies to
libeutil.so.0 as that is evidence of an ABI-incompatible update
somewhere.

I compare this against the results of a different script plus the CentOS
repos. A bad pkgs checker as opposed to repoclosure-modified. It tries to
determine the set of test updates that break deps whereas repoclosure
tries to find the pkgs that suffer from unresolved deps. This one is
different:
source rpm: nikto-1.36-3.el5.src.rpm
package: nikto - 1.36-3.el5.noarch from fedora-epel-testing-5-i386
unresolved deps:
perl(LW)
The EPEL5 test update build job results that break something are (ignore
the repoid, it's just debug output, the run was made against x86_64, too):
Packages that break dependencies:
claws-mail-3.3.1-1.el5.src.rpm (fedora-epel-testing-5-i386)
hspell-1.0-7.el5.src.rpm (fedora-epel-testing-5-i386)
koji-1.2.3-1.el5.src.rpm (fedora-epel-testing-5-i386)
nikto-1.36-3.el5.src.rpm (fedora-epel-testing-5-i386)
perl-ParseLex-2.15-11.el5.src.rpm (fedora-epel-testing-5-i386)
perl-libwhisker2-2.4-3.el5.src.rpm (fedora-epel-testing-5-i386)
php-pear-PHPUnit-3.2.13-1.el5.1.src.rpm (fedora-epel-testing-5-i386)
python-Coherence-0.2.1-3.el5.src.rpm (fedora-epel-testing-5-i386)
sshmenu-3.15-5.el5.src.rpm (fedora-epel-testing-5-i386)
translate-toolkit-0.10.1-1.el5.src.rpm (fedora-epel-testing-5-i386)

It has to do with the various 'channels': perl(Archive::Zip) and
thunderbird do not seem to be in the server channels but are in the
client channels.. I am guessing there are vice versa ones too... I run
into this quite a bit which is why we ended up with a non standard
through it all into one repo to do our installs from.
--
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

On Thu, Feb 28, 2008 at 9:21 AM, Michael Schwendt wrote:
> On Wed, 27 Feb 2008 23:08:09 -0000, Fedora Extras repoclosure wrote:
>
> > ======================================================================
> > Broken packages in fedora-epel-5-i386:
> >
> > amavisd-new-2.4.5-1.el5.noarch requires perl(Archive::Zip)
> > evolution-bogofilter-0.2.0-5.el5.1.i386 requires libeutil.so.0
> > mail-notification-evolution-plugin-4.0-2.el5.i386 requires
libeutil.so.0
> > mlvirsh-0.3.3.0-6.el5.i386 requires libvirt.so.0
> > ocaml-libvirt-0.3.3.0-6.el5.i386 requires libvirt.so.0
> > ooo2txt-0.0.6-3.el5.noarch requires perl(Archive::Zip)
> > virt-top-0.3.3.0-6.el5.i386 requires libvirt.so.0
>
> The RHEL virtualisation pkgs are in a separate repo. This is
> missing in the yum cfg.
>
> As why perl(Archive::Zip) is missing in RHEL5 and not CentOS5
> puzzles me (right now -- I've not examined it). Same applies to
> libeutil.so.0 as that is evidence of an ABI-incompatible update
> somewhere.
>
It has to do with the various 'channels': perl(Archive::Zip) and
thunderbird do not seem to be in the server channels but are in the
client channels.. I am guessing there are vice versa ones too... I run
into this quite a bit which is why we ended up with a non standard
through it all into one repo to do our installs from.

Right. I see it was run against a RHEL5 Server repo and apparently not
against what the buildsys uses.
Btw, the rc-report script can take multiple repoclosure output files as
in input arguments. No need to concatenate them.