On 10/03/2017 12:20 PM, Thierry Vignaud wrote:
On 3 October 2017 at 09:23, Panu Matilainen <pmati...@redhat.com> wrote:
On 10/02/2017 11:54 PM, Thierry Vignaud wrote:

On 2 October 2017 at 15:08, Panu Matilainen <pmati...@redhat.com> wrote:

perl-RPM4's testsuite seems to have caught a regression:
Simulating several simulate rpm -bi in a row now fails with:
error: Wrong number of entries for tag Filemodes: 2 found but 1
expected.

As a workaround, we've to reload the spec file between 2 tests:



http://svnweb.mageia.org/packages/cauldron/perl-RPM4/current/SOURCES/reload-spec-file-before-builds.patch?revision=1143572&view=markup

I've attached the output of erl t/04spec.t with & w/o this patch


Wild guess: debuginfo link creation.

Does setting %_build_id_links to "none" or "alldebug" make the issue go
away?



...without the actual quotes, that is.


None of that fixes it



So what is the extra entry that's getting added then?

          - Panu -


That's in the logs:
"error: Wrong number of entries for tag Filemodes: 2 found but 1
expected."
This cames from lib/rpmfi.c 's _hgfi()


Yes I saw the log, there's an unexpected file entry in there. And I'm asking
*what* that unexpected *file* is - it's path you know :)

I'm fairly positive it's an intentionally added debuginfo thing and thus
notabug, but until proven...

         - Panu -

The only file listed in RPMTAG_FILENAMES, is /etc/test-rpm, the only
dummy file in this test pkg
Disabling debug packages doesn't help too.

I think you overshot what I initially said: the test works fine if the
spec file is reloaded.
Or if the test is only done once. Repeating the same test will just got:
<first one to work>
    Wrong number of entries for tag Filemodes: 1 found but 1 expected.
    Wrong number of entries for tag Filemodes: 2 found but 1 expected.
     Wrong number of entries for tag Filemodes: 3 found but 1 expected.
(...)

So you're saying the same file gets added over and over? It's not just RPMTAG_FILEMODES which will be increasing in size in that case.

Aka this is a regression when running several builds from the spec
object so I don't see the link with debuginfo...


Debuginfo can add new entries to the package filelist behind the scenes, and that's the only thing I can think of having such an effect. It's just a wild guess like said in the first email because I dont have a reproducer and there's not that much info here when you don't know what the heck the failing test is *actually* doing. What I'm trying to say is that since you have the reproducer, it'd be easiest for you to bisect down which commit changed that behavior.

        - Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to