Bug 473213 - smart fails on rpm with empty Provides:
smart fails on rpm with empty Provides:
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: smart (Show other bugs)
10
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Reopened
: 475779 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-27 00:59 EST by William M. Brack
Modified: 2009-07-31 13:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-30 18:55:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
terminal log showing the problem (3.55 KB, text/plain)
2008-11-27 00:59 EST, William M. Brack
no flags Details

  None (edit)
Description William M. Brack 2008-11-27 00:59:51 EST
Created attachment 324832 [details]
terminal log showing the problem

Description of problem:

When fedora.channel is added and channels are updated, a python error "IndexError: string index out of range" occurs.  See attachment for log of commands leading up to this.

Version-Release number of selected component (if applicable):

smart-1.1 in Fedora f10

How reproducible:

always

Steps to Reproduce:

1. Install smart, start with one channel in /etc/smart/channels(e.g. fedora-updates)
2. smart update
   (all goes well, cache is updated)
3. add (standard version) fedora.channel to /etc/smart/channels
4. smart update
   repo data is read successfully; after cache update begins, trouble
  
Actual results:

smart crashes with a python "string" error

Expected results:

cache update should complete successfully
Comment 1 William M. Brack 2008-11-28 10:40:49 EST
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.
Comment 2 Kelvin J. Hill 2008-12-03 03:24:17 EST
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.
Comment 3 Axel Thimm 2008-12-21 15:11:40 EST
(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!
Comment 4 Axel Thimm 2008-12-21 15:13:48 EST
Changing to the upstream bug summary.
Comment 5 Fedora Update System 2008-12-21 16:34:44 EST
smart-1.1-58.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc9
Comment 6 Fedora Update System 2008-12-21 16:34:52 EST
smart-1.1-58.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc8
Comment 7 Fedora Update System 2008-12-21 16:34:57 EST
smart-1.1-58.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/smart-1.1-58.fc10
Comment 8 Anders F Björklund 2008-12-22 03:39:56 EST
The broken "opal" package was reported as Bug #473084
Comment 9 Fedora Update System 2008-12-24 07:58:35 EST
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.
Comment 10 Fedora Update System 2008-12-24 13:38:14 EST
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.
Comment 11 Fedora Update System 2008-12-24 13:43:10 EST
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.
Comment 12 Fedora Update System 2008-12-24 13:44:12 EST
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.
Comment 13 William M. Brack 2008-12-24 19:23:19 EST
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
Comment 14 Fedora Update System 2008-12-27 08:55:04 EST
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
Comment 15 Axel Thimm 2008-12-27 08:56:44 EST
(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.
Comment 16 Axel Thimm 2008-12-27 08:58:42 EST
*** Bug 475779 has been marked as a duplicate of this bug. ***
Comment 17 Fedora Update System 2008-12-30 18:55:52 EST
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.
Comment 18 William M. Brack 2008-12-31 02:10:36 EST
Confirmed, problem is fixed with this latest update.  Thanks!

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