Red Hat Bugzilla – Bug 69521
problems with repackaged rpms (rpm reports size mismatch + "No signature available")
Last modified: 2008-05-01 11:38:03 EDT
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. How reproducible: Always 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). Actual Results: 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.