Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Panu Matilainen 

On 10/03/2017 12:20 PM, Thierry Vignaud wrote:

On 3 October 2017 at 09:23, Panu Matilainen  wrote:

On 10/02/2017 11:54 PM, Thierry Vignaud wrote:


On 2 October 2017 at 15:08, Panu Matilainen  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=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:

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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Thierry Vignaud 
On 3 October 2017 at 09:23, Panu Matilainen  wrote:
> On 10/02/2017 11:54 PM, Thierry Vignaud wrote:
>>
>> On 2 October 2017 at 15:08, Panu Matilainen  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=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:

   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.
(...)

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


04spec.t.tv
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Panu Matilainen 

On 10/02/2017 11:54 PM, Thierry Vignaud wrote:

On 2 October 2017 at 15:08, Panu Matilainen  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=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 -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Panu Matilainen 

On 10/03/2017 09:55 AM, Thierry Vignaud wrote:

On 3 October 2017 at 08:00, Thierry Vignaud  wrote:

On 3 October 2017 at 07:34, Panu Matilainen  wrote:

Also this new rpm introduced segfault regressions in both RPM4 & urpmi
testsuites
See attached gdb traces in BUG*.txt
valgrind seems to hint about invalid writes/reads
See you



The urpmi issue is when checking bogus pkgs.
The RPM4 issue is when traversing the transaction (not the rpmdb)
Attached are the valgrind outputs



So we have stuff like

==14087== Invalid write of size 4
==14087==at 0x103AA6DD: headerUnlink (header.c:188)
==14087==by 0x103AA6DD: headerFree (header.c:194)
==14087==by 0xFF69314: XS_RPM4__Header_DESTROY (RPM4.xs:890)
==14087==by 0x3F512E2C40: Perl_pp_entersub (pp_hot.c:4231)
==14087==by 0x3F5125551E: Perl_call_sv (perl.c:2848)
==14087==by 0x3F512E7C09: S_curse (sv.c:6987)
==14087==by 0x3F512E84F7: Perl_sv_clear (sv.c:6591)
==14087==by 0x3F512E898D: Perl_sv_free2 (sv.c:7088)
==14087==by 0x3F513182E6: UnknownInlinedFun (inline.h:200)
==14087==by 0x3F513182E6: Perl_free_tmps (scope.c:212)
==14087==by 0x3F512DAD74: Perl_pp_nextstate (pp_hot.c:52)
==14087==by 0x3F512DAA55: Perl_runops_standard (run.c:41)
==14087==by 0x3F5125D236: S_run_body (perl.c:2524)
==14087==by 0x3F5125D236: perl_run (perl.c:2447)
==14087==by 0x400C79: main (perlmain.c:123)
==14087==  Address 0xffeffef8c is on thread 1's stack
==14087==  396 bytes below stack pointer

...and all the failures are around headerFree(), but none of the traces go
into rpm itself, so I dont really know what does "traversing the
transaction" actually mean.


in both URPM & RPM4 bindings, there's a family of traverse functions
that enable to execute a callback on each package of either:
- rpmdb
- the current transaction,
- pkgs header from an hdlist file
- synthetic metadata from a synthesis file
calling the callback on the currrent header

See:
- Db_traverse*() & Trans_traverse() in perl-URPM/URPM.xs
- Ts_traverse() in RPM4-0.36/src/RPM4.xs

It's loosely documented at
http://search.cpan.org/~tvignaud/URPM-5.12/URPM.pm or
http://search.cpan.org/~tvignaud/RPM4-0.36/lib/RPM4/Transaction.pm#Hdlist::Db-%3Etraverse_headers(sub)
(RPM4's doc is very incomplete -- I'm only maintaining this b/c other
tools depend on that and I cannot break them when upgrading rpm)


But the problem is simply with perl-RPM4 and
urpmi passing uninitialized variables to headerFree().

What changed in rpm is that rpmReadPackageFile() no longer does this as the
first thing:

 if (hdrp)
 *hdrp = NULL;

Ie if you pass an uninitialized pointer as hdrp, it remains uninitialized
unless rpmReadPackageFile() returns with a success code.
Which is how I think it should be, but it does deserve a release note on the
changed API.

So the moral of the story is basically: if you depend on your variables
being initialized, initialize them by yourself. It's a good practise anyway.


I'll check for uninitialized variables later today


Actually the bug happen when running the transaction



Right, that makes sense, there's a second rpmReadPackageFile() inside 
transaction run.


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Thierry Vignaud 
On 3 October 2017 at 08:00, Thierry Vignaud  wrote:
> On 3 October 2017 at 07:34, Panu Matilainen  wrote:
 Also this new rpm introduced segfault regressions in both RPM4 & urpmi
 testsuites
 See attached gdb traces in BUG*.txt
 valgrind seems to hint about invalid writes/reads
 See you
