rpm5 & ts.hdrFromFdno from .hdr file

Jeffrey Johnson n3npq at me.com
Mon May 20 21:55:46 CEST 2013


On May 20, 2013, at 3:42 PM, Elan Ruusamäe wrote:

> On 05/20/2013 10:24 PM, Jeffrey Johnson wrote:
>> On May 20, 2013, at 3:16 PM, Elan Ruusamäe wrote:
>> 
>>> so yes, the data is identical.
>>> 
>> Good.
>> 
>> So there is likely a difference in the python-rpm binding implementation. I'm
>> not surprised ...
> yes, they moved the implemetation to .py, which just gives out rpm.hdr object there
>> Try to pin down the exact return code in yum/anaconda that is failing.
>> One way to do this is to turn on RPMIO debugging, another way is
> yeah, and how to do that in .py interface?

There are several ways:

Easiest by far is just to set _rpmio_debug (from memory, name is obvious) to -1 and temporarily install.

the FD_t object SHOULD have a Debug method to set per-object rather than globally. Easy enough
to add the method if not present, look at other RPM objects).

One can also use Python to find the symbol and assign to non-zero (-1 instead of +1 sometimes
gives more information)

But every I/O operation done by RPM5 SHOULD be insturmented.


>> with strace (limit to open/close/read/write if the spewage overwhelms)
> 
> $ strace -ff -efile -s2000 python hdr2.py blockdev-2.22.2-4.i686.hdr 2>blockdev-2.22.2-4.i686.hdr.strace
> None
> 
> file is opened on line 343, and then it just exits:
> 343 open("blockdev-2.22.2-4.i686.hdr", O_RDONLY|O_LARGEFILE) = 3
> 344 getcwd("/home/vagrant", 4096)           = 14
> 345 +++ exited with 0 +++set
> 

OK. the getcwd is being done to change a ealtive name into an absolute name.

You are failing on the open, and my guess is that yum/anaconda have decided
to _NOT_ write header magic which RPM5 is expecting.

> also appended blockdev-2.22.2-4.i686.hdr.strace.gz to previous archive at:
> http://carme.pld-linux.org/~glen/rpm5-hdr.tar
> 
>> (from ancient memories)
>> The @rpm5.org code has a slightly different return for EOF than what
>> yum/anaconda are expecting. Just one guess ...
>> 
>> ... another guess ... the @rpm.org python bindings is trying to support
>> reading headers without verifying digest/signature, and is also (though
>> its enturely unused afaik) attemptint to support multiple concatenated
>> headers read from single file.
> 
> i tested also with unsigned rpm's - same result (failing). but otoh, you say pld (rpm5) rpm's are always signed, so maybe that test was not accurate.
> 

You don't have to believe me, try-and-see, WYSIWYG.

	rpnbuild -bb foo.spec
	rpm -qvvp foo*.rpm

You should see the non-repudiable signature being verified.
You can see the public key in metadata by doing

	rpm -qp --yaml foo*.rpm

73 de Jeff
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



More information about the pld-devel-en mailing list