From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020712
Description of problem:
Also see intro to bug #69211.
Limbo's version of up2date repackages installed rpms in /var/spool/up2date (as
configured in /usr/lib/rpm/macros). On Limbo, with rpm-4.1-0.34 or 4.1-0.50,
these packages _cannot_ be queried. E.g.
# rpm -qpl xinetd-2.3.5-3.i386.rpm
warning: Expected size: 209735 = lead(96)+sigs(344)+pad(0)+data(209295)
warning: Actual size: 209746
error: xinetd-2.3.5-3.i386.rpm: No signature available
error: query of xinetd-2.3.5-3.i386.rpm failed
# rpm -qpl xmlto-0.0.10-3.noarch.rpm
warning: Expected size: 17306 = lead(96)+sigs(344)+pad(0)+data(16866)
warning: Actual size: 17285
error: xmlto-0.0.10-3.noarch.rpm: No signature available
error: query of xmlto-0.0.10-3.noarch.rpm failed
However, on Valhalla (and with the RPM version that is the latest for Valhalla)
the same repackaged rpms can be queried without problems. Makes me believe there
is some problem here either in Limbo's version of RPM or Valhalla's version of
RPM. You choose.
Steps to Reproduce:
1. Install Limbo.
2. Run up2date -u to upgrade.
3. rpm -qpl /var/spool/up2date/glibc-common-2.2.90-14.i386.rpm
where "glibc-common-2.2.90-14.i386.rpm" is the repackaged glibc-common from
Limbo, not the new one from RHN (which is -15).
warning: Expected size: 11486008 = lead(96)+sigs(344)+pad(0)+data(11485568)
warning: Actual size: 5485639
error: glibc-common-2.2.90-14.i386.rpm: No signature available
error: query of glibc-common-2.2.90-14.i386.rpm failed
Expected Results: The contents of the package.
*** Bug 69519 has been marked as a duplicate of this bug. ***
This does not seem to be up2date specific (just doing rpm -e --repackage causes
the same thing to happen), so I've updated the "Summary" line.
Fixed in rpm-4.1-0.57. There were 2 forms of breakage:
1) payload was generated with only base names.
2) the legacy size check prevented the signature
header from being returned.
Note carefully that a package reconstituted with --repackage
will always have a different size, as there's an RPMTAG_REMOVETID
tag appended to the header. There are several other causes
of size change as well, particularly if the files from the
package are deleted and/or missing.