Bug 473213

I have confirmed that this does not occur on x86_64 (f10).  Since it looks likely that this bug is triggered by data from the download site, I added in a little debug code to base.py at line 101, viz:
        try:
         if (len(self.upgrades) != len(other.upgrades) or
            len(self.conflicts) != len(other.conflicts) or
            fk(self.upgrades) != fk(other.upgrades) or
            fk(self.conflicts) != fk(other.conflicts) or
            fk([x for x in self.provides if x.name[0] != "/"]) !=
            fk([x for x in other.provides if x.name[0] != "/"])):
            return False
        except:
         print
         print "Name:     ", self.name
         print "Version:  ", self.version
         print "Upgrades: ", self.upgrades
         print "Conflicts:", self.conflicts
         print other.provides
         print self.provides
         raise

resulting in the following output:
Loading cache...
Updating cache...            ################                           ( 39%)
Name:      opal
Version:   3.4.2-1.fc10@i386
Upgrades:  [opal < 3.4.2-1.fc10@i386, openh323]
Conflicts: [openh323]
[lpc10, opal = 3.4.2-1.fc10@i386, h261-vic, libopal.so.3.4.2, gsm0610, g726, , opal(x86-32) = 3.4.2-1.fc10, ima_adpcm, theora, vpb, gsmamrcodec, speexcodec, h263-ffmpeg]
[lpc10, opal = 3.4.2-1.fc10@i386, h261-vic, libopal.so.3.4.2, gsm0610, g726, opal(x86-32) = 3.4.2-1.fc10, ima_adpcm, theora, vpb, gsmamrcodec, speexcodec, h263-ffmpeg]
Traceback (most recent call last):
(remainder of traceback as previously shown)

I guess this shows that the extra empty element following 'g726' is the culprit.  Unfortunately, that has reached the outer limits of my knowledge, since I have absolutely no idea what all this represents, much less whether it is right or wrong :-).

Let me know if I can help in any way.

I can confirm that this also happens if you make a local archive of the Everything packages and repo and use that instead.

If you then rebuild a new repo using createrepo, the same thing also happens. Basically, there is something in smart that is not handling the rpm-md data.

(In reply to comment #1)
>          print other.provides

> [lpc10, opal = 3.4.2-1.fc10@i386, h261-vic, libopal.so.3.4.2, gsm0610, g726, ,
> opal(x86-32) = 3.4.2-1.fc10, ima_adpcm, theora, vpb, gsmamrcodec, speexcodec,
> h263-ffmpeg]

> I guess this shows that the extra empty element following 'g726' is the
> culprit.  Unfortunately, that has reached the outer limits of my knowledge,
> since I have absolutely no idea what all this represents, much less whether it
> is right or wrong :-).
> 
> Let me know if I can help in any way.

Great debugging! This seems to be the empty Provides: bug that is submitted here:

https://bugs.launchpad.net/smart/+bug/302345

Actually the report there mentions the same package, so it's rather 100% the same bug, and the better news is that there is a fix there available as well.

New build are underway and will close this bug once they hit the update repo.

Thanks for reporting and analysis!

Changing to the upstream bug summary.

smart-1.1-58.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc9

smart-1.1-58.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc8

smart-1.1-58.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc10

The broken "opal" package was reported as Bug #473084

smart-1.1-58.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

smart-1.1-58.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

smart-1.1-58.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

smart-1.1-58.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

After upgrading to smart-1.1-58.fc10, I find that the version of base.py included in the package does NOT smart-emptyprov.diff from https://bugs.launchpad.net/smart/+bug/302345, hence the problem persists.
[root@bbsuper rpm]# pwd
/usr/lib/python2.5/site-packages/smart/backends/rpm
[root@bbsuper rpm]# ls -l base.py
-rw-r--r-- 1 root root 10446 2008-09-09 04:28 base.py
[root@bbsuper rpm]# rpm -qf base.py
smart-1.1-58.fc10.i386

smart-1.1-58.0.1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/smart-1.1-58.0.1.fc10

(In reply to comment #13)
> After upgrading to smart-1.1-58.fc10, I find that the version of base.py
> included in the package does NOT smart-emptyprov.diff from
> https://bugs.launchpad.net/smart/+bug/302345, hence the problem persists.

For some reason the patch with the bugfixes was empty for F10. I resubmitted a build and update for F10.

*** Bug 475779 has been marked as a duplicate of this bug. ***

smart-1.1-58.0.1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Confirmed, problem is fixed with this latest update.  Thanks!