>>>
>>>
>>> The urpmi issue is when checking bogus pkgs.
>>> The RPM4 issue is when traversing the transaction (not the rpmdb)
>>> Attached are the valgrind outputs
>>>
>>
>> So we have stuff like
>>
>> ==14087== Invalid write of size 4
>> ==14087==at 0x103AA6DD: headerUnlink (header.c:188)
>> ==14087==by 0x103AA6DD: headerFree (header.c:194)
>> ==14087==by 0xFF69314: XS_RPM4__Header_DESTROY (RPM4.xs:890)
>> ==14087==by 0x3F512E2C40: Perl_pp_entersub (pp_hot.c:4231)
>> ==14087==by 0x3F5125551E: Perl_call_sv (perl.c:2848)
>> ==14087==by 0x3F512E7C09: S_curse (sv.c:6987)
>> ==14087==by 0x3F512E84F7: Perl_sv_clear (sv.c:6591)
>> ==14087==by 0x3F512E898D: Perl_sv_free2 (sv.c:7088)
>> ==14087==by 0x3F513182E6: UnknownInlinedFun (inline.h:200)
>> ==14087==by 0x3F513182E6: Perl_free_tmps (scope.c:212)
>> ==14087==by 0x3F512DAD74: Perl_pp_nextstate (pp_hot.c:52)
>> ==14087==by 0x3F512DAA55: Perl_runops_standard (run.c:41)
>> ==14087==by 0x3F5125D236: S_run_body (perl.c:2524)
>> ==14087==by 0x3F5125D236: perl_run (perl.c:2447)
>> ==14087==by 0x400C79: main (perlmain.c:123)
>> ==14087==  Address 0xffeffef8c is on thread 1's stack
>> ==14087==  396 bytes below stack pointer
>>
>> ...and all the failures are around headerFree(), but none of the traces go
>> into rpm itself, so I dont really know what does "traversing the
>> transaction" actually mean.
>
> in both URPM & RPM4 bindings, there's a family of traverse functions
> that enable to execute a callback on each package of either:
> - rpmdb
> - the current transaction,
> - pkgs header from an hdlist file
> - synthetic metadata from a synthesis file
> calling the callback on the currrent header
>
> See:
> - Db_traverse*() & Trans_traverse() in perl-URPM/URPM.xs
> - Ts_traverse() in RPM4-0.36/src/RPM4.xs
>
> It's loosely documented at
> http://search.cpan.org/~tvignaud/URPM-5.12/URPM.pm or
> http://search.cpan.org/~tvignaud/RPM4-0.36/lib/RPM4/Transaction.pm#Hdlist::Db-%3Etraverse_headers(sub)
> (RPM4's doc is very incomplete -- I'm only maintaining this b/c other
> tools depend on that and I cannot break them when upgrading rpm)
>
>> But the problem is simply with perl-RPM4 and
>> urpmi passing uninitialized variables to headerFree().
>>
>> What changed in rpm is that rpmReadPackageFile() no longer does this as the
>> first thing:
>>
>> if (hdrp)
>> *hdrp = NULL;
>>
>> Ie if you pass an uninitialized pointer as hdrp, it remains uninitialized
>> unless rpmReadPackageFile() returns with a success code.
>> Which is how I think it should be, but it does deserve a release note on the
>> changed API.
>>
>> So the moral of the story is basically: if you depend on your variables
>> being initialized, initialize them by yourself. It's a good practise anyway.
>
> I'll check for uninitialized variables later today

Actually the bug happen when running the transaction
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-03 Thread Thierry Vignaud 
On 3 October 2017 at 07:34, Panu Matilainen  wrote:
>>> Also this new rpm introduced segfault regressions in both RPM4 & urpmi
>>> testsuites
>>> See attached gdb traces in BUG*.txt
>>> valgrind seems to hint about invalid writes/reads
>>> See you
>>
>>
>> The urpmi issue is when checking bogus pkgs.
>> The RPM4 issue is when traversing the transaction (not the rpmdb)
>> Attached are the valgrind outputs
>>
>
> So we have stuff like
>
> ==14087== Invalid write of size 4
> ==14087==at 0x103AA6DD: headerUnlink (header.c:188)
> ==14087==by 0x103AA6DD: headerFree (header.c:194)
> ==14087==by 0xFF69314: XS_RPM4__Header_DESTROY (RPM4.xs:890)
> ==14087==by 0x3F512E2C40: Perl_pp_entersub (pp_hot.c:4231)
> ==14087==by 0x3F5125551E: Perl_call_sv (perl.c:2848)
> ==14087==by 0x3F512E7C09: S_curse (sv.c:6987)
> ==14087==by 0x3F512E84F7: Perl_sv_clear (sv.c:6591)
> ==14087==by 0x3F512E898D: Perl_sv_free2 (sv.c:7088)
> ==14087==by 0x3F513182E6: UnknownInlinedFun (inline.h:200)
> ==14087==by 0x3F513182E6: Perl_free_tmps (scope.c:212)
> ==14087==by 0x3F512DAD74: Perl_pp_nextstate (pp_hot.c:52)
> ==14087==by 0x3F512DAA55: Perl_runops_standard (run.c:41)
> ==14087==by 0x3F5125D236: S_run_body (perl.c:2524)
> ==14087==by 0x3F5125D236: perl_run (perl.c:2447)
> ==14087==by 0x400C79: main (perlmain.c:123)
> ==14087==  Address 0xffeffef8c is on thread 1's stack
> ==14087==  396 bytes below stack pointer
>
> ...and all the failures are around headerFree(), but none of the traces go
> into rpm itself, so I dont really know what does "traversing the
> transaction" actually mean.

in both URPM & RPM4 bindings, there's a family of traverse functions
that enable to execute a callback on each package of either:
- rpmdb
- the current transaction,
- pkgs header from an hdlist file
- synthetic metadata from a synthesis file
calling the callback on the currrent header

See:
- Db_traverse*() & Trans_traverse() in perl-URPM/URPM.xs
- Ts_traverse() in RPM4-0.36/src/RPM4.xs

It's loosely documented at
http://search.cpan.org/~tvignaud/URPM-5.12/URPM.pm or
http://search.cpan.org/~tvignaud/RPM4-0.36/lib/RPM4/Transaction.pm#Hdlist::Db-%3Etraverse_headers(sub)
(RPM4's doc is very incomplete -- I'm only maintaining this b/c other
tools depend on that and I cannot break them when upgrading rpm)

> But the problem is simply with perl-RPM4 and
> urpmi passing uninitialized variables to headerFree().
>
> What changed in rpm is that rpmReadPackageFile() no longer does this as the
> first thing:
>
> if (hdrp)
> *hdrp = NULL;
>
> Ie if you pass an uninitialized pointer as hdrp, it remains uninitialized
> unless rpmReadPackageFile() returns with a success code.
> Which is how I think it should be, but it does deserve a release note on the
> changed API.
>
> So the moral of the story is basically: if you depend on your variables
> being initialized, initialize them by yourself. It's a good practise anyway.

I'll check for uninitialized variables later today
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/03/2017 12:12 AM, Thierry Vignaud wrote:

On 2 October 2017 at 23:06, Thierry Vignaud  wrote:

Also this new rpm introduced segfault regressions in both RPM4 & urpmi
testsuites
See attached gdb traces in BUG*.txt
valgrind seems to hint about invalid writes/reads
See you


The urpmi issue is when checking bogus pkgs.
The RPM4 issue is when traversing the transaction (not the rpmdb)
Attached are the valgrind outputs



So we have stuff like

==14087== Invalid write of size 4
==14087==at 0x103AA6DD: headerUnlink (header.c:188)
==14087==by 0x103AA6DD: headerFree (header.c:194)
==14087==by 0xFF69314: XS_RPM4__Header_DESTROY (RPM4.xs:890)
==14087==by 0x3F512E2C40: Perl_pp_entersub (pp_hot.c:4231)
==14087==by 0x3F5125551E: Perl_call_sv (perl.c:2848)
==14087==by 0x3F512E7C09: S_curse (sv.c:6987)
==14087==by 0x3F512E84F7: Perl_sv_clear (sv.c:6591)
==14087==by 0x3F512E898D: Perl_sv_free2 (sv.c:7088)
==14087==by 0x3F513182E6: UnknownInlinedFun (inline.h:200)
==14087==by 0x3F513182E6: Perl_free_tmps (scope.c:212)
==14087==by 0x3F512DAD74: Perl_pp_nextstate (pp_hot.c:52)
==14087==by 0x3F512DAA55: Perl_runops_standard (run.c:41)
==14087==by 0x3F5125D236: S_run_body (perl.c:2524)
==14087==by 0x3F5125D236: perl_run (perl.c:2447)
==14087==by 0x400C79: main (perlmain.c:123)
==14087==  Address 0xffeffef8c is on thread 1's stack
==14087==  396 bytes below stack pointer

...and all the failures are around headerFree(), but none of the traces 
go into rpm itself, so I dont really know what does "traversing the 
transaction" actually mean. But the problem is simply with perl-RPM4 and 
urpmi passing uninitialized variables to headerFree().


What changed in rpm is that rpmReadPackageFile() no longer does this as 
the first thing:


if (hdrp)
*hdrp = NULL;

Ie if you pass an uninitialized pointer as hdrp, it remains 
uninitialized unless rpmReadPackageFile() returns with a success code.
Which is how I think it should be, but it does deserve a release note on 
the changed API.


So the moral of the story is basically: if you depend on your variables 
being initialized, initialize them by yourself. It's a good practise anyway.


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/03/2017 12:12 AM, Thierry Vignaud wrote:

On 2 October 2017 at 23:06, Thierry Vignaud  wrote:

Also this new rpm introduced segfault regressions in both RPM4 & urpmi
testsuites
See attached gdb traces in BUG*.txt
valgrind seems to hint about invalid writes/reads
See you


The urpmi issue is when checking bogus pkgs.
The RPM4 issue is when traversing the transaction (not the rpmdb)
Attached are the valgrind outputs



Okay, I'll look into it. But PLEASE, when reporting issues, use a new 
subject instead of just hitting reply to an announcement. Now I got half 
a dozen emails covering several different issues but all appearing to be 
about rc2, none of these issues are even specific to that rc.


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 2 October 2017 at 23:06, Thierry Vignaud  wrote:
> Also this new rpm introduced segfault regressions in both RPM4 & urpmi
> testsuites
> See attached gdb traces in BUG*.txt
> valgrind seems to hint about invalid writes/reads
> See you

The urpmi issue is when checking bogus pkgs.
The RPM4 issue is when traversing the transaction (not the rpmdb)
Attached are the valgrind outputs


valgrind-urpmi.xz
Description: application/xz


