Bug 1962

I had noticed that if fails to load part the existing hdlist and will re-add everything after the failing header, but did not have time to investigate yet :(

rpm -q genhdlist2 rpmtools?
Have you tried with 6.1-1.mga2?

Keywords: (none) => NEEDINFO

Indeed URPM::parse_hdlist__XS() has rpm::headerRead() failing to read headers after a while.
The problem is either in generating hdlists or in reading them back.
As the position it stops reading hdlist is random, it would be the later.
It also happens with rpm-4.9.

one needs to look at what makes headerRead() pukes

Keywords: NEEDINFO => (none)
CC: (none) => dmorganec
Assignee: bugsquad => thierry.vignaud

@dexter: I think this is a regression of rpm due to the lost of ufd in rpmio.
It now expect only regular files, all the code managing regular files is now dead...
However, URPM::parse_hdlist__XS() uses a pipe as a fd...

Summary: Incorrect display in genhdlist2 => genhdlist2 doesn't reuse most of the existing hdlist
Source RPM: rpmtools => perl-URPM

(In reply to comment #2)
After some absence, I see you working on problem.
Just in case, I answer all the same questions

> rpm -q genhdlist2 rpmtools?
version 6.0-1.mga1

> Have you tried with 6.1-1.mga2?
I just test it. The problem remains

Regards

I tried to debug it, it seems headerRead expects timedRead(fd, (char *)&ei[2], len) to always read the full requested size but it does not (it often only gets 4992 bytes).

Just to test I changed the code to be 

    if ((a=timedRead(fd, (char *)&ei[2], len)) != len) {
        int p = 0;
        while ((a > 0) && (a < len)) {
                len -= a;
                p += a;
                a = timedRead(fd, (char *)&ei[2]+p, len);
        }
        if (a < len) {
                goto exit;
        }
    }

And it can now load all the headers.

Created attachment 1181 [details]
test case from Panu Matilainen

Created attachment 1182 [details]
patch from Panu Matilainen that makes headerRead works properly again for the previous test case

Created attachment 1183 [details]
old patch of mine trying to use librpm, now working fine with previous rpm patch

Created attachment 1184 [details]
cleaning API after previous URPM patch

@Dexter & Pascal: Ping

tracked at https://bugs.launchpad.net/rpm/+bug/913203

CC: (none) => n3npq

rpm-4.9.1.2-15.mga2 & perl-URPM-3.38.5-1.4 just pushed into core/updates_testing
Please test.

The patch you added in perl-URPM-3.38.5-1.4 is broken, it does not pass test anymore.

Also, please do not add it as a patch in the perl-URPM package, but commit directly in the /soft SVN

It is...

And it won't be commited in soft until we agree to go with this rpm patch

Well, perl-URPM does not build right now because of this patch.
Should I remove it?

perl-URPM-3.36 has been uploaded...

Thanks for the fix.
Though, I would like to have in my in core/release, not core/updates_testing.
We should probably remove your patch in the current/ branch, and you could work from another branch.

Upload in progress.

As for removing the patch, nope. 
The patched method doesn't work anymore at least since we switched from rpm-4.6.x to rpm-4.8.x anyway...

Hey,

I just made an update rpm packages (testing) rpm, lib64rpm and perl-URPMI.

I made several tests to build my local mirror, after having made partial updates.
At home, the result is conclusive. Thank you all.

Packages can they be carried in core/release?
These corrections can they be made to  Mageia 1?

rpm & perl-URPM are just being pushed into core/release for mga2

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED