I see the same problem on Fedora 14, is it possible for the patch provided to be included in F14. Thanks,

+++ This bug was initially created as a clone of Bug #612409 +++

Created attachment 430250 [details]
yum output

Description of problem:
When you try to install a big package, like openoffice.org-debuginfo, yum reports Installed size as a negative number.

Version-Release number of selected component (if applicable):
yum-3.2.27-12.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. yum --enablerepo=*-debuginfo install openoffice.org-debuginfo
2. see Installed size: line in the output

Additional info:
rpm -q openoffice.org-debuginfo --queryformat='%{size}' shows (correctly) 2266262890 .

--- Additional comment from james.antill on 2010-07-08 10:11:02 EDT ---

That's what the .xml says:

  <name>openoffice.org-debuginfo</name>
[...]
<size package="452133452" installed="-2031517036" archive="-2025743476"/>
<location href="openoffice.org-debuginfo-3.2.0-12.25.fc13.x86_64.rpm"/>

...which almost certainly makes this an rpm-python bug (using the wrong type).

--- Additional comment from james.antill on 2010-07-08 10:36:40 EDT ---

Ok ... rpm doesn't appear to have UINT32 types, lib/gentagtbl.sh just does INT32 and there are lookup functions based on that ... *sigh*.

We can fix it up with something like:

def uint(x): return x & 0xFFFFFFFF

--- Additional comment from james.antill on 2010-07-08 12:07:47 EDT ---

Ok ... I've just checked this on F-13 and rpm appears to dtrt (not sure how though :). Normal createrepo run looks like:

  <size package="452133452" installed="2263450260" archive="2269223820"/>

...which is "negative" as int32:

% nums 2263450260
 Input: 2263450260
    %#'x = 0x86E9,8294
    %#'u =   2,263,450,260
    %#'o = 0o20,672,301,224
    %#'b = 0b1000,0110,1110,1001,1000,0010,1001,0100

...not sure when this changed, but my guess is that the repodata was created on RHEL-5.

--- Additional comment from james.antill on 2010-07-08 12:09:18 EDT ---

Panu can you confirm that hdr['size'] not being negative is fixed in recent rpm versions, and what version it was fixed in ... and I guess how hard it would be to backport that fix to RHEL-5 rpm?

--- Additional comment from pmatilai on 2010-07-09 02:24:12 EDT ---

Yup. Rpm >= 4.6.0 considers all integers from headers to be unsigned, but python bindings got signed numbers in some cases prior to 4.8.0. So RHEL 6 itself is not affected with mis-signedness etc.

The problem with backporting this to RHEL 5 is that rpm 4.4.x internally considers all integers from headers to be signed, limiting sizes to the ~2GB. The patch to change python to get unsigned values instead is not big or hard as such, but it is somewhat scary: it involves returning longs instead of ints in cases like this, and I've no idea whether RHN can deal with that. IIRC yum too needed some patching for rpm returning python longs.

--- Additional comment from dtardon on 2010-07-09 03:20:18 EDT ---

Well, just scrap it, then. I thought it was going to be easy fix, like bad conversion somewhere, but if it requires changing half of our infrastructure... I can live with the negative number quite well :)

--- Additional comment from james.antill on 2010-07-28 17:31:30 EDT ---

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

--- Additional comment from james.antill on 2010-08-20 09:23:06 EDT ---

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

--- Additional comment from james.antill on 2010-08-20 09:24:35 EDT ---

I'm going to close this as NaB, as any work around we do would be a major hack ... customers will just have to use RHEL-6 for createrepo, if they have _large_ rpms.

--- Additional comment from grant_williamson.com on 2010-08-20 09:46:35 EDT ---

I can reproduce the same issue on RHEL6 running createrepo.

https://bugzilla.redhat.com/show_bug.cgi?id=625759

So EL6 will not solve the issue.

--- Additional comment from james.antill on 2010-08-20 11:45:57 EDT ---

Grant, you are sure that createrepo was run on RHEL-6?

Can you provide the size data from the XML?

--- Additional comment from grant_williamson.com on 2010-08-20 13:06:30 EDT ---

<package type="rpm">
  <name>ibm-winxp-kvm-3.01</name>
  <arch>noarch</arch>
  <version epoch="0" ver="1" rel="1"/>
  <checksum type="sha256" pkgid="YES">afd31d7d6b9aa80d104196685f92364a1818e508463b0cef037f689edae89ff4</checksum>
  <summary>IBM Client Windows XP KVM Image</summary>
  <description>Open Client for Linux, Microsoft Windows XP KVM Image.</description>
  <packager></packager>
  <url></url>
  <time file="1282279787" build="1282279335"/>
  <size package="3008586525" installed="3044372868" archive="3044374108"/>
<location href="ibm-winxp-kvm-3.01-1-1.noarch.rpm"/>
  <format>
    <rpm:license>IBM Internal Use Only</rpm:license>
    <rpm:vendor/>
    <rpm:group>Applications/Emulators</rpm:group>
    <rpm:buildhost>superrh</rpm:buildhost>
    <rpm:sourcerpm>ibm-winxp-kvm-3.01-1-1.nosrc.rpm</rpm:sourcerpm>
    <rpm:header-range start="280" end="3107"/>
    <rpm:provides>
      <rpm:entry name="ibm-winxp-kvm-3.01" flags="EQ" epoch="0" ver="1" rel="1"/>
    </rpm:provides>
    <rpm:requires>
      <rpm:entry name="sed"/>
      <rpm:entry name="coreutils"/>
      <rpm:entry name="/bin/sh" pre="1"/>
      <rpm:entry name="util-linux-ng"/>
    </rpm:requires>    <file>/etc/libvirt/qemu/ibmwinxp.xml</file>

  </format>
</package>

--- Additional comment from james.antill on 2010-08-20 14:26:34 EDT ---

Ok ... I think Grant's problem is that when we do the XML => .sqlite conversion, we do:

p->size_package = strtol(value, NULL, 10);

...which is fine, but then:

sqlite3_bind_int  (handle, 20, p->size_package);

...which converts the number to signed 32bit.

--- Additional comment from grant_williamson.com on 2010-08-21 08:53:48 EDT ---

James, is there something I can patch to test? I am willing to rebuild any package.

--- Additional comment from james.antill on 2010-08-21 18:28:34 EDT ---

Sure, try this against yum-metadata-parser:

http://yum.baseurl.org/gitweb?p=yum-metadata-parser.git;a=commitdiff;h=2d8499cf272bf9027d015fae0d344998debfae69

...it should fix the above bug, but it's possible there are other ones lurking about (given it can't have ever worked), so any testing you can do would be helpful :).

--- Additional comment from grant_williamson.com on 2010-08-23 00:59:37 EDT ---

Initial test on 6.0 works.
Any idea if this can still make the 6.0 GA Deadline or will this need to wait
till 6.1?

--- Additional comment from james.antill on 2010-08-23 09:20:05 EDT ---

At this point IBM would need to push really hard to get this fixed for 6.0. I've already marked it to be considered for 6.1.

--- Additional comment from james.antill on 2010-09-16 13:52:30 EDT ---

Uh, just realized this was against yum and not yum-metadata-parser.