valgrind-RPM4.xz
Description: application/xz
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 28 September 2017 at 16:06, Panu Matilainen  wrote:
> There aren't that many changes since rc1, but enough to warrant a second
> release candidate instead of going for final. The important ones being:
>
> - Fix a bug of file triggers failing on some packages (MgBug:18797, in
> 4.13.x already)
> - Fix a regression on 32bit architectures on generation of packages over 2GB
> in size (RhBug:1492587)
> - Fix rpm following arbitrary directory symlinks on installation
> (CVE-2017-7500)
> - Fix rpm following symlinks on file creation (CVE-2017-7501)
> - Adjust verification to match the new directory symlink rule
> - Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context
>
> As usual, the details + download info at:
>
> http://rpm.org/wiki/Releases/4.14.0

Also this new rpm introduced segfault regressions in both RPM4 & urpmi
testsuites
See attached gdb traces in BUG*.txt
valgrind seems to hint about invalid writes/reads
See you
$ LC_ALL=C gdb -q --args perl t/05transaction.t
Reading symbols from perl...Reading symbols from 
/usr/lib/debug/usr/bin/perl5.26.1-5.26.1-1.mga7.x86_64.debug...done.
done.
(gdb) r
Starting program: /usr/bin/perl t/05transaction.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
1..45
error: can't create transaction lock on /dev/null/__db.000 (Not a directory)
ok 1 - Verify non existing database (get error)
ok 2 - initdb works
ok 3 - rebuild database
error: rpmdb: Enhancename: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Supplementname: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Suggestname: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Recommendname: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Transfiletriggername: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Filetriggername: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Sha1header: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Sigmd5: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Installtid: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Dirnames: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Triggername: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Obsoletename: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Conflictname: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Providename: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Requirename: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Group: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Basenames: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
error: rpmdb: Name: No such file or directory
error: db5 error(2) from db->verify: No such file or directory
not ok 4 - Verify empty
#   Failed test 'Verify empty'
#   at t/05transaction.t line 24.
ok 5 - Open a new transaction
warning: Generating 18 missing index(es), please wait...
ok 6 - ts->traverse
ok 7 - Importing a public key
ok 8 - Reading the header works
ok 9 - Adding a package to transaction works
ok 10 - Checking transaction works
ok 11 - Run transaction order
ok 12 - Set transflags
ok 13 - Resetting transaction
ok 14 - Reading the header works
ok 15 - Adding a package to transaction works
ok 16 - Can get name from te
ok 17 - Can get type from te
ok 18 - traverse_transaction works
ok 19 - Checking transaction works
ok 20 - Run transaction order
ok 21 - Set transflags
TRANS_START 6 / 1
TRANS_PROGRESS 0 / 1
TRANS_STOP 6 / 1
INST_OPEN_FILE 0 / 0
 0 / 1
INST_START 0 / 284
INST_PROGRESS 0 / 284
INST_PROGRESS 284 / 284
 284 / 284
INST_CLOSE_FILE 0 / 0
ok 22 - Running transaction justdb

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0xfffe7fff) at malloc.c:3121
3121  if (chunk_is_mmapped (p))   /* release mmapped 
memory. */
(gdb) bt
#0  __GI___libc_free (mem=0xfffe7fff) at malloc.c:3121
#1  0x768b0dd9 in rfree (ptr=ptr@entry=0xfffe7fff) at 
rpmmalloc.c:83
#2  0x76ae576c in headerFree (h=0x7fffd1a8) at header.c:214
#3  0x76f4d315 in XS_RPM4__Header_DESTROY (my_perl=, 
cv=) at RPM4.xs:890
#4

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 2 October 2017 at 15:50, Thierry Vignaud  wrote:
 It's probably this:

 https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80

 If so, the following in the spec should work around it:
 %undefine __global_requires_exclude_from
 %undefine __global_provides_exclude_from
>>>
>>>
>>> That works but that not manageable for 3000+ perl packages
>>> So that would have to be reverted at the distro wide level.
>>
>>
>> I wasn't suggesting you do it on every package, it was just to see whether
>> that's really the cause.
>>
>> Just comment out the defaults in rpm's main macros file to stop it
>> distro-wide.
>
> Already done :-)
>
 I never really agreed to filtering doc dependencies because there's no
 reason docs could not have dependencies, they just tend to be slightly
 different from other docs.
>>
>>
>> Oops, that paragraph got garbled (was in a bit of hurry). It was supposed to
>> say something like "..., they just tend to be slightly different in nature
>> from other dependencies.
>>
>>> I understand the reasoning.
>>
>>
>> Not sure which reasoning you mean :) Like said, I never really liked the
>> idea of filtering them in the first place.
>
> I understand some packagers not want to got extra deps b/c of example
> scripts & the like
> But I think it's wrong to do it at distro wide level, at least for some 
> distros
>
>>> In that case I guess we could package them in another place (like
>>> pythoneggs)
>>> But that means more changes to 3000+ packages.
>>> Up to now, mga perl packagers could just rely on using "%doc META.yml"
>>> and voila autodeps were automagically working
>>>
 Just wondering if those files should really be %doc - I've no idea what
 they
 do, but metadata doesn't really sound like documentation. Does the
 package
 work if installed with --nodocs?
>>>
>>>
>>> Yes, of course they would work.
>>> Those files are not packaged in eg FC
>>> They're just metadata. But those metadata actually describe the deps.
>>
>>
>> Yeah I get that. Let me put it in different way:
>>
>> Would there be an actual reason to package those files if not for rpm's
>> dependency generator? This kinda sounds like the answer is "no".
>
> None at all indeed.

