rpm5 & ts.hdrFromFdno from .hdr file

[Elan Ruusamäe]

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?
> 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

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.

-- 
glen