hi, it's something strange (even if i double reload from different mirror sites). it seems to be good: ------------------------------------------ # rpm -K kdebindings-3.5.4-6.el5.src.rpm kdebindings-3.5.4-6.el5.src.rpm: (sha1) dsa sha1 md5 gpg OK ------------------------------------------ but the src.rpm still contains invalid source: ------------------------------------------ # rpm -Uvh kdebindings-3.5.4-6.el5.src.rpm 1:kdebindings warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root warning: user mockbuild does not exist - using root warning: group mockbuild does not exist - using root ########################################### [100%] error: unpacking of archive failed on file /home/robot/rpm/SOURCES/kdebindings-3.5.4.tar.bz2;49ee1e7a: cpio: read ------------------------------------------
On Apr 21, 2009, at 3:30 PM, Farkas Levente wrote:
error: unpacking of archive failed on file /home/robot/rpm/SOURCES/kdebindings-3.5.4.tar.bz2;49ee1e7a: cpio: read
Hmmm, I dimly recall diagnosing an issue like this but have chlorox'ed the memory.
There's something goofy about the payload ...
One next step to diagnosis is rpm -Uvv --fsmdebug ... but I doubt you want to examine the spewage.
One can also work around the issue by doing
rpm2cpio kdebindings-3.5.4-6.el5.src.rpm | cpio -dim
or using the rpm2cpio.sh to figger what is actually in the payload.
hth
73 de Jeff
Jeff Johnson wrote:
On Apr 21, 2009, at 3:30 PM, Farkas Levente wrote:
error: unpacking of archive failed on file /home/robot/rpm/SOURCES/kdebindings-3.5.4.tar.bz2;49ee1e7a: cpio: read
Hmmm, I dimly recall diagnosing an issue like this but have chlorox'ed the memory.
There's something goofy about the payload ...
One next step to diagnosis is rpm -Uvv --fsmdebug ... but I doubt you want to examine the spewage.
One can also work around the issue by doing
rpm2cpio kdebindings-3.5.4-6.el5.src.rpm | cpio -dimor using the rpm2cpio.sh to figger what is actually in the payload.
probably neither rpm2cpio nor rpm2cpio.sh help since it seems the contents is wrong. does it help for you? for me it seems to be an rpm bug since the src.rpm verification is good, so the problem is not happened during the file upload to the mirror sites. i just check that rhel's src.rpm is good.
On Apr 21, 2009, at 4:16 PM, Farkas Levente wrote:
Jeff Johnson wrote:
On Apr 21, 2009, at 3:30 PM, Farkas Levente wrote:
error: unpacking of archive failed on file /home/robot/rpm/SOURCES/kdebindings-3.5.4.tar.bz2;49ee1e7a: cpio: read
Hmmm, I dimly recall diagnosing an issue like this but have chlorox'ed the memory.
There's something goofy about the payload ...
One next step to diagnosis is rpm -Uvv --fsmdebug ... but I doubt you want to examine the spewage.
One can also work around the issue by doing
rpm2cpio kdebindings-3.5.4-6.el5.src.rpm | cpio -dimor using the rpm2cpio.sh to figger what is actually in the payload.
probably neither rpm2cpio nor rpm2cpio.sh help since it seems the contents is wrong. does it help for you? for me it seems to be an rpm bug since the src.rpm verification is good, so the problem is not happened during the file upload to the mirror sites. i just check that rhel's src.rpm is good.
<snip>
Give me a URI to the package and I'll tell you what's wrong.
Bugs depend on POV until the problem is diagnosed and cause identified.
But feel free to attach blame however you wish. It was Bush's fault ...
73 de Jeff
Jeff Johnson wrote:
On Apr 21, 2009, at 4:16 PM, Farkas Levente wrote:
Jeff Johnson wrote:
On Apr 21, 2009, at 3:30 PM, Farkas Levente wrote:
error: unpacking of archive failed on file /home/robot/rpm/SOURCES/kdebindings-3.5.4.tar.bz2;49ee1e7a: cpio: read
Hmmm, I dimly recall diagnosing an issue like this but have chlorox'ed the memory.
There's something goofy about the payload ...
One next step to diagnosis is rpm -Uvv --fsmdebug ... but I doubt you want to examine the spewage.
One can also work around the issue by doing
rpm2cpio kdebindings-3.5.4-6.el5.src.rpm | cpio -dimor using the rpm2cpio.sh to figger what is actually in the payload.
probably neither rpm2cpio nor rpm2cpio.sh help since it seems the contents is wrong. does it help for you? for me it seems to be an rpm bug since the src.rpm verification is good, so the problem is not happened during the file upload to the mirror sites. i just check that rhel's src.rpm is good.
<snip>
Give me a URI to the package and I'll tell you what's wrong.
Bugs depend on POV until the problem is diagnosed and cause identified.
But feel free to attach blame however you wish. It was Bush's fault ...
ftp://mirrors.kernel.org/centos/5.3/os/SRPMS/kdebindings-3.5.4-6.el5.src.rpm
On 04/21/2009 08:30 PM, Farkas Levente wrote:
hi, it's something strange (even if i double reload from different mirror sites). it seems to be good:
# rpm -K kdebindings-3.5.4-6.el5.src.rpm kdebindings-3.5.4-6.el5.src.rpm: (sha1) dsa sha1 md5 gpg OK
but the src.rpm still contains invalid source:
we are trying to work out why this is the way it is - Jeff's feedback re: the rpm would help, in the mean time we might have found a bug in rsync itself. I've manually pushed in a resigned package that should be visible shortly, that should fix the issue.
Once we have a clearer idea as to what caused this issue to come up, I'll post again with details and also how we might make sure this sort of a thing is better tracked for.
On Apr 21, 2009, at 5:41 PM, Karanbir Singh wrote:
On 04/21/2009 08:30 PM, Farkas Levente wrote:
hi, it's something strange (even if i double reload from different mirror sites). it seems to be good:
# rpm -K kdebindings-3.5.4-6.el5.src.rpm kdebindings-3.5.4-6.el5.src.rpm: (sha1) dsa sha1 md5 gpg OK
but the src.rpm still contains invalid source:
we are trying to work out why this is the way it is - Jeff's feedback re: the rpm would help, in the mean time we might have found a bug in rsync itself. I've manually pushed in a resigned package that should be visible shortly, that should fix the issue.
Once we have a clearer idea as to what caused this issue to come up, I'll post again with details and also how we might make sure this sort of a thing is better tracked for.
Hmmm, this seems to be the issue:
rpm2cpio /tmp/kdebindings-3.5.4-6.el5.src.rpm | cpio -itv -rw-r--r-- 1 root root 615 Sep 9 2004 kde-libtool.patch -rw-r--r-- 1 root root 603 Nov 18 2004 kdebindings-3.1- python2.4.patch -rw-r--r-- 1 root root 742 Sep 9 2004 kdebindings-3.1- ssl-krb5.patch -rw-r--r-- 1 root root 217 Sep 9 2004 kdebindings-3.3.0-python.patch -rw-r--r-- 1 root root 876 Mar 1 2005 kdebindings-3.3.92-xdg.patch -rw-r--r-- 1 root root 5416588 Aug 10 2006 kdebindings-3.5.4.tar.bz2 cpio: premature end of file
My 1st guess is that kdebindings-3.5.4.tar.bz2 got clobbered (perhaps by a 2nd SRPM install?) while being built.
Since all the digests/signatures verify w rpm -Kvv:
/tmp/kdebindings-3.5.4-6.el5.src.rpm: Header V3 DSA signature: OK, key ID e8562897 Header SHA1 digest: OK (bd47bcf5840446eac55cbf51ef09cc5c8a37a79b) MD5 digest: OK (775978cfa249016a57512534cb005af6)
that pretty much means that the SRPM got packaged okay, and no damage from rdist or other transport occurred. Digests do not lie.
But there is a window between when RPMTAG_FILESIZES is populated in the metadata, and when the file is actually written to the payload that leads me to guess "clobbered while building".
I can likely add a check to close the window if this problem isn't a unique one-time occurrence.
Do you have any more of these flaws?
My 2nd guess is that the SRPM got truncated between building and signing. I fergit (can/will look if my 2nd guess is more plausible than my 1st) whether digests are recalculated during signing. Hmmm, the digests likely are recalculated during signing, that would explain.
Its easy enough to create a reproducer:
1) build some package 2) use dd to truncate some of the payload. 3) sign the package 3) verify the signature.
Procedurally, run rpm -Kvv on the original content before signing if the 2nd guess reproduces the flaw. Reject (and don't sign) any packages that fail initially.
(aside) BTW, the previous "chlorox'ed" problem I alluded too exercises a different window. If you redefine the desired compression using %define in a spec file, then its possible to generate a *.rpm that claims to be compressed but actually is not.
The window is between when rpm decides what payload compression to use, and when the %define override is encountered in the spec file.
Don't do that! is my current "fix", but I can add mandatory/enforcing policy if needed. E.g. (with @rpm5.org) its possible to make macros read-only before parsing the spec file so that they cannot be changed by %define's encountered within a spec file.
hth
73 de Jeff
On Apr 21, 2009, at 6:10 PM, Jeff Johnson wrote:
Its easy enough to create a reproducer:
- build some package
- use dd to truncate some of the payload.
- sign the package
- verify the signature.
If this reproduces the issue, I can pretty easily send you a patch that compares before and after header+payload MD5 digest and warns/errors if the two values do not match while signing.
73 de Jeff
Jeff Johnson wrote:
On Apr 21, 2009, at 6:10 PM, Jeff Johnson wrote:
Its easy enough to create a reproducer:
- build some package
- use dd to truncate some of the payload.
- sign the package
- verify the signature.
If this reproduces the issue, I can pretty easily send you a patch that compares before and after header+payload MD5 digest and warns/errors if the two values do not match while signing.
then you'd have to send to the upstream rpm, but i'd be more happy to fix #495689 and be able to use 5.3's rpm with mock-0.9 instead of 5.2's rpm:-)
On Apr 21, 2009, at 6:44 PM, Farkas Levente wrote:
then you'd have to send to the upstream rpm, but i'd be more happy to fix #495689 and be able to use 5.3's rpm with mock-0.9 instead of 5.2's rpm:-)
Well I (and @rpm5.org) are "upstream rpm", just not yours. Too bad for you.
I will generate a patch for any version of rpm when given 1) what version of rpm is in use 2) a reliable report that the procedure I described reproduces the error.
73 de Jeff
On Apr 21, 2009, at 9:10 PM, Jeff Johnson wrote:
On Apr 21, 2009, at 6:44 PM, Farkas Levente wrote:
then you'd have to send to the upstream rpm, but i'd be more happy to fix #495689 and be able to use 5.3's rpm with mock-0.9 instead of 5.2's rpm:-)
FYI: re #495689
- rpm/yum (on the buildhost) not respecting pam's
Requires(post): coreutils
The only circumstance under which a dependency is ignored by rpm (yum does things differently) is when a dependency loop is involved. With pam <-> initscripts, I'm not surprised that there are dependency loops.
- pam's scriptlets unsafe and not ending with ||:
- rpm/yum (on the buildhost) exiting with error-code on a scriptlet
Ignoring error codes is hardly a proper "fix".
The 1st step to resolving the issue is identifying the dependency loops and the package ordering that was attempted by mock.
If mock and yum cannot provide the necessary info re whether loops were present (or not) and what order the packages were installed, well, rpm can if you patch the error message in lib/depends.c rpmtsOrder() to change the diagnostic message from RPMLOG_DEBUG to RPMLOG_WARNING.
Yes you will have to rebuild rpm to do that. hth 73 de Jeff
Hi Jeff, thanks for looking into this.
On 04/21/2009 11:14 PM, Jeff Johnson wrote:
- build some package
- use dd to truncate some of the payload.
- sign the package
- verify the signature.
If this reproduces the issue, I can pretty easily send you a patch that compares before and after header+payload MD5 digest and warns/errors if the two values do not match while signing.
This is indeed a part of the situation. The signature was added to a file that wasent complete at the time.
however, the problem does not end there. The file on the master server was then refreshed with the complete srpm on the next rsync ( about 12 minutes later ) and resigned - but that package never made it down to the mirror's, they continued to run with the partial srpm even though they run a complete rsync every 15 minutes from the master.
Its getting a bit late now, but I will try and setup some tests for this over the next few days and see exactly what caused rsync to ignore this file inspite of timestamp and filesize being very different.
On Apr 21, 2009, at 6:46 PM, Karanbir Singh wrote:
Its getting a bit late now, but I will try and setup some tests for this over the next few days and see exactly what caused rsync to ignore this file inspite of timestamp and filesize being very different.
Thank you for reproducing.
I'm not sure why rsync shouldn't copy changed content, a *.rpm is no different than any other file content afaik.
73 de Jeff
-
Farkas Levente -
Jeff Johnson -
Karanbir Singh