BTW ignored deps should be debugable with specific logs when using
--rpmfcdebug IMGO
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 2 October 2017 at 15:04, Panu Matilainen  wrote:

>>> It's probably this:
>>>
>>> https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80
>>>
>>> If so, the following in the spec should work around it:
>>> %undefine __global_requires_exclude_from
>>> %undefine __global_provides_exclude_from
>>
>>
>> That works but that not manageable for 3000+ perl packages
>> So that would have to be reverted at the distro wide level.
>
>
> I wasn't suggesting you do it on every package, it was just to see whether
> that's really the cause.
>
> Just comment out the defaults in rpm's main macros file to stop it
> distro-wide.

Already done :-)

>>> I never really agreed to filtering doc dependencies because there's no
>>> reason docs could not have dependencies, they just tend to be slightly
>>> different from other docs.
>
>
> Oops, that paragraph got garbled (was in a bit of hurry). It was supposed to
> say something like "..., they just tend to be slightly different in nature
> from other dependencies.
>
>> I understand the reasoning.
>
>
> Not sure which reasoning you mean :) Like said, I never really liked the
> idea of filtering them in the first place.

I understand some packagers not want to got extra deps b/c of example
scripts & the like
But I think it's wrong to do it at distro wide level, at least for some distros

>> In that case I guess we could package them in another place (like
>> pythoneggs)
>> But that means more changes to 3000+ packages.
>> Up to now, mga perl packagers could just rely on using "%doc META.yml"
>> and voila autodeps were automagically working
>>
>>> Just wondering if those files should really be %doc - I've no idea what
>>> they
>>> do, but metadata doesn't really sound like documentation. Does the
>>> package
>>> work if installed with --nodocs?
>>
>>
>> Yes, of course they would work.
>> Those files are not packaged in eg FC
>> They're just metadata. But those metadata actually describe the deps.
>
>
> Yeah I get that. Let me put it in different way:
>
> Would there be an actual reason to package those files if not for rpm's
> dependency generator? This kinda sounds like the answer is "no".

None at all indeed.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/02/2017 02:05 PM, Thierry Vignaud wrote:

On 2 October 2017 at 12:34, Panu Matilainen  wrote:

On 10/02/2017 12:20 PM, Thierry Vignaud wrote:


On 28 September 2017 at 16:06, Panu Matilainen 
wrote:



There aren't that many changes since rc1, but enough to warrant a second
release candidate instead of going for final. The important ones being:

- Fix a bug of file triggers failing on some packages (MgBug:18797, in
4.13.x already)
- Fix a regression on 32bit architectures on generation of packages over
2GB
in size (RhBug:1492587)
- Fix rpm following arbitrary directory symlinks on installation
(CVE-2017-7500)
- Fix rpm following symlinks on file creation (CVE-2017-7501)
- Adjust verification to match the new directory symlink rule
- Forbid 'if' richops in 'or' context and 'unless' richops in 'and'
context

As usual, the details + download info at:

  http://rpm.org/wiki/Releases/4.14.0

Oh and release notes changed to use SHA256 instead of SHA1 for the source
checksum. Guess it's about time.



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=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 -
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/02/2017 02:14 PM, Thierry Vignaud wrote:

On 2 October 2017 at 12:05, Panu Matilainen  wrote:

It looks like some dep generators are no more run:
We've one dep generator carried by another pkg (so unchanged).
But since we upgrade to 4.14, those deps are no more run:

$ cat /usr/lib/rpm/fileattrs/perl_from_meta.attr
%__perl_from_meta_requires  %{_rpmconfigdir}/mageia/perl.req-from-meta
%__perl_from_meta_path  /(META.json|(MY|)META.yml)$

$ rpm --eval   %{_rpmconfigdir}/mageia/perl.req-from-meta
/usr/lib/rpm/mageia/perl.req-from-meta
$ ll /usr/lib/rpm/mageia/perl.req-from-meta
-rwxr-xr-x 1 rpm rpm 1428 Her   2 10:35
/usr/lib/rpm/mageia/perl.req-from-meta*
$ rpmbuild -bb --define "_topdir $PWD" --define "_tmppath
$PWD/BUILDROOT" --without build $PWD/SPECS/perl-Term-Clui.spec
--rpmfcdebug -v -vv
(...)
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20465
D:  waitpid(20465) rc 20465 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20467
D:  waitpid(20467) rc 20467 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20469
D:  waitpid(20469) rc 20469 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20471
D:  waitpid(20471) rc 20471 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20474
D:  waitpid(20474) rc 20474 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20475
D:  waitpid(20475) rc 20475 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20477
D:  waitpid(20477) rc 20477 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20480
D:  waitpid(20480) rc 20480 status 0

   ^so perl.req-from-meta is no more run, only other scripts

(...)
3
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/lib/perl5/vendor_perl/5.26.1/Term/Clui/FileSelect.pm
 Perl5 module source text [perl_base,perllib]
  R perl-base >= 2:5.26.1
  P perl(Term::Clui::FileSelect) = 1.710.0
  R perl(Exporter)
4
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui
 directory [none]
5
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/Changes
 ASCII text [none]
6
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/META.yml
ASCII text [perl_from_meta]
7
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/MYMETA.yml
  ASCII text [perl_from_meta]

^ so fileattr did matched but the corresponding generator was not run
(missing in above execve() list)

