Bug 146477 - Python interface has wrong iterator offset matching
Summary: Python interface has wrong iterator offset matching
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: x86_64 Linux
medium
high
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-28 18:13 UTC by Gustavo Niemeyer
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-07 19:40:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Gustavo Niemeyer 2005-01-28 18:13:00 UTC
The dbMatch() method of TransactionSet objects (as created by 
rpm.ts()) fail to match any packages when using numeric keys, such as  
iterator offsets, on any 64bit machine. 
 
For instance, the following Python snippet will always show '0' (no 
matched packages) as output, no matter what "offset" is used. 
 
  import rpm 
  import sys 
  ts = rpm.ts() 
  mi = ts.dbMatch(0, offset) 
  print mi.count() 
 
As previously discussed with Jeff Johnson, the problem here is that 
the "key" parameter, when numeric, is converted to a long and passed 
to the rpmlib as such, but rpmlib expects an "int" instead (32bit). 
 
This problem is seriously affecting Smart Package Manager usage on 
64bit platforms, as many Fedora Core users have reported. 
 
 
Version-Release number of selected component (if applicable): 
4.3, 4.4, ... 
 
How reproducible: 
Always

Comment 1 Jeff Johnson 2005-01-28 21:16:33 UTC
Fixed on HEAD, rpm-4_4, and rpm-4_3 branches, (rpm-4_2 no fix needed).

Comment 2 Edward Rudd 2005-02-04 17:38:59 UTC
will a release pushed for Fedora Core 3 with this fix?

Comment 3 Jeff Johnson 2005-02-07 19:40:29 UTC
Fixed in rpm-4.4.1-0.18.

Comment 4 Dag Wieers 2005-03-08 03:13:53 UTC
So no fix for FC3 ? Not even when I say pretty please ? :)

The bug makes Smart(pm) useless on FC3/x86_64. And if EL4 ships with
something older than 4.4.1-0.18, it'll fail on EL4/x86_64 too...

Where do I have to donate to get RPM 4.4.1 backported back to EL2 ? :)


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