Any idea?



It's probably this:
https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80

If so, the following in the spec should work around it:
%undefine __global_requires_exclude_from
%undefine __global_provides_exclude_from


That works but that not manageable for 3000+ perl packages
So that would have to be reverted at the distro wide level.


I wasn't suggesting you do it on every package, it was just to see 
whether that's really the cause.


Just comment out the defaults in rpm's main macros file to stop it 
distro-wide.





I never really agreed to filtering doc dependencies because there's no
reason docs could not have dependencies, they just tend to be slightly
different from other docs.


Oops, that paragraph got garbled (was in a bit of hurry). It was 
supposed to say something like "..., they just tend to be slightly 
different in nature from other dependencies.



I understand the reasoning.


Not sure which reasoning you mean :) Like said, I never really liked the 
idea of filtering them in the first place.



In that case I guess we could package them in another place (like pythoneggs)
But that means more changes to 3000+ packages.
Up to now, mga perl packagers could just rely on using "%doc META.yml"
and voila autodeps were automagically working


Just wondering if those files should really be %doc - I've no idea what they
do, but metadata doesn't really sound like documentation. Does the package
work if installed with --nodocs?


Yes, of course they would work.
Those files are not packaged in eg FC
They're just metadata. But those metadata actually describe the deps.


Yeah I get that. Let me put it in different way:

Would there be an actual reason to package those files if not for rpm's 
dependency generator? This kinda sounds like the answer is "no".


- Panu -


Some distro rely on manually inserting the proper "BuildRequires",
"Requires:", "Recommend" & the like
Other (such mas mga) rely on autogenerating deps based on the deps
described in the perl package
(hint for a future feature for eg: fc29... :-) )

Like mga relied on pythoneggs before it got upstreamed as pythonX.Ydist(foobar)
And now other distro do too.




___
Rpm-maint mailing list

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 2 October 2017 at 12:05, Panu Matilainen  wrote:
>> It looks like some dep generators are no more run:
>> We've one dep generator carried by another pkg (so unchanged).
>> But since we upgrade to 4.14, those deps are no more run:
>>
>> $ cat /usr/lib/rpm/fileattrs/perl_from_meta.attr
>> %__perl_from_meta_requires  %{_rpmconfigdir}/mageia/perl.req-from-meta
>> %__perl_from_meta_path  /(META.json|(MY|)META.yml)$
>>
>> $ rpm --eval   %{_rpmconfigdir}/mageia/perl.req-from-meta
>> /usr/lib/rpm/mageia/perl.req-from-meta
>> $ ll /usr/lib/rpm/mageia/perl.req-from-meta
>> -rwxr-xr-x 1 rpm rpm 1428 Her   2 10:35
>> /usr/lib/rpm/mageia/perl.req-from-meta*
>> $ rpmbuild -bb --define "_topdir $PWD" --define "_tmppath
>> $PWD/BUILDROOT" --without build $PWD/SPECS/perl-Term-Clui.spec
>> --rpmfcdebug -v -vv
>> (...)
>> D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20465
>> D:  waitpid(20465) rc 20465 status 0
>> D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20467
>> D:  waitpid(20467) rc 20467 status 0
>> D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20469
>> D:  waitpid(20469) rc 20469 status 0
>> D:  execv(/usr/lib/rpm/perl.prov) pid 20471
>> D:  waitpid(20471) rc 20471 status 0
>> D:  execv(/usr/lib/rpm/perl.req) pid 20474
>> D:  waitpid(20474) rc 20474 status 0
>> D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20475
>> D:  waitpid(20475) rc 20475 status 0
>> D:  execv(/usr/lib/rpm/perl.prov) pid 20477
>> D:  waitpid(20477) rc 20477 status 0
>> D:  execv(/usr/lib/rpm/perl.req) pid 20480
>> D:  waitpid(20480) rc 20480 status 0
>>
>>   ^so perl.req-from-meta is no more run, only other scripts
>>
>> (...)
>>3
>> /home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/lib/perl5/vendor_perl/5.26.1/Term/Clui/FileSelect.pm
>> Perl5 module source text [perl_base,perllib]
>>  R perl-base >= 2:5.26.1
>>  P perl(Term::Clui::FileSelect) = 1.710.0
>>  R perl(Exporter)
>>4
>> /home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui
>> directory [none]
>>5
>> /home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/Changes
>> ASCII text [none]
>>6
>> /home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/META.yml
>>ASCII text [perl_from_meta]
>>7
>> /home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/MYMETA.yml
>>  ASCII text [perl_from_meta]
>>
>> ^ so fileattr did matched but the corresponding generator was not run
>> (missing in above execve() list)
>>
>> Any idea?
>
>
> It's probably this:
> https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80
>
> If so, the following in the spec should work around it:
> %undefine __global_requires_exclude_from
> %undefine __global_provides_exclude_from

That works but that not manageable for 3000+ perl packages
So that would have to be reverted at the distro wide level.

> I never really agreed to filtering doc dependencies because there's no
> reason docs could not have dependencies, they just tend to be slightly
> different from other docs.

I understand the reasoning.
In that case I guess we could package them in another place (like pythoneggs)
But that means more changes to 3000+ packages.
Up to now, mga perl packagers could just rely on using "%doc META.yml"
and voila autodeps were automagically working

> Just wondering if those files should really be %doc - I've no idea what they
> do, but metadata doesn't really sound like documentation. Does the package
> work if installed with --nodocs?

Yes, of course they would work.
Those files are not packaged in eg FC
They're just metadata. But those metadata actually describe the deps.
Some distro rely on manually inserting the proper "BuildRequires",
"Requires:", "Recommend" & the like
Other (such mas mga) rely on autogenerating deps based on the deps
described in the perl package
(hint for a future feature for eg: fc29... :-) )

Like mga relied on pythoneggs before it got upstreamed as pythonX.Ydist(foobar)
And now other distro do too.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 2 October 2017 at 12:34, Panu Matilainen  wrote:
> On 10/02/2017 12:20 PM, Thierry Vignaud wrote:
>>
>> On 28 September 2017 at 16:06, Panu Matilainen 
>> wrote:
>>>
>>>
>>> There aren't that many changes since rc1, but enough to warrant a second
>>> release candidate instead of going for final. The important ones being:
>>>
>>> - Fix a bug of file triggers failing on some packages (MgBug:18797, in
>>> 4.13.x already)
>>> - Fix a regression on 32bit architectures on generation of packages over
>>> 2GB
>>> in size (RhBug:1492587)
>>> - Fix rpm following arbitrary directory symlinks on installation
>>> (CVE-2017-7500)
>>> - Fix rpm following symlinks on file creation (CVE-2017-7501)
>>> - Adjust verification to match the new directory symlink rule
>>> - Forbid 'if' richops in 'or' context and 'unless' richops in 'and'
>>> context
>>>
>>> As usual, the details + download info at:
>>>
>>>  http://rpm.org/wiki/Releases/4.14.0
>>>
>>> Oh and release notes changed to use SHA256 instead of SHA1 for the source
>>> checksum. Guess it's about time.
>>
>>
>> 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=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?

None of that fixes it
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/02/2017 12:20 PM, Thierry Vignaud wrote:

On 28 September 2017 at 16:06, Panu Matilainen  wrote:


There aren't that many changes since rc1, but enough to warrant a second
release candidate instead of going for final. The important ones being:

- Fix a bug of file triggers failing on some packages (MgBug:18797, in
4.13.x already)
- Fix a regression on 32bit architectures on generation of packages over 2GB
in size (RhBug:1492587)
- Fix rpm following arbitrary directory symlinks on installation
(CVE-2017-7500)
- Fix rpm following symlinks on file creation (CVE-2017-7501)
- Adjust verification to match the new directory symlink rule
- Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context

As usual, the details + download info at:

 http://rpm.org/wiki/Releases/4.14.0

Oh and release notes changed to use SHA256 instead of SHA1 for the source
checksum. Guess it's about time.


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


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Panu Matilainen 

On 10/02/2017 12:11 PM, Thierry Vignaud wrote:

On 28 September 2017 at 16:06, Panu Matilainen  wrote:


There aren't that many changes since rc1, but enough to warrant a second
release candidate instead of going for final. The important ones being:

- Fix a bug of file triggers failing on some packages (MgBug:18797, in
4.13.x already)
- Fix a regression on 32bit architectures on generation of packages over 2GB
in size (RhBug:1492587)
- Fix rpm following arbitrary directory symlinks on installation
(CVE-2017-7500)
- Fix rpm following symlinks on file creation (CVE-2017-7501)
- Adjust verification to match the new directory symlink rule
- Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context

As usual, the details + download info at:

 http://rpm.org/wiki/Releases/4.14.0

Oh and release notes changed to use SHA256 instead of SHA1 for the source
checksum. Guess it's about time.

On behalf of the rpm-team,


It looks like some dep generators are no more run:
We've one dep generator carried by another pkg (so unchanged).
But since we upgrade to 4.14, those deps are no more run:

$ cat /usr/lib/rpm/fileattrs/perl_from_meta.attr
%__perl_from_meta_requires  %{_rpmconfigdir}/mageia/perl.req-from-meta
%__perl_from_meta_path  /(META.json|(MY|)META.yml)$

$ rpm --eval   %{_rpmconfigdir}/mageia/perl.req-from-meta
/usr/lib/rpm/mageia/perl.req-from-meta
$ ll /usr/lib/rpm/mageia/perl.req-from-meta
-rwxr-xr-x 1 rpm rpm 1428 Her   2 10:35 /usr/lib/rpm/mageia/perl.req-from-meta*
$ rpmbuild -bb --define "_topdir $PWD" --define "_tmppath
$PWD/BUILDROOT" --without build $PWD/SPECS/perl-Term-Clui.spec
--rpmfcdebug -v -vv
(...)
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20465
D:  waitpid(20465) rc 20465 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20467
D:  waitpid(20467) rc 20467 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20469
D:  waitpid(20469) rc 20469 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20471
D:  waitpid(20471) rc 20471 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20474
D:  waitpid(20474) rc 20474 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20475
D:  waitpid(20475) rc 20475 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20477
D:  waitpid(20477) rc 20477 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20480
D:  waitpid(20480) rc 20480 status 0

  ^so perl.req-from-meta is no more run, only other scripts

(...)
   3 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/lib/perl5/vendor_perl/5.26.1/Term/Clui/FileSelect.pm
Perl5 module source text [perl_base,perllib]
 R perl-base >= 2:5.26.1
 P perl(Term::Clui::FileSelect) = 1.710.0
 R perl(Exporter)
   4 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui
directory [none]
   5 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/Changes
ASCII text [none]
   6 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/META.yml
   ASCII text [perl_from_meta]
   7 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/MYMETA.yml
 ASCII text [perl_from_meta]

^ so fileattr did matched but the corresponding generator was not run
(missing in above execve() list)

Any idea?


It's probably this:
https://github.com/rpm-software-management/rpm/commit/816c7cf3fdae5c45de02a42a2245549778e2ca80

If so, the following in the spec should work around it:
%undefine __global_requires_exclude_from
%undefine __global_provides_exclude_from

I never really agreed to filtering doc dependencies because there's no 
reason docs could not have dependencies, they just tend to be slightly 
different from other docs.


Just wondering if those files should really be %doc - I've no idea what 
they do, but metadata doesn't really sound like documentation. Does the 
package work if installed with --nodocs?


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 28 September 2017 at 16:06, Panu Matilainen  wrote:
>
> There aren't that many changes since rc1, but enough to warrant a second
> release candidate instead of going for final. The important ones being:
>
> - Fix a bug of file triggers failing on some packages (MgBug:18797, in
> 4.13.x already)
> - Fix a regression on 32bit architectures on generation of packages over 2GB
> in size (RhBug:1492587)
> - Fix rpm following arbitrary directory symlinks on installation
> (CVE-2017-7500)
> - Fix rpm following symlinks on file creation (CVE-2017-7501)
> - Adjust verification to match the new directory symlink rule
> - Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context
>
> As usual, the details + download info at:
>
> http://rpm.org/wiki/Releases/4.14.0
>
> Oh and release notes changed to use SHA256 instead of SHA1 for the source
> checksum. Guess it's about time.

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=markup

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


LOG.t04b
Description: Binary data


LOG.t04
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.14.0 release candidate 2 is out

2017-10-02 Thread Thierry Vignaud 
On 28 September 2017 at 16:06, Panu Matilainen  wrote:
>
> There aren't that many changes since rc1, but enough to warrant a second
> release candidate instead of going for final. The important ones being:
>
> - Fix a bug of file triggers failing on some packages (MgBug:18797, in
> 4.13.x already)
> - Fix a regression on 32bit architectures on generation of packages over 2GB
> in size (RhBug:1492587)
> - Fix rpm following arbitrary directory symlinks on installation
> (CVE-2017-7500)
> - Fix rpm following symlinks on file creation (CVE-2017-7501)
> - Adjust verification to match the new directory symlink rule
> - Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context
>
> As usual, the details + download info at:
>
> http://rpm.org/wiki/Releases/4.14.0
>
> Oh and release notes changed to use SHA256 instead of SHA1 for the source
> checksum. Guess it's about time.
>
> On behalf of the rpm-team,

It looks like some dep generators are no more run:
We've one dep generator carried by another pkg (so unchanged).
But since we upgrade to 4.14, those deps are no more run:

$ cat /usr/lib/rpm/fileattrs/perl_from_meta.attr
%__perl_from_meta_requires  %{_rpmconfigdir}/mageia/perl.req-from-meta
%__perl_from_meta_path  /(META.json|(MY|)META.yml)$

$ rpm --eval   %{_rpmconfigdir}/mageia/perl.req-from-meta
/usr/lib/rpm/mageia/perl.req-from-meta
$ ll /usr/lib/rpm/mageia/perl.req-from-meta
-rwxr-xr-x 1 rpm rpm 1428 Her   2 10:35 /usr/lib/rpm/mageia/perl.req-from-meta*
$ rpmbuild -bb --define "_topdir $PWD" --define "_tmppath
$PWD/BUILDROOT" --without build $PWD/SPECS/perl-Term-Clui.spec
--rpmfcdebug -v -vv
(...)
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20465
D:  waitpid(20465) rc 20465 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20467
D:  waitpid(20467) rc 20467 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20469
D:  waitpid(20469) rc 20469 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20471
D:  waitpid(20471) rc 20471 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20474
D:  waitpid(20474) rc 20474 status 0
D:  execv(/usr/lib/rpm/mageia/perl_base.req) pid 20475
D:  waitpid(20475) rc 20475 status 0
D:  execv(/usr/lib/rpm/perl.prov) pid 20477
D:  waitpid(20477) rc 20477 status 0
D:  execv(/usr/lib/rpm/perl.req) pid 20480
D:  waitpid(20480) rc 20480 status 0

 ^so perl.req-from-meta is no more run, only other scripts

(...)
  3 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/lib/perl5/vendor_perl/5.26.1/Term/Clui/FileSelect.pm
   Perl5 module source text [perl_base,perllib]
R perl-base >= 2:5.26.1
P perl(Term::Clui::FileSelect) = 1.710.0
R perl(Exporter)
  4 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui
   directory [none]
  5 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/Changes
   ASCII text [none]
  6 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/META.yml
  ASCII text [perl_from_meta]
  7 
/home/tv/mga/pkgs/perl-Term-Clui/BUILDROOT/perl-Term-Clui-1.710.0-2.mga7.x86_64/usr/share/doc/perl-Term-Clui/MYMETA.yml
ASCII text [perl_from_meta]

^ so fileattr did matched but the corresponding generator was not run
(missing in above execve() list)

Any idea?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint