Re: [Rpm-maint] [Rpm-announce] RPM 4.17.0 beta1 released!

[Thierry Vignaud]

Le mar. 22 juin 2021 à 14:37, Panu Matilainen  a
écrit :

>
> More or less in planned schedule for a change, here goes 4.17.0 beta1.
> We're not actually planning for a second beta, the 1 is there just in
> case because there are some unusual changes between alpha and beta:
>
>* Debuginfo extraction split to external project:
>  https://sourceware.org/debugedit/
>* Python helpers split to external project:
>  https://github.com/rpm-software-management/python-rpm-packaging
>* Various unmaintained scripts removed
>* New buildroot policy to remove `.la` files by default
>* Man pages converted to Markdown for easier maintenance + many other
>  doc improvements
>* Miscellaneous bugs and regressions fixed
>
> In other words, there are more external dependencies now, packaging will
> need to be updated and adjusted accordingly etc. Normally one would
> rather have these in the alpha already but the timing was impossible in
> this case. We'll try to step on the brakes harder going towards rc which
> should take place in August.
>
> As usual, download info & further details at
>
>  https://rpm.org/wiki/Releases/4.17.0
>
>
>
Humm it fails to build:
(…)
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[3]: Entering directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
no -s -t man ./ja/rpmbuild.8.md -o ja/rpmbuild.8
make[3]: no: No such file or directory
make[3]: *** [Makefile:869: ja/rpmbuild.8] Error 127
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[3]: Entering directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
no -s -t man ./ja/rpmgraph.8.md -o ja/rpmgraph.8
make[3]: no: No such file or directory
make[3]: *** [Makefile:869: ja/rpmgraph.8] Error 127
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[3]: Entering directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
no -s -t man ./ko/rpm.8.md -o ko/rpm.8
make[3]: no: No such file or directory
make[3]: *** [Makefile:869: ko/rpm.8] Error 127
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[3]: Entering directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
no -s -t man ./ko/rpm2cpio.8.md -o ko/rpm2cpio.8
make[3]: no: No such file or directory
make[3]: *** [Makefile:869: ko/rpm2cpio.8] Error 127
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[3]: Entering directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
no -s -t man ./gendiff.1.md -o gendiff.1
make[3]: no: No such file or directory
make[3]: *** [Makefile:869: gendiff.1] Error 127
make[3]: Leaving directory '/ff/rpm/BUILD/rpm-4.17.0-beta1/docs/man'
make[2]: *** [Makefile:495: all-recursive] Error 1
error: failed!
make[1]: *** [Makefile:1300: all-recursive] Error 1
make: *** [Makefile:746: all] Error 2
error: Bad exit status from /ff/rpm/BUILDROOT/rpm-tmp.QkTTXA (%build)


Probably due to:
"checking for pandoc... no"
(undetected new dep)

Many distros do not have pandoc available…

So I would blame:
https://github.com/rpm-software-management/rpm/commit/937785005d8ca34805cf6a0eb58ad97691af11d6
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.17.0 alpha released!

[Thierry Vignaud]

Le lun. 26 avr. 2021 à 11:34, Panu Matilainen  a
écrit :

>
> The beginning of this year has gone nothing like planned, and
> consequently we had to postpone and even revert some things originally
> planned for 4.17. But what the hey, there's plenty of good stuff here as
> it is, and there will always be another release.
>
> Highlights include:
> - More robust install failure handling
> - Many macro improvements, in particular wrt Lua integration
> - Some long-needed transaction API enhancements
> - Beginnings of a reference manual
>
> In particular macros have seen a big overhaul: built-in and user-defined
> macros have been unified internally, and in general can be called by
> using either syntax. The Lua-macro interface is much improved, macro
> arguments are passed as native Lua arguments, parametric macros can be
> called as native Lua functions and all rpm macros can be natively
> accessed via a handy 'macros' table. In theory this is all backwards
> compatible, but with as with any changes there could be something we
> missed.
>
> For further details and download info, head over to
>
> https://rpm.org/wiki/Releases/4.17.0
>
> On behalf of the rpm team,
>
> - Panu -
>
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
>

For the record, rpm-4.16.90's testsuite has an unexpected failure here:
323: rpm -i hardlinksFAILED (rpmi.at:758)
(…)
+++
/ff/rpm/BUILD/rpm-4.16.90-git15395/tests/rpmtests.dir/at-groups/323/stderr
 2021-04-26 10:35:59.602608319 +
@@ -1,3 +1 @@
-error: unpacking of archive failed: cpio: Archive file not in header
-error: hlinktest-1.0-1.noarch: install failed

./rpmi.at:758: exit code was 0, expected 1
323. rpmi.at:728: 323. rpm -i hardlinks (rpmi.at:728): FAILED (rpmi.at:758)

For the record, the generated package is also installable with rpm-4.16.1.3:
$ rpm -Uvh --test
./BUILD/rpm-4.16.90-git15395/tests/rpmtests.dir/323/testing/build/RPMS/noarch/hlinktest-1.0-1.noarch.rpm
Verifying...  #
[100%]
Preparing...  #
[100%]

This is a new test introduced in commit
a82251b44ee2d2802ee8aea1b3d89f88beee4bad


tests.txt.gz
Description: application/gzip
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 RC1 released!

[Thierry Vignaud]

Le mar. 15 sept. 2020 à 12:51, Thierry Vignaud 
a écrit :

> Le mar. 15 sept. 2020 à 12:40, Thierry Vignaud 
> a écrit :
>
>> Not sure if it's related to 4.16.0 but for some time, when looking at
>>> some (successful) builds, I see several objcopy error messages during late
>>> build stages.
>>> eg:
>>> objcopy: unable to copy file
>>> '/pkgs/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
>>> reason: Permission denied
>>>
>>> It doesn't affect all packages, but those affected are quite reproducable
>>> Has anyone see sg similar?
>>>
>>
>> For example, adding "-x" to /usr/lib/rpm/find-debuginfo.sh shebang + "ls
>> -l" results in:
>>
>> + type gdb-add-index
>> + ls -l
>> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
>> -rwxr-xr-x 2 tv users 9682392 Sep 15 12:36
>> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
>> + gdb-add-index
>> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
>> objcopy: unable to copy file
>> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so';
>> reason: Permission denied
>> + objcopy --merge-notes
>> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/dmeventd
>> objcopy: unable to copy file
>> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2thin.so';
>> reason: Permission denied
>> + objcopy --merge-notes
>> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so
>> objcopy: unable to copy file
>> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2mirror.so';
>> reason: Permission denied
>> objcopy: unable to copy file
>> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
>> reason: Permission denied
>> objcopy: unable to copy file
>> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib/systemd/system-generators/lvm2-activation-generator';
>> reason: Permission denied
>>
>
> It looks like it affect other Fedora Rawhide too:
> https://www.spinics.net/lists/fedora-devel/msg276748.html
>
> Both are running rpm-4.16, glibc-2.31 in one, 2.33dev in the other.
> It happens with both gdb-9.1 & 9.2 on the Mageia side
>

So in build directory:
lrwxrwxrwx 1 tv users39 Gwe  15 12:04
./BUILD/LVM2.2.03.10/shared/daemons/dmeventd/plugins/snapshot/libdevmapper-event-lvm2snapshot.so
-> libdevmapper-event-lvm2snapshot.so.2.03
-rwxr-xr-x 1 tv users 34800 Gwe  15 12:04
./BUILD/LVM2.2.03.10/shared/daemons/dmeventd/plugins/snapshot/libdevmapper-event-lvm2snapshot.so.2.03

In BUILDROOT:

 -r-xr-xr-x 1 tv users 34792 Sep 15 12:52
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so

Installed system:
-rw-r--r-- 1 root root 14624 Gwe  10 11:42
/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so
(because of "%defattr(644,root,root,755)")

-r-xr-xr-x 1 root root 14624 Gwe  15 12:58
/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so*
(w/o "%defattr…")

So it looks like the culprit is the package's BS:
/usr/bin/install -p -m 555  -D libdevmapper-event-lvm2snapshot.so
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.1.mga8.x86_64//usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so

The question is why does it show now?
Was some output redirected to /dev/null previously?
Should either find-debuginfo.sh or objcopy workaround perms (by using a
temp file with proper perms, then move/overwite & re-set the original
perms?)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 RC1 released!

[Thierry Vignaud]

Le mar. 15 sept. 2020 à 12:40, Thierry Vignaud 
a écrit :

> Not sure if it's related to 4.16.0 but for some time, when looking at some
>> (successful) builds, I see several objcopy error messages during late build
>> stages.
>> eg:
>> objcopy: unable to copy file
>> '/pkgs/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
>> reason: Permission denied
>>
>> It doesn't affect all packages, but those affected are quite reproducable
>> Has anyone see sg similar?
>>
>
> For example, adding "-x" to /usr/lib/rpm/find-debuginfo.sh shebang + "ls
> -l" results in:
>
> + type gdb-add-index
> + ls -l
> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
> -rwxr-xr-x 2 tv users 9682392 Sep 15 12:36
> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
> + gdb-add-index
> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
> objcopy: unable to copy file
> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so';
> reason: Permission denied
> + objcopy --merge-notes
> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/dmeventd
> objcopy: unable to copy file
> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2thin.so';
> reason: Permission denied
> + objcopy --merge-notes
> /home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so
> objcopy: unable to copy file
> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2mirror.so';
> reason: Permission denied
> objcopy: unable to copy file
> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
> reason: Permission denied
> objcopy: unable to copy file
> '/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib/systemd/system-generators/lvm2-activation-generator';
> reason: Permission denied
>

It looks like it affect other Fedora Rawhide too:
https://www.spinics.net/lists/fedora-devel/msg276748.html

Both are running rpm-4.16, glibc-2.31 in one, 2.33dev in the other.
It happens with both gdb-9.1 & 9.2 on the Mageia side
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 RC1 released!

[Thierry Vignaud]

Le mar. 15 sept. 2020 à 12:25, Thierry Vignaud 
a écrit :

> Le lun. 31 août 2020 à 11:30, Panu Matilainen  a
> écrit :
>
>>
>> Very little has changed since beta3, there are a handful of bugfixes
>> across the board to various older issues but no regressions were found
>> in beta3 so none of the sort fixed either.
>>
>> Barring any unexpected disasters, this should be what goes out as final
>> in couple of weeks.
>>
>> Download info & further details at:
>>
>>  https://rpm.org/wiki/Releases/4.16.0
>>
>> - Panu -
>>
>> ___
>> Rpm-announce mailing list
>> rpm-annou...@lists.rpm.org
>> http://lists.rpm.org/mailman/listinfo/rpm-announce
>>
>
> Not sure if it's related to 4.16.0 but for some time, when looking at some
> (successful) builds, I see several objcopy error messages during late build
> stages.
> eg:
> objcopy: unable to copy file
> '/pkgs/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
> reason: Permission denied
>
> It doesn't affect all packages, but those affected are quite reproducable
> Has anyone see sg similar?
>

For example, adding "-x" to /usr/lib/rpm/find-debuginfo.sh shebang + "ls
-l" results in:

+ type gdb-add-index
+ ls -l
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
-rwxr-xr-x 2 tv users 9682392 Sep 15 12:36
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
+ gdb-add-index
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/lvm
objcopy: unable to copy file
'/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so';
reason: Permission denied
+ objcopy --merge-notes
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/sbin/dmeventd
objcopy: unable to copy file
'/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2thin.so';
reason: Permission denied
+ objcopy --merge-notes
/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2snapshot.so
objcopy: unable to copy file
'/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2mirror.so';
reason: Permission denied
objcopy: unable to copy file
'/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
reason: Permission denied
objcopy: unable to copy file
'/home/tv/mga/pkgs/UTILS/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib/systemd/system-generators/lvm2-activation-generator';
reason: Permission denied
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 RC1 released!

[Thierry Vignaud]

Le lun. 31 août 2020 à 11:30, Panu Matilainen  a
écrit :

>
> Very little has changed since beta3, there are a handful of bugfixes
> across the board to various older issues but no regressions were found
> in beta3 so none of the sort fixed either.
>
> Barring any unexpected disasters, this should be what goes out as final
> in couple of weeks.
>
> Download info & further details at:
>
>  https://rpm.org/wiki/Releases/4.16.0
>
> - Panu -
>
> ___
> Rpm-announce mailing list
> rpm-annou...@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-announce
>

Not sure if it's related to 4.16.0 but for some time, when looking at some
(successful) builds, I see several objcopy error messages during late build
stages.
eg:
objcopy: unable to copy file
'/pkgs/lvm2/BUILDROOT/lvm2-2.03.10-3.mga8.x86_64/usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so';
reason: Permission denied

It doesn't affect all packages, but those affected are quite reproducable
Has anyone see sg similar?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 beta3 released!

[Thierry Vignaud]

Le mer. 24 juin 2020 à 10:47, Panu Matilainen  a écrit :
>
>
> This fixes multiple dependency generator related regressions introduced
> beta2, by reverting the "fail build on dependency generator failure"
> change introduced there.
>
> We don't usually release new tarballs just because an issue was found in
> a beta, but since beta2 was released to address just this type of issues
> in beta1 already... And is this wasn't enough, I managed to upload a
> wrong tarball to the website momentarily, so if you were hasty enough to
> download the beta3 tarball before this announcement email, make sure you
> have the one whose sha256sum is
> e6196fac6adcc13ca39699627a1cfc99c79c0beb9acca8c4d065b6cc9d50471c
>
> Sigh, this is what you get for breaking tradition.

Shouldn't it be time to do a RC release and planning for 4.16.0 GA?
See you
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 beta2 released!

[Thierry Vignaud]

Le mar. 23 juin 2020 à 14:41, Panu Matilainen  a
écrit :

>
> Some fairly important fixes cropped up in the last few weeks so we
> decided to go with a second beta for a change. The highlights since
> beta1 include:
>
> - fix hardlink breakage on upgrade when minimize_writes is enabled
> - fix some file triggers missed with sqlite backend
> - fix SSD optimizations also enabling IO-flushing
> - fix too small signature header size limit
> - fix fail build on dependency generator and %_build_pkgcheck_set errors
> - fix data race in threaded package generation
> - fix metainfo dependency generator regression
> - fix Python addErase() not raising exception on non-existent packages
> - fix test-suite parallel execution
>

And thanks you for that last point, the testsuite used to beat the
compilation part on the timing scale, but now it's fast, especially on SSD
(even if there's a small gain even on HDs)
(elapsed 9:07.09 -> 8:31.92 on HD --> 0:33.65 on a (old) SSD)
We lost the test group names in the output but we can always find the
affected test thanks to its name.
So that's a _huge_ improvement!
Thanks again :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 beta3 released!

[Thierry Vignaud]

Le mer. 24 juin 2020 à 11:02, Thierry Vignaud  a
écrit :

>
>> This fixes multiple dependency generator related regressions introduced
>>> beta2, by reverting the "fail build on dependency generator failure"
>>> change introduced there.
>>>
>>> We don't usually release new tarballs just because an issue was found in
>>> a beta, but since beta2 was released to address just this type of issues
>>> in beta1 already... And is this wasn't enough, I managed to upload a
>>> wrong tarball to the website momentarily, so if you were hasty enough to
>>> download the beta3 tarball before this announcement email, make sure you
>>> have the one whose sha256sum is
>>> e6196fac6adcc13ca39699627a1cfc99c79c0beb9acca8c4d065b6cc9d50471c
>>>
>>> Sigh, this is what you get for breaking tradition.
>>>
>>
>> Sorry to be the bearer of bad news again this week but… there's a new
>> testsuite failure:
>>
>> Beta2 was fine besides "rpmbuild.at:482 Dependency generation 3 build":
>>
>> http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200623145307.tv.duvel.658/rpm-4.16.0-0.beta2.1.mga8/
>>
>> But beta3 introduces a new failure. See build*.log files & look for
>> "Summary of the failures" at:
>>
>> http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200624083544.tv.duvel.13457/rpm-4.16.0-0.beta3.1.mga8/
>>
>>  235: rpmsigdig.at:144   rpmkeys -Kv  2
>>   rpmkeys digest
>>
>> ## -- ##
>> ## Detailed failed tests. ##
>> ## -- ##
>>
>> # -*- compilation -*-
>> 235. rpmsigdig.at:144: testing rpmkeys -Kv  2 ...
>> ./rpmsigdig.at:146:
>>
>>
>> if ! [ -d testing/ ]; then
>> cp -aP "${RPMTEST}" .
>> chmod -R u+w testing/
>> mkdir -p testing/build
>> ln -s ../data/SOURCES testing/build/
>> fi
>> export RPMTEST="${PWD}/testing"
>> export TOPDIR="${RPMTEST}/build"
>> export HOME="${RPMTEST}"
>>
>> rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
>> runroot rpm --initdb
>>
>>
>> runroot rpmbuild -bb --quiet \
>>  --define "%optflags -O2 -g" \
>>  --define "%_target_platform noarch-linux" \
>>  --define "%_binary_payload w.ufdio" \
>>  --define "%_buildhost localhost" \
>>  --define "%use_source_date_epoch_as_buildtime 1" \
>>  --define "%source_date_epoch_from_changelog 1" \
>>  --define "%clamp_mtime_to_source_date_epoch 1" \
>>  /data/SPECS/attrtest.spec
>> for v in SHA256HEADER SHA1HEADER SIGMD5 PAYLOADDIGEST PAYLOADDIGESTALT; do
>> runroot rpm -q --qf "${v}: %{${v}}\n" 
>> /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
>> done
>> runroot rpmkeys -Kv /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
>>
>> --- -2020-06-24 08:37:24.201578966 +
>> +++ 
>> /home/iurt/rpmbuild/BUILD/rpm-4.16.0-beta3/tests/rpmtests.dir/at-groups/235/stdout
>>2020-06-24 08:37:24.186383200 +
>> @@ -1,6 +1,6 @@
>> -SHA256HEADER: 
>> 6104d0f021dfe58af39b1957fa222762a45cbec221b10915d61d5238858f3c28
>> -SHA1HEADER: e58516622b8b8960201d07e7b061af8bc21fcaef
>> -SIGMD5: 09ca69da1b4a85c202c377da3cf20048
>> +SHA256HEADER: 
>> 24790a8639dec5e0d4506f8ebacba0844b41bfd1aeecf7542251cafdebd1f7f3
>> +SHA1HEADER: 3539a6132ce89ef2296f5db3ce90f7991891e739
>> +SIGMD5: 4a51b31c3e136b3c5b3971f3d1811a7b
>>  PAYLOADDIGEST: 
>> 749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
>>  PAYLOADDIGESTALT: 
>> 749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
>>  /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm:
>> 235. rpmsigdig.at:144: 235. rpmkeys -Kv  2 (rpmsigdig.at:144): 
>> FAILED (rpmsigdig.at:146)
>>
>>
>> ## - ##
>>
>>
> Opened as https://github.com/rpm-software-management/rpm/issues/1288
> I forgot to mention I'm running the testsuite in the new parallel mode.
> This was already the case for my builds of beta2
>

Also I forgot to report this one yesterday:
https://github.com/rpm-software-management/rpm/issues/1289
rpm's %clean fails unless I run "chmod -R +w tests/testing/"
It might be a side effect of the // testsuite
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 beta3 released!

[Thierry Vignaud]

Le mer. 24 juin 2020 à 10:59, Thierry Vignaud  a
écrit :

>
> This fixes multiple dependency generator related regressions introduced
>> beta2, by reverting the "fail build on dependency generator failure"
>> change introduced there.
>>
>> We don't usually release new tarballs just because an issue was found in
>> a beta, but since beta2 was released to address just this type of issues
>> in beta1 already... And is this wasn't enough, I managed to upload a
>> wrong tarball to the website momentarily, so if you were hasty enough to
>> download the beta3 tarball before this announcement email, make sure you
>> have the one whose sha256sum is
>> e6196fac6adcc13ca39699627a1cfc99c79c0beb9acca8c4d065b6cc9d50471c
>>
>> Sigh, this is what you get for breaking tradition.
>>
>
> Sorry to be the bearer of bad news again this week but… there's a new
> testsuite failure:
>
> Beta2 was fine besides "rpmbuild.at:482 Dependency generation 3 build":
>
> http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200623145307.tv.duvel.658/rpm-4.16.0-0.beta2.1.mga8/
>
> But beta3 introduces a new failure. See build*.log files & look for
> "Summary of the failures" at:
>
> http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200624083544.tv.duvel.13457/rpm-4.16.0-0.beta3.1.mga8/
>
>  235: rpmsigdig.at:144   rpmkeys -Kv  2
>   rpmkeys digest
>
> ## -- ##
> ## Detailed failed tests. ##
> ## -- ##
>
> # -*- compilation -*-
> 235. rpmsigdig.at:144: testing rpmkeys -Kv  2 ...
> ./rpmsigdig.at:146:
>
>
> if ! [ -d testing/ ]; then
> cp -aP "${RPMTEST}" .
> chmod -R u+w testing/
> mkdir -p testing/build
> ln -s ../data/SOURCES testing/build/
> fi
> export RPMTEST="${PWD}/testing"
> export TOPDIR="${RPMTEST}/build"
> export HOME="${RPMTEST}"
>
> rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
> runroot rpm --initdb
>
>
> runroot rpmbuild -bb --quiet \
>   --define "%optflags -O2 -g" \
>   --define "%_target_platform noarch-linux" \
>   --define "%_binary_payload w.ufdio" \
>   --define "%_buildhost localhost" \
>   --define "%use_source_date_epoch_as_buildtime 1" \
>   --define "%source_date_epoch_from_changelog 1" \
>   --define "%clamp_mtime_to_source_date_epoch 1" \
>   /data/SPECS/attrtest.spec
> for v in SHA256HEADER SHA1HEADER SIGMD5 PAYLOADDIGEST PAYLOADDIGESTALT; do
> runroot rpm -q --qf "${v}: %{${v}}\n" 
> /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
> done
> runroot rpmkeys -Kv /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
>
> --- - 2020-06-24 08:37:24.201578966 +
> +++ 
> /home/iurt/rpmbuild/BUILD/rpm-4.16.0-beta3/tests/rpmtests.dir/at-groups/235/stdout
> 2020-06-24 08:37:24.186383200 +
> @@ -1,6 +1,6 @@
> -SHA256HEADER: 
> 6104d0f021dfe58af39b1957fa222762a45cbec221b10915d61d5238858f3c28
> -SHA1HEADER: e58516622b8b8960201d07e7b061af8bc21fcaef
> -SIGMD5: 09ca69da1b4a85c202c377da3cf20048
> +SHA256HEADER: 
> 24790a8639dec5e0d4506f8ebacba0844b41bfd1aeecf7542251cafdebd1f7f3
> +SHA1HEADER: 3539a6132ce89ef2296f5db3ce90f7991891e739
> +SIGMD5: 4a51b31c3e136b3c5b3971f3d1811a7b
>  PAYLOADDIGEST: 
> 749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
>  PAYLOADDIGESTALT: 
> 749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
>  /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm:
> 235. rpmsigdig.at:144: 235. rpmkeys -Kv  2 (rpmsigdig.at:144): 
> FAILED (rpmsigdig.at:146)
>
>
> ## - ##
>
>
Opened as https://github.com/rpm-software-management/rpm/issues/1288
I forgot to mention I'm running the testsuite in the new parallel mode.
This was already the case for my builds of beta2
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 beta3 released!

[Thierry Vignaud]

Le mer. 24 juin 2020 à 10:47, Panu Matilainen  a
écrit :

>
> This fixes multiple dependency generator related regressions introduced
> beta2, by reverting the "fail build on dependency generator failure"
> change introduced there.
>
> We don't usually release new tarballs just because an issue was found in
> a beta, but since beta2 was released to address just this type of issues
> in beta1 already... And is this wasn't enough, I managed to upload a
> wrong tarball to the website momentarily, so if you were hasty enough to
> download the beta3 tarball before this announcement email, make sure you
> have the one whose sha256sum is
> e6196fac6adcc13ca39699627a1cfc99c79c0beb9acca8c4d065b6cc9d50471c
>
> Sigh, this is what you get for breaking tradition.
>

Sorry to be the bearer of bad news again this week but… there's a new
testsuite failure:

Beta2 was fine besides "rpmbuild.at:482 Dependency generation 3 build":
http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200623145307.tv.duvel.658/rpm-4.16.0-0.beta2.1.mga8/

But beta3 introduces a new failure. See build*.log files & look for
"Summary of the failures" at:
http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/20200624083544.tv.duvel.13457/rpm-4.16.0-0.beta3.1.mga8/

 235: rpmsigdig.at:144   rpmkeys -Kv  2
  rpmkeys digest

## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
235. rpmsigdig.at:144: testing rpmkeys -Kv  2 ...
./rpmsigdig.at:146:


if ! [ -d testing/ ]; then
cp -aP "${RPMTEST}" .
chmod -R u+w testing/
mkdir -p testing/build
ln -s ../data/SOURCES testing/build/
fi
export RPMTEST="${PWD}/testing"
export TOPDIR="${RPMTEST}/build"
export HOME="${RPMTEST}"

rm -rf "${RPMTEST}"`rpm --eval '%_dbpath'`/*
runroot rpm --initdb


runroot rpmbuild -bb --quiet \
--define "%optflags -O2 -g" \
--define "%_target_platform noarch-linux" \
--define "%_binary_payload w.ufdio" \
--define "%_buildhost localhost" \
--define "%use_source_date_epoch_as_buildtime 1" \
--define "%source_date_epoch_from_changelog 1" \
--define "%clamp_mtime_to_source_date_epoch 1" \
/data/SPECS/attrtest.spec
for v in SHA256HEADER SHA1HEADER SIGMD5 PAYLOADDIGEST PAYLOADDIGESTALT; do
runroot rpm -q --qf "${v}: %{${v}}\n"
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm
done
runroot rpmkeys -Kv /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm

--- -   2020-06-24 08:37:24.201578966 +
+++ 
/home/iurt/rpmbuild/BUILD/rpm-4.16.0-beta3/tests/rpmtests.dir/at-groups/235/stdout
  2020-06-24
08:37:24.186383200 +
@@ -1,6 +1,6 @@
-SHA256HEADER: 6104d0f021dfe58af39b1957fa222762a45cbec221b10915d61d5238858f3c28
-SHA1HEADER: e58516622b8b8960201d07e7b061af8bc21fcaef
-SIGMD5: 09ca69da1b4a85c202c377da3cf20048
+SHA256HEADER: 24790a8639dec5e0d4506f8ebacba0844b41bfd1aeecf7542251cafdebd1f7f3
+SHA1HEADER: 3539a6132ce89ef2296f5db3ce90f7991891e739
+SIGMD5: 4a51b31c3e136b3c5b3971f3d1811a7b
 PAYLOADDIGEST: 749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
 PAYLOADDIGESTALT:
749d8980cc5889419da8cdbe9a5b3292742af8a227db3635f84966481b7612a8
 /build/RPMS/noarch/attrtest-1.0-1.noarch.rpm:
235. rpmsigdig.at:144: 235. rpmkeys -Kv  2
(rpmsigdig.at:144): FAILED (rpmsigdig.at:146)


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

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 beta2 released!

[Thierry Vignaud]

Le mar. 23 juin 2020 à 14:41, Panu Matilainen  a
écrit :

>
> Some fairly important fixes cropped up in the last few weeks so we
> decided to go with a second beta for a change. The highlights since
> beta1 include:
>
> - fix hardlink breakage on upgrade when minimize_writes is enabled
> - fix some file triggers missed with sqlite backend
> - fix SSD optimizations also enabling IO-flushing
> - fix too small signature header size limit
> - fix fail build on dependency generator and %_build_pkgcheck_set errors
> - fix data race in threaded package generation
> - fix metainfo dependency generator regression
> - fix Python addErase() not raising exception on non-existent packages
> - fix test-suite parallel execution
>
> Download info & further details at:
>
>  https://rpm.org/wiki/Releases/4.16.0
>
> On behalf of rpm-team,
>

It doesn't compile on arches other than x86_64 (see my comment in the
appropriate thread)
(due to hardcoded x86_64 in expected test output)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.16.0 beta1 released!

[Thierry Vignaud]

Le ven. 29 mai 2020 à 09:57, Panu Matilainen  a écrit :

>
> The gap between alpha and beta was longer than usual because we were
> waiting for bug reports for the new sqlite backend from wider exposure
> in Fedora. After two months, we figured we can't wait forever. Zero
> filed bugs is almost certainly too good to be entirely true, but it's a
> not a bad situation either.
>
> In the meanwhile, on top of the usual assorted fixes and minor
> enhancements, the highligh since the alpha is that rpm expressions
> gained native version comparison powers and new version parsing and
> comparison API was added to C and Python.
>
> Download info and the usual, including updated details and examples on
> the new expression capabilities of 4.16 at:
>
> https://rpm.org/wiki/Releases/4.16.0
>
> Enjoy!
>
> On behalf of rpm-team,
>
> - Panu -
>

Hi
/usr/share/man8/rpm-plugin-selinux.8 is installed even if selinux is
disabled (--without-selinux)…
See you
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 alpha released!

[Thierry Vignaud]

Le lun. 23 mars 2020 à 15:47, Panu Matilainen  a
écrit :

>
> On 3/23/20 3:22 PM, Panu Matilainen wrote:
> >
> > So soon you say? Well, its almost a year since 4.15 alpha and annual
> > release schedule isn't *that* fast. More like trying to get back on
> > track with this release stuff after some erratic years.
> >
> > Anyway, here goes. The two major themes here are: preparing to finally
> > kick Berkeley DB out, and (conditional) macro expressions. If you ever
> > thought %{?foo:bar} is too limited, this one is for you.
>
> So this is what I get for trying to cut a release on Monday: the
> originally linked rpm-4.15.90-git14970 snapshot has a buggy rpm.pc file
> which prevents using it for linking. Since an important aspect of alpha
> testing is testing other software... duh.
>
> Just pushed a new snapshot (rpm-4.15.90-git14971) to fix that and
> updated the download links + hashes, but if you were eager enough to
> have grabbed the first snapshot then you'll want to update.
>
> >
> > Highlights include:
> > - Powerful macro and %if expressions including ternary operator
> > - New sqlite and read-only BDB backends, NDB promoted to stable
> > - Automatic SSD detection and optimization on Linux
>
> Seems I also forgotten some highlights as well:
>
> - Support for dependency generation with parametric macros
> - Support for dependency generation based on MIME types
>
> The details and download info still at
>
> https://rpm.org/wiki/Releases/4.16.0
>
> Apologies for the confusion,
>

Another regression is in rpmbuild:
$ rpmbuild -ba ~/rpmbuild/SPECS/foobar.spec
error: line 5: Tag takes single token only: Release:%{mkrel 1}
This basically breaks building all of 13 000 packages in Mageia because all
of them use this:
Release: %mkrel 1

Which expands to a nicely formatted release number according to the distro
version (similar to %{dist} in Fedora).
Can you please rollback that change?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.16.0 alpha released!

[Thierry Vignaud]

Le mar. 7 avr. 2020 à 12:08, Thierry Vignaud  a
écrit :

> > So soon you say? Well, its almost a year since 4.15 alpha and annual
>
>> > release schedule isn't *that* fast. More like trying to get back on
>> > track with this release stuff after some erratic years.
>> >
>> > Anyway, here goes. The two major themes here are: preparing to finally
>> > kick Berkeley DB out, and (conditional) macro expressions. If you ever
>> > thought %{?foo:bar} is too limited, this one is for you.
>>
>> So this is what I get for trying to cut a release on Monday: the
>> originally linked rpm-4.15.90-git14970 snapshot has a buggy rpm.pc file
>> which prevents using it for linking. Since an important aspect of alpha
>> testing is testing other software... duh.
>>
>> Just pushed a new snapshot (rpm-4.15.90-git14971) to fix that and
>> updated the download links + hashes, but if you were eager enough to
>> have grabbed the first snapshot then you'll want to update.
>>
>> >
>> > Highlights include:
>> > - Powerful macro and %if expressions including ternary operator
>> > - New sqlite and read-only BDB backends, NDB promoted to stable
>> > - Automatic SSD detection and optimization on Linux
>>
>> Seems I also forgotten some highlights as well:
>>
>> - Support for dependency generation with parametric macros
>> - Support for dependency generation based on MIME types
>>
>> The details and download info still at
>>
>> https://rpm.org/wiki/Releases/4.16.0
>>
>
> I kept procrastining for 2 weeks but, as usual ( :-) ), there's a
> regression caught by urpmi's testsuite.
> The nice thing is that there's only one regression this time.
>
> t/superuser--srpm-bootstrapping.t fails:
>
> t/superuser--srpm-bootstrapping.t (Wstat: 1536
> Tests: 21 Failed: 6)
>   Failed tests:  4, 9-10, 14, 19-20
>   Non-zero exit status: 6
>
> The "interesting" part is that:
> 1) if I skip t/02create_pkgs.t (building rpms from test spec files) and
> keep the rpms generated with rpm-4.15.1, it passes
> 1) Similarly if I skip t/02create_pkgs.t and keep the rpms generated with
> rpm-4.16.0a, running the testsuite with rpm-4.15 fails
>
> I'ven't dig further, whether it's a bug in rpm or a change in rpm showing
> a bogus expectation in urpmi.
> And since I don't have much time, let's report the issue.
> At least, there's one change:
> $ rpmdiff
> ./media.4.15/SRPMS-srpm-bootstrapping/srpm-bootstrapping-1-1.src.rpm
> ./media.4.16/media/SRPMS-srpm-bootstrapping/srpm-bootstrapping-1-1.src.rpm
> added   PROVIDES srpm-bootstrapping = 1-1
>
> (which is expected)
>

Eventually, it's that new provides that makes URPM resolver to derail…
It's a 2 lines changes in URPM::Resolve
This is because of"Add NEVR provides for all packages that would be built
into source rpms"
commit 75ec16e660e784d7897b37cac1a2b9b135825f25

This broke expectations in URPM/urpmi when processing SRPMs…
From baf3fa111904e59a6b46e8e32e31234ddd161cb6 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Tue, 7 Apr 2020 16:12:01 +0200
Subject: [PATCH] workaround rpm-4.16 adding provides to SRPMs

rationale:
rpm-4.16 adds provides for all generated RPMS to SRPMs, which breaks
urpmi's testsuite (t/superuser--srpm-bootstrapping.t)

See rpm's commit 75ec16e660e784d7897b37cac1a2b9b135825f25
---
 URPM/Resolve.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/URPM/Resolve.pm b/URPM/Resolve.pm
index 33504b5..c799dff 100644
--- a/URPM/Resolve.pm
+++ b/URPM/Resolve.pm
@@ -641,11 +641,12 @@ sub unsatisfied_requires {
 	#- check on the selected package if a provide is satisfying the resolution (need to do the ops).
 	foreach (grep { exists $state->{selected}{$_} } keys %{$urpm->{provides}{$n} || {}}) {
 		my $p = $urpm->{depslist}[$_];
+		next if $p->arch eq 'src'; # ignore provides from SRPM (new in rpm-4.16)
 		!$urpm->{provides}{$n}{$_} || $p->provides_overlap($prop) and next REQUIRES;
 	}
 
 	#- check if the package itself provides what is necessary.
-	$pkg->provides_overlap($prop) and next REQUIRES;
+	$pkg->arch ne 'src' and $pkg->provides_overlap($prop) and next REQUIRES;
 
 	#- check on installed system if a package which is not obsoleted is satisfying the require.
 	my $satisfied = 0;
-- 
2.26.0

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

Re: [Rpm-maint] RPM 4.16.0 alpha released!

[Thierry Vignaud]

Le lun. 23 mars 2020 à 15:47, Panu Matilainen  a
écrit :

>
> On 3/23/20 3:22 PM, Panu Matilainen wrote:
> >
> > So soon you say? Well, its almost a year since 4.15 alpha and annual
> > release schedule isn't *that* fast. More like trying to get back on
> > track with this release stuff after some erratic years.
> >
> > Anyway, here goes. The two major themes here are: preparing to finally
> > kick Berkeley DB out, and (conditional) macro expressions. If you ever
> > thought %{?foo:bar} is too limited, this one is for you.
>
> So this is what I get for trying to cut a release on Monday: the
> originally linked rpm-4.15.90-git14970 snapshot has a buggy rpm.pc file
> which prevents using it for linking. Since an important aspect of alpha
> testing is testing other software... duh.
>
> Just pushed a new snapshot (rpm-4.15.90-git14971) to fix that and
> updated the download links + hashes, but if you were eager enough to
> have grabbed the first snapshot then you'll want to update.
>
> >
> > Highlights include:
> > - Powerful macro and %if expressions including ternary operator
> > - New sqlite and read-only BDB backends, NDB promoted to stable
> > - Automatic SSD detection and optimization on Linux
>
> Seems I also forgotten some highlights as well:
>
> - Support for dependency generation with parametric macros
> - Support for dependency generation based on MIME types
>
> The details and download info still at
>
> https://rpm.org/wiki/Releases/4.16.0
>

I kept procrastining for 2 weeks but, as usual ( :-) ), there's a
regression caught by urpmi's testsuite.
The nice thing is that there's only one regression this time.

t/superuser--srpm-bootstrapping.t fails:

t/superuser--srpm-bootstrapping.t (Wstat: 1536
Tests: 21 Failed: 6)
  Failed tests:  4, 9-10, 14, 19-20
  Non-zero exit status: 6

The "interesting" part is that:
1) if I skip t/02create_pkgs.t (building rpms from test spec files) and
keep the rpms generated with rpm-4.15.1, it passes
1) Similarly if I skip t/02create_pkgs.t and keep the rpms generated with
rpm-4.16.0a, running the testsuite with rpm-4.15 fails

I'ven't dig further, whether it's a bug in rpm or a change in rpm showing a
bogus expectation in urpmi.
And since I don't have much time, let's report the issue.
At least, there's one change:
$ rpmdiff
./media.4.15/SRPMS-srpm-bootstrapping/srpm-bootstrapping-1-1.src.rpm
./media.4.16/media/SRPMS-srpm-bootstrapping/srpm-bootstrapping-1-1.src.rpm
added   PROVIDES srpm-bootstrapping = 1-1

(which is expected)

Does it ring a bell?

I've attached the log diff when uncommenting the following in t/helper.pm &
adding a cople debug prints:
#$urpmi_debug_opt = '-v --debug';

urpmi can be fetched from CPAN, using the cpan command:
https://metacpan.org/release/urpmi

Deps (listed at
https://explorer.metacpan.org/?url=/release/TVIGNAUD/urpmi-v8.120.12):
dnf install perl-Test-Pod perl-Expect perl-File-Slurp perl-Net-Server
perl-Test-Pod-Coverage perl-Locale-gettext perl-XML-LibXML perl-Getopt-Long
perl-Filesys-Df
(Net::LDAP, XML::LibXML::Reader & Test::More being part of perl)
The other deps can also be fetched from cpan:
https://explorer.metacpan.org/?url=/release/TVIGNAUD/urpmi-v8.120.12
rpmtools, MDV-Distribconf & URPM:
https://metacpan.org/release/rpmtools
https://metacpan.org/release/URPM
https://metacpan.org/release/MDV-Distribconf
https://metacpan.org/release/Time-ZoneInfo

Just run "perl Makefile.PL && make && sudo make install" if you're not
fluent in cpan
And "make test" of course
--- ../ULOG.14-rpm4.16-4with-4.15-rpms	2020-04-02 12:08:28.787115922 +0200
+++ ../ULOG.14-rpm4.16-4with-4.16-rpms	2020-04-02 12:13:50.344204513 +0200
@@ -11915,35 +11959,34 @@
 >> K0 (media/SRPMS-srpm-bootstrapping/srpm-bootstrapping-*.src.rpm)
 found synthesis: /home/tv/mga/git/mga/urpmi/t/media/srpm-bootstrapping/media_info/synthesis.hdlist.cz
 update_medium: 1=1
-EXITING (pid=13494)
+EXITING (pid=29073)
 >> I.1 (--buildrequires --auto media/SRPMS-srpm-bootstrapping/srpm-bootstrapping-*.src.rpm)
 opening rpmdb (root=/home/tv/mga/git/mga/urpmi/t/root, write=)
 selecting srpm-bootstrapping-1-1.src
-requiring srpm-bootstrapping for srpm-bootstrapping-1-1.src
-selecting srpm-bootstrapping-1-1.x86_64
 srpm-bootstrapping is not in potential orphans
 opening rpmdb (root=/home/tv/mga/git/mga/urpmi/t/root, write=)
 getting graph of dependencies for sorting
 sorting graph of dependencies
 rpms sorted by dependencies:
 srpm-bootstrapping
-srpm-bootstrapping
 selecting srpm-bootstrapping-1-1.src
-requiring srpm-bootstrapping for srpm-bootstrapping-1-1.src
-selecting srpm-bootstrapping-1-1.x86_64
-transaction valid: remove= update=srpm-bootstrapping,srpm-bootstrapping
+transaction valid: remove= update=srpm-bootstrapping
 scheduled sets of transactions:
-remove=0= update=2=srpm-bootstrapping,srpm-bootstrapping
+remove=0= update=1=srpm-bootstrapping
 verifying signature of media/SRPMS-srpm-bootstrapping/srpm-bootstrapping-1-1.src.rpm
-verifying 

[Rpm-maint] [PATCH] fix zstd magic

[Thierry Vignaud]

Hi
The attached patch fixes the zstd magic bytes detection.

I spot it while adding support for zstd compressed metadata in
URPM/urpmi, which was broken by this typo…

Thanks
(done against 4.15.x but should apply cleany to master)
From fa42be542cfabe953c461a52d9100d1ad28354b8 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Mon, 23 Dec 2019 16:51:49 +0100
Subject: [PATCH] fix zstd magic

I spot it while adding support for zstd compressed metadata in
URPM/urpmi, which was broken by this typo

typo introduced in commit 3684424fe297c996bb05bb64631336fa2903df12
---
 rpmio/rpmfileutil.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rpmio/rpmfileutil.c b/rpmio/rpmfileutil.c
index bda97adf1..84ee34f4d 100644
--- a/rpmio/rpmfileutil.c
+++ b/rpmio/rpmfileutil.c
@@ -188,7 +188,7 @@ int rpmFileIsCompressed(const char * file, rpmCompressedMagic * compressed)
 	   (magic[4] == 0x5a) && (magic[5] == 0x00)) {
 	/* new style xz (lzma) with magic */
 	*compressed = COMPRESSED_XZ;
-} else if ((magic[0] == 0x28) && (magic[1] == 0x85) &&
+} else if ((magic[0] == 0x28) && (magic[1] == 0xB5) &&
 	   (magic[2] == 0x2f) ) {
 	*compressed = COMPRESSED_ZSTD;
 } else if ((magic[0] == 'L') && (magic[1] == 'Z') &&
-- 
2.24.1

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

Re: [Rpm-maint] [Rpm-announce] RPM 4.15.0 rc1 released!

[Thierry Vignaud]

Le sam. 31 août 2019 à 13:00, Thierry Vignaud  a
écrit :

> A wee bit late from the original schedule but at least in the same month
>
>> still, here comes the first and hopefully last release candidate for
>> 4.15.0.
>>
>> The main highlights since beta are:
>> - Fixed out of order build output
>> - Fixed memory exhaustion during build on 32bit platforms
>> - Added %{expr:...} macro for evaluating expressions (into strings)
>> - Assorted other bug fixes
>>
>> As usual, details and download info at:
>>
>>  https://rpm.org/wiki/Releases/4.15.0
>>
>> Unless some major drama comes up, I expect this to become the final
>> release in a couple of weeks.
>> <http://lists.rpm.org/mailman/listinfo/rpm-announce>
>
>
> There's an issue with the python bindings: with the new "rpmdsIsReverse":
>
> $ python3
> (...)
> >>> import rpm
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib64/python3.7/site-packages/rpm/__init__.py", line 38, in
> 
> from rpm._rpm import *
> ImportError: /usr/lib64/python3.7/site-packages/rpm/_
> rpm.cpython-37m-x86_64-linux-gnu.so: undefined symbol: rpmdsIsReverse
>

Interestingly, I noted that python[23]-rpm-4.15.0-0.rc1 were linked against
librpm*.so.8 instead of .9.
Rebuilding rpm-4.15 against itself fixes it (aka upgrading first the system
rpm to 4.15 before building rpm again).
So the real issue is that the python modules link against system librpm*
instead of the just built librpm*
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.15.0 rc1 released!

[Thierry Vignaud]

Le mer. 28 août 2019 à 12:28, Panu Matilainen  a
écrit :

> A wee bit late from the original schedule but at least in the same month
> still, here comes the first and hopefully last release candidate for
> 4.15.0.
>
> The main highlights since beta are:
> - Fixed out of order build output
> - Fixed memory exhaustion during build on 32bit platforms
> - Added %{expr:...} macro for evaluating expressions (into strings)
> - Assorted other bug fixes
>
> As usual, details and download info at:
>
>  https://rpm.org/wiki/Releases/4.15.0
>
> Unless some major drama comes up, I expect this to become the final
> release in a couple of weeks.
> 


There's an issue with the python bindings: with the new "rpmdsIsReverse":

$ python3
(...)
>>> import rpm
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.7/site-packages/rpm/__init__.py", line 38, in

from rpm._rpm import *
ImportError: /usr/lib64/python3.7/site-packages/rpm/_
rpm.cpython-37m-x86_64-linux-gnu.so: undefined symbol: rpmdsIsReverse
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] document %__NAME_namespace added in 2011

[Thierry Vignaud]

ping?
Le lun. 10 sept. 2018 à 08:16, Thierry Vignaud
 a écrit :
>
> Hi
> This patch  documents the %__NAME_namespace added in 2011 on the website.
> See you
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Thierry Vignaud]

Le mer. 12 sept. 2018 à 19:15, Neal Gompa  a écrit :
> > >> In Mageia, we eg had:
> > >> 1) manual "requires(post)" or "requires(posttrans): info-install"
> > >> (info-install being the package containing /sbin/ /sbin/install-info
> > >> 2) plus manual %post or %posttrans calling install-info
> > >>
> > >> This was a manual process, so it was sometimes missed in some pkgs.
> > >
> > >
> > > That's why Fedora switched to transfiletrigger. It is much better ;)
> >
> > But we still need the pkgs container the info files to require the
> > needed /sbin/info-install
> >
> > >> We've replaced those manual requires+scriptlets by a filetrigger.
> > >> But we still want info-install to be installed, so in order to replace
> > >> the manual requires, we want to automatically emit the requires on
> > >> info-install
> > >> But we don't want to emit "requires: info-install",
> > >> what we want really is "requires(posttrans): info-install"
> > >>
> > >> The patch enables to emit requires for scriptlets or filetriggers.
> > >
> > >
> > > This is too specific use case I think..
> >
> > That's an example but there could be more
>
> I think the idea usually is that the file trigger would not fire if
> the package isn't installed, so forcing a dependency here means that
> there was no benefit to separating it out to be run only when it was
> needed. It basically makes it impossible to avoid running the trigger.

Which is exactly the point here:
Again, here the policy was for all those pkgs to require info-install
& run it in %post or %posttrans
In order to ease packager work, we replaced this manual work by using
a filetrigger.
But we stil want info-isntall to be installed, hence this patch

> In the case of info, there's no point in running the info commands if
> info itself is not installed. You can't use them anyway. :)

Again, info-install was manually required before, we just want to automate that.

> That said, there may be a case where we might want this, so I'm not
> completely ruling out its relevance.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Thierry Vignaud]

Le mer. 12 sept. 2018 à 14:30, Igor Gnatenko
 a écrit :
>> In Mageia, we eg had:
>> 1) manual "requires(post)" or "requires(posttrans): info-install"
>> (info-install being the package containing /sbin/ /sbin/install-info
>> 2) plus manual %post or %posttrans calling install-info
>>
>> This was a manual process, so it was sometimes missed in some pkgs.
>
>
> That's why Fedora switched to transfiletrigger. It is much better ;)

But we still need the pkgs container the info files to require the
needed /sbin/info-install

>> We've replaced those manual requires+scriptlets by a filetrigger.
>> But we still want info-install to be installed, so in order to replace
>> the manual requires, we want to automatically emit the requires on
>> info-install
>> But we don't want to emit "requires: info-install",
>> what we want really is "requires(posttrans): info-install"
>>
>> The patch enables to emit requires for scriptlets or filetriggers.
>
>
> This is too specific use case I think..

That's an example but there could be more
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Thierry Vignaud]

In Mageia, we eg had:
1) manual "requires(post)" or "requires(posttrans): info-install"
(info-install being the package containing /sbin/ /sbin/install-info
2) plus manual %post or %posttrans calling install-info

This was a manual process, so it was sometimes missed in some pkgs.

We've replaced those manual requires+scriptlets by a filetrigger.
But we still want info-install to be installed, so in order to replace
the manual requires, we want to automatically emit the requires on
info-install
But we don't want to emit "requires: info-install",
what we want really is "requires(posttrans): info-install"

The patch enables to emit requires for scriptlets or filetriggers.
See you

Le mer. 12 sept. 2018 à 10:34, Igor Gnatenko
 a écrit :
>
> What is the point of this? I just don't get the use-case..
>
> On Wed, Sep 12, 2018 at 10:32 AM Thierry Vignaud  
> wrote:
>>
>> Le sam. 8 sept. 2018 à 09:10, Thierry Vignaud
>>  a écrit :
>> >
>> > Hi
>> >
>> > The attached patch adds support for scriptlet deps in generated deps.
>> > Eg on Mageia, there's a file trigger for automatically
>> > installing/removing info pages from /usr/share/info index
>> >
>> > Having manual or auto generated "Requires: ..." mean some strong
>> > deploops in base packages which rpmlib can break at random places,
>> > sometimes borking scriptlets.
>> >
>> > What we want in such a case is "Requires(posttrans): ..;" as
>> > filetriggers will be run late anyway.
>> >
>> > This patch enables to do that (but only in internal deps generators)
>> >
>> > Example:
>> > %__info_requires%{_rpmconfigdir}/mageia/info-file.req
>> > %__info_scriptlet   posttrans
>> > %__info_path^%{_datadir}/info/.*\\.info.*$
>> >
>> > See you
>>
>> Can you consider this one for inclusion?
>> ___
>> Rpm-maint mailing list
>> Rpm-maint@lists.rpm.org
>> http://lists.rpm.org/mailman/listinfo/rpm-maint
>
> --
>
> -Igor Gnatenko
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Thierry Vignaud]

Le sam. 8 sept. 2018 à 09:10, Thierry Vignaud
 a écrit :
>
> Hi
>
> The attached patch adds support for scriptlet deps in generated deps.
> Eg on Mageia, there's a file trigger for automatically
> installing/removing info pages from /usr/share/info index
>
> Having manual or auto generated "Requires: ..." mean some strong
> deploops in base packages which rpmlib can break at random places,
> sometimes borking scriptlets.
>
> What we want in such a case is "Requires(posttrans): ..;" as
> filetriggers will be run late anyway.
>
> This patch enables to do that (but only in internal deps generators)
>
> Example:
> %__info_requires%{_rpmconfigdir}/mageia/info-file.req
> %__info_scriptlet   posttrans
> %__info_path^%{_datadir}/info/.*\\.info.*$
>
> See you

Can you consider this one for inclusion?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] document %__NAME_namespace added in 2011

[Thierry Vignaud]

Hi
This patch  documents the %__NAME_namespace added in 2011 on the website.
See you
From 87a129401c77dfe21e1da480459c3c199f606da7 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Mon, 10 Sep 2018 08:07:17 +0200
Subject: [PATCH] document %__NAME_namespace added in 2011

---
 user_doc/dependency_generators.md | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/user_doc/dependency_generators.md b/user_doc/dependency_generators.md
index f1496ec..1bf1ccc 100644
--- a/user_doc/dependency_generators.md
+++ b/user_doc/dependency_generators.md
@@ -29,6 +29,7 @@ A file attribute is represented by a macro file in %{_fileattrsdir} (typically /
 %__NAME_exclude_path
 %__NAME_exclude_magic
 %__NAME_exclude_flags
+%__NAME_namespace
 ```
 
 NAME needs to be replaced by the name choosen for the file attribute and needs to be the same as the file name of the macro file itself (without the .attr suffix). While technically all of them are optional, typically two or more of them are present to form a meaningul attribute. All the values are further macro-expanded on use, and additionally the path and magic related values are interpreted as extended regular expressions.
@@ -39,6 +40,12 @@ Flags are a comma-separated lists, as of rpm 4.9.1 the supported flags are:
 * exeonly - require executable bit set
 * magic_and_path - require both magic and pattern to match 
 
+Namespace enables to automatically wrapping generated dependencies into
+macro-expanded namespaces, eg "foo(depname)" by specifying __attr_namespace in
+the file attribute definition.
+Thus it's not needed to hardcode the namspace in the generator scripts and
+frees generators from having to take care of the formatting.
+
 ## Generators
 A generator is just an executable that reads file name(s) from stdin and writes out Provides: or Requires: on stdout. This way the generator can be implemented in whatever language is preferred and can use e.g. language specific libraries or tools. Generators get called once for each file with matching attributes. Generators can be declare in the file attributes file by defining the following macros:
 
-- 
2.18.0

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

[Rpm-maint] [PATCH] add support for scriptlet deps in generated deps

[Thierry Vignaud]

Hi

The attached patch adds support for scriptlet deps in generated deps.
Eg on Mageia, there's a file trigger for automatically
installing/removing info pages from /usr/share/info index

Having manual or auto generated "Requires: ..." mean some strong
deploops in base packages which rpmlib can break at random places,
sometimes borking scriptlets.

What we want in such a case is "Requires(posttrans): ..;" as
filetriggers will be run late anyway.

This patch enables to do that (but only in internal deps generators)

Example:
%__info_requires%{_rpmconfigdir}/mageia/info-file.req
%__info_scriptlet   posttrans
%__info_path^%{_datadir}/info/.*\\.info.*$

See you
From c70b34df68cedc93c2a77fd92ceed3e78cc06651 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Sat, 8 Sep 2018 08:30:45 +0200
Subject: [PATCH] add support for scriptlet deps in generated deps

only in internal deps generators
---
 build/rpmfc.c | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/build/rpmfc.c b/build/rpmfc.c
index 2fbfc69ab..9fb7945e5 100644
--- a/build/rpmfc.c
+++ b/build/rpmfc.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -504,6 +505,7 @@ static ARGV_t runCmd(const char *nsdep, const char *depname,
 struct addReqProvDataFc {
 rpmfc fc;
 const char *namespace;
+const char *scriptlet;
 regex_t *exclude;
 };
 
@@ -524,6 +526,61 @@ static rpmRC addReqProvFc(void *cbdata, rpmTagVal tagN,
 return RPMRC_OK;
 }
 
+// Stolen from build/parsePreamble.c
+typedef const struct tokenBits_s {
+const char * name;
+rpmsenseFlags bits;
+} * tokenBits;
+
+static struct tokenBits_s const installScriptBits[] = {
+{ "interp", RPMSENSE_INTERP },
+{ "preun",  RPMSENSE_SCRIPT_PREUN },
+{ "pre",RPMSENSE_SCRIPT_PRE },
+{ "postun", RPMSENSE_SCRIPT_POSTUN },
+{ "post",   RPMSENSE_SCRIPT_POST },
+//{ "rpmlib", RPMSENSE_RPMLIB },
+{ "verify", RPMSENSE_SCRIPT_VERIFY },
+{ "pretrans",   RPMSENSE_PRETRANS },
+{ "posttrans",  RPMSENSE_POSTTRANS },
+{ NULL, 0 }
+};
+
+static int parseBits(const char * s, const tokenBits tokbits,
+rpmsenseFlags * bp)
+{
+tokenBits tb;
+const char * se;
+rpmsenseFlags bits = RPMSENSE_ANY;
+int c = 0;
+int rc = RPMRC_OK;
+
+if (s) {
+while (*s != '\0') {
+while ((c = *s) && risspace(c)) s++;
+se = s;
+while ((c = *se) && risalpha(c)) se++;
+if (s == se)
+break;
+for (tb = tokbits; tb->name; tb++) {
+if (tb->name != NULL &&
+strlen(tb->name) == (se-s) && rstreqn(tb->name, s, (se-s)))
+break;
+}
+if (tb->name == NULL) {
+rc = RPMRC_FAIL;
+break;
+}
+bits |= tb->bits;
+while ((c = *se) && risspace(c)) se++;
+if (c != ',')
+break;
+s = ++se;
+}
+}
+*bp |= bits;
+return rc;
+}
+
 /**
  * Run per-interpreter dependency helper.
  * @param fc		file classifier
@@ -541,6 +598,7 @@ static int rpmfcHelper(rpmfc fc, int ix,
 ARGV_t pav = NULL;
 const char * fn = fc->fn[ix];
 char *namespace = NULL;
+char *scriptlet = NULL;
 int pac;
 int rc = 0;
 regex_t *exclude = NULL;
@@ -563,11 +621,19 @@ static int rpmfcHelper(rpmfc fc, int ix,
 pac = argvCount(pav);
 namespace = rpmfcAttrMacro(nsdep, "namespace", NULL);
 exclude = rpmfcAttrReg(depname, "exclude", NULL);
+scriptlet = rpmfcAttrMacro(nsdep, "scriptlet", NULL);
+rpmsenseFlags tagflags = RPMSENSE_ANY;
+if (scriptlet && parseBits(scriptlet, installScriptBits, )) {
+rpmlog(RPMLOG_ERR, _("Bad scriptlet: %s\n"), scriptlet);
+goto exit;
+}
+dsContext |= tagflags;
 
 struct addReqProvDataFc data;
 data.fc = fc;
 data.namespace = namespace;
 data.exclude = exclude;
+data.scriptlet = scriptlet;
 
 for (int i = 0; i < pac; i++) {
 	if (parseRCPOT(NULL, fc->pkg, pav[i], tagN, ix, dsContext, addReqProvFc, ))
@@ -577,6 +643,7 @@ static int rpmfcHelper(rpmfc fc, int ix,
 argvFree(pav);
 regFree(exclude);
 free(namespace);
+free(scriptlet);
 
 exit:
 regFree(exclude_from);
-- 
2.18.0

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

[Rpm-maint] [PATCH] add -C/O aliases for conflicts/obsoletes

[Thierry Vignaud]

Hi
The attached patch adds  -C/O aliases for --conflicts/obsoletes
Mirroring the -P/R aliases we've for provides/requires

Thx
From b5cb6a1526e07e4eb8eb943c41fba5536ae25521 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Thu, 14 Jun 2018 00:43:25 +0200
Subject: [PATCH] add -C/O aliases for conflicts/obsoletes

like we've -P/R for provides/requires
---
 rpmpopt.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rpmpopt.in b/rpmpopt.in
index e4270fd8e..0213a53fe 100644
--- a/rpmpopt.in
+++ b/rpmpopt.in
@@ -67,9 +67,11 @@ rpm	alias --restore -q --qf \
 rpm	alias --conflicts	--qf \
   "[%|VERBOSE?{%{CONFLICTFLAGS:deptype}: }:{}|%{CONFLICTNEVRS}\n]" \
 	--POPTdesc=$"list capabilities this package conflicts with"
+rpm	alias -C --conflicts
 rpm	alias --obsoletes	--qf \
   "[%|VERBOSE?{%{OBSOLETEFLAGS:deptype}: }:{}|%{OBSOLETENEVRS}\n]" \
 	--POPTdesc=$"list other packages removed by installing this package"
+rpm	alias -O --obsoletes
 rpm	alias --provides	--qf \
   "[%|VERBOSE?{%{PROVIDEFLAGS:deptype}: }:{}|%{PROVIDENEVRS}\n]" \
 	--POPTdesc=$"list capabilities that this package provides"
-- 
2.17.1

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

[Rpm-maint] [PATCH] add support for --whatobsoletes

[Thierry Vignaud]

Hi
The attached patch adds support for --whatobsoletes
Mirroring the other --what* options, it's useful when debugging some
upgrade issues.

Tested on rpm-4.14.1, cherry-picked on top of master.
Thx
From f0ee48f525772b032eba92c7d6707e2482d9520a Mon Sep 17 00:00:00 2001
From: Thierry Vignaud 
Date: Mon, 11 Jun 2018 16:04:58 +0200
Subject: [PATCH] add support for --whatobsoletes

Mirroring the other --what* options, it's useful when debugging some
upgrade issues
---
 doc/rpm.8| 4 
 lib/poptQV.c | 4 
 lib/query.c  | 7 +++
 lib/rpmcli.h | 1 +
 4 files changed, 16 insertions(+)

diff --git a/doc/rpm.8 b/doc/rpm.8
index d8d6284c6..279e2ee2c 100644
--- a/doc/rpm.8
+++ b/doc/rpm.8
@@ -63,6 +63,7 @@ rpm \- RPM Package Manager
  [\fB--whatprovides \fICAPABILITY\fB\fR] [\fB--whatrequires \fICAPABILITY\fB\fR]
  [\fB--whatrecommends \fICAPABILITY\fB\fR] [\fB--whatsuggests \fICAPABILITY\fB\fR]
  [\fB--whatsupplements \fICAPABILITY\fB\fR] [\fB--whatenhances \fICAPABILITY\fB\fR]
+ [\fB--whatobsoletes \fICAPABILITY\fB\fR]
 
 .SS "query-options"
 .PP
@@ -622,6 +623,9 @@ a single transaction have a common identifier.
 Query packages that are triggered by package(s)
 \fIPACKAGE_NAME\fR.
 .TP
+\fB--whatobsoletes \fICAPABILITY\fB\fR
+Query all packages that obsolete \fICAPABILITY\fR for proper functioning.
+.TP
 \fB--whatprovides \fICAPABILITY\fB\fR
 Query all packages that provide the \fICAPABILITY\fR capability.
 .TP
diff --git a/lib/poptQV.c b/lib/poptQV.c
index 55ce7edb0..2822a3b3c 100644
--- a/lib/poptQV.c
+++ b/lib/poptQV.c
@@ -25,6 +25,7 @@ struct rpmQVKArguments_s rpmQVKArgs;
 #define POPT_WHATSUGGESTS	-1012
 #define POPT_WHATSUPPLEMENTS	-1013
 #define POPT_WHATENHANCES	-1014
+#define POPT_WHATOBSOLETES	-1015
 
 /* == Query/Verify/Signature source args */
 static void rpmQVSourceArgCallback( poptContext con,
@@ -48,6 +49,7 @@ static void rpmQVSourceArgCallback( poptContext con,
 case 'g': qva->qva_source |= RPMQV_GROUP; break;
 case 'p': qva->qva_source |= RPMQV_RPM; break;
 case POPT_WHATPROVIDES: qva->qva_source |= RPMQV_WHATPROVIDES; break;
+case POPT_WHATOBSOLETES: qva->qva_source |= RPMQV_WHATOBSOLETES; break;
 case POPT_WHATREQUIRES: qva->qva_source |= RPMQV_WHATREQUIRES; break;
 case POPT_WHATRECOMMENDS: qva->qva_source |= RPMQV_WHATRECOMMENDS; break;
 case POPT_WHATSUGGESTS: qva->qva_source |= RPMQV_WHATSUGGESTS; break;
@@ -99,6 +101,8 @@ struct poptOption rpmQVSourcePoptTable[] = {
 	N_("rpm verify mode"), NULL },
  { "whatrequires", '\0', 0, 0, POPT_WHATREQUIRES, 
 	N_("query/verify the package(s) which require a dependency"), "CAPABILITY" },
+ { "whatobsoletes", '\0', 0, 0, POPT_WHATOBSOLETES,
+	N_("query/verify the package(s) which obsolete a dependency"), "CAPABILITY" },
  { "whatprovides", '\0', 0, 0, POPT_WHATPROVIDES, 
 	N_("query/verify the package(s) which provide a dependency"), "CAPABILITY" },
  { "whatrecommends", '\0', 0, 0, POPT_WHATRECOMMENDS,
diff --git a/lib/query.c b/lib/query.c
index e07a3b2db..0f2e67483 100644
--- a/lib/query.c
+++ b/lib/query.c
@@ -373,6 +373,13 @@ static rpmdbMatchIterator initQueryIterator(QVA_t qva, rpmts ts, const char * ar
 	}
 }	break;
 
+case RPMQV_WHATOBSOLETES:
+	mi = rpmtsInitIterator(ts, RPMDBI_OBSOLETENAME, arg, 0);
+	if (mi == NULL) {
+	rpmlog(RPMLOG_NOTICE, _("no package obsolete %s\n"), arg);
+	}
+	break;
+
 case RPMQV_WHATREQUIRES:
 	mi = rpmtsInitIterator(ts, RPMDBI_REQUIRENAME, arg, 0);
 	if (mi == NULL) {
diff --git a/lib/rpmcli.h b/lib/rpmcli.h
index 662eb29ff..f1eeb7c45 100644
--- a/lib/rpmcli.h
+++ b/lib/rpmcli.h
@@ -99,6 +99,7 @@ enum rpmQVSources_e {
 RPMQV_WHATSUPPLEMENTS,	/*!< ... from supplements db search. */
 RPMQV_WHATENHANCES,		/*!< ... from enhances db search. */
 RPMQV_SPECBUILTRPMS,	/*!< ... from pkgs which would be built from spec */
+RPMQV_WHATOBSOLETES,	/*!< ... from obsoletes db search. */
 };
 
 typedef rpmFlags rpmQVSources;
-- 
2.17.1

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

Re: [Rpm-maint] [PATCH] Mark build-id and dwz entries in packages as %artifact files

[Thierry Vignaud]

On 8 November 2017 at 10:27, Panu Matilainen  wrote:
> In worst-case scenarios (packages with lots of binaries but little
> else), the build-id entries can dominate the query output to the
> point its hard to see the actual content. Marking these things as
> %artifact entries (artificial by-products of our processing) allows
> them to be easily filtered out from queries, eg:
>
>   $ rpm -qpl can-utils-20170830git-1.fc27.x86_64.rpm | wc -l
>   76
>   $ rpm -qpl --noartifact /can-utils-20170830git-1.fc27.x86_64.rpm | wc -l
>   28

I would not list them by default (aka --noartifact would be the default)

> Besides build-ids in the main package(s), this also marks the build-id
> and dwz-related entries in the debuginfo packages as %artifacts. The
> debuginfo files exist solely for carrying debuginfo data so its arguable
> whether these should be %artifacts in there too or only in the main
> packages, comments welcome...

I would say the should not be tagged as such
___
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 released!

[Thierry Vignaud]

On 12 October 2017 at 11:22, Panu Matilainen  wrote:
>
> In short, RPM 4.14.0 is out now. It's not quite what we originally had in
> mind - some things we planned for didn't make it, but perhaps more
> importantly, it's actually a whole lot MORE than we ever could've
> anticipated.
>
> Some highlights:
> - Major revamp of debuginfo packages
>   - Debuginfo packages are parallel installable
>   - Debuginfo can be split to subpackages and separate source package
>   - Debugedit supports string/line table rewriting
> - Major macro engine changes to sanitize and improve the "language"
>   - Parametric macro arguments are expanded and quotable
>   - Scoping is enforced for automatic macros
>   - Buggy "block level" scoping is gone, only macros defined inside
> parametric macros are considered local
> - Major rewrite of package/header reading and signature checking to
>   utilize a single codepath
> - Support for with/without/unless rich dependencies
> - A configurable mode to conserve SSD disks
> - Experimental LMDB database backend
>
> ...and I'm sure I missed several things worth being on that list, because
> there's an absolutely *huge* amount of enhancements and fixes all over the
> place, from over 20 contributors. For details and download information, head
> over to
>
> http://rpm.org/wiki/Releases/4.14.0


Hi
Can you create the proper tag in the rpm-4.14.x branch?
(or push it if it already exists on your machine)
Thanks
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault

[Thierry Vignaud]

On 5 October 2017 at 13:27, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
>>>>>>>>> Yeah, I'm getting segfaults all the way to rpm 4.11.x, didn't test
>>>>>>>>> earlier because this already shows it's not a regression in 4.14.x
>>>>>>>>> but
>>>>>>>>> something else. A bug in perl-RPM4 perhaps, as compiling it with -Og
>>>>>>>>> makes
>>>>>>>>> the crash go away, other optimization levels make it blow up with
>>>>>>>>> different
>>>>>>>>> levels of spectacular. I dont see anything obvious in there but that
>>>>>>>>> doesn't
>>>>>>>>> mean much, I know diddly about perl and its extensions.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I ran it with some added debugging on rpm side which I'm more
>>>>>>>> familiar
>>>>>>>> with, and the crash happens because a totally garbage pointer is
>>>>>>>> passed
>>>>>>>> to
>>>>>>>> headerFree(). Well indeed, it was passing the address of the header
>>>>>>>> pointer
>>>>>>>> variable as the header itself into the callback, and when you try do
>>>>>>>> stuff
>>>>>>>> with that, well...
>>>>>>>>
>>>>>>>> This fixes it:
>>>>>>>>
>>>>>>>> diff --git a/src/RPM4.xs b/src/RPM4.xs
>>>>>>>> index 04c65ee..6604477 100644
>>>>>>>> --- a/src/RPM4.xs
>>>>>>>> +++ b/src/RPM4.xs
>>>>>>>> @@ -246,7 +246,7 @@ static void *
>>>>>>>> s_what = "INST_START";
>>>>>>>> if (h) {
>>>>>>>> mXPUSHs(newSVpv("header", 0));
>>>>>>>> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>>>>>>> ));
>>>>>>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>>>>>>> h));
>>>>>>>> #ifdef HDRPMMEM
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oh and you'll want to fix the debug printf too, even though it's
>>>>>>> obviously
>>>>>>> harmless (but then useless for debugging):
>>>>>>>
>>>>>>>> PRINTF_NEW(bless_header, , -1);
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ^^
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Blech, one of those days...
>>>>>>
>>>>>> The above is closer to mark but still not quite right and will crash
>>>>>> too,
>>>>>> only in a different way because the refcount is wrong. Here's the real
>>>>>> deal:
>>>>>>
>>>>>> diff --git a/src/RPM4.xs b/src/RPM4.xs
>>>>>> index 04c65ee..f7cfd33 100644
>>>>>> --- a/src/RPM4.xs
>>>>>> +++ b/src/RPM4.xs
>>>>>> @@ -246,9 +246,9 @@ static void *
>>>>>>s_what = "INST_START";
>>>>>>if (h) {
>>>>>>mXPUSHs(newSVpv("header", 0));
>>>>>> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
>>>>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>>>>> headerLink(h)));
>>>>>>#ifdef HDRPMMEM
>>>>>> -PRINTF_NEW(bless_header, , -1);
>>>>>> +PRINTF_NEW(bless_header, h, -1);
>>>>>>#endif
>>>>>>}
>>>>>>break;
>>>>>>
>>>>>>   - Panu -
>>>>>>
>>>>>
>>>>> Thanks
>>>>> Now remains the issue with several builds on the same spec objec

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault

[Thierry Vignaud]

On 5 October 2017 at 12:03, Panu Matilainen  wrote:
 Yeah, I'm getting segfaults all the way to rpm 4.11.x, didn't test
 earlier because this already shows it's not a regression in 4.14.x
 but
 something else. A bug in perl-RPM4 perhaps, as compiling it with -Og
 makes
 the crash go away, other optimization levels make it blow up with
 different
 levels of spectacular. I dont see anything obvious in there but that
 doesn't
 mean much, I know diddly about perl and its extensions.
>>>
>>>
>>>
>>>
>>> I ran it with some added debugging on rpm side which I'm more
>>> familiar
>>> with, and the crash happens because a totally garbage pointer is
>>> passed
>>> to
>>> headerFree(). Well indeed, it was passing the address of the header
>>> pointer
>>> variable as the header itself into the callback, and when you try do
>>> stuff
>>> with that, well...
>>>
>>> This fixes it:
>>>
>>> diff --git a/src/RPM4.xs b/src/RPM4.xs
>>> index 04c65ee..6604477 100644
>>> --- a/src/RPM4.xs
>>> +++ b/src/RPM4.xs
>>> @@ -246,7 +246,7 @@ static void *
>>> s_what = "INST_START";
>>> if (h) {
>>> mXPUSHs(newSVpv("header", 0));
>>> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>> ));
>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>> h));
>>> #ifdef HDRPMMEM
>>
>>
>>
>>
>>
>> Oh and you'll want to fix the debug printf too, even though it's
>> obviously
>> harmless (but then useless for debugging):
>>
>>> PRINTF_NEW(bless_header, , -1);
>>
>>
>>
>> ^^
>
>
>
>
> Blech, one of those days...
>
> The above is closer to mark but still not quite right and will crash
> too,
> only in a different way because the refcount is wrong. Here's the real
> deal:
>
> diff --git a/src/RPM4.xs b/src/RPM4.xs
> index 04c65ee..f7cfd33 100644
> --- a/src/RPM4.xs
> +++ b/src/RPM4.xs
> @@ -246,9 +246,9 @@ static void *
>s_what = "INST_START";
>if (h) {
>mXPUSHs(newSVpv("header", 0));
> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
> headerLink(h)));
>#ifdef HDRPMMEM
> -PRINTF_NEW(bless_header, , -1);
> +PRINTF_NEW(bless_header, h, -1);
>#endif
>}
>break;
>
>   - Panu -
>

 Thanks
 Now remains the issue with several builds on the same spec object

>>>
>>> Yeah, I was just about to write about that.
>>>
>>> I totally misunderstood the case initially (that's what happens if you
>>> try
>>> to understand the world by peeking through a keyhole), I thought your
>>> testcase was looking at the number of files by itself and finding one
>>> more
>>> than expected. When the error actually comes from rpm itself.
>>
>>
>> Yeah we had a misunderstanding there :-)
>>
>>> That file entries get messed when reusing the same spec is probably an
>>> ages
>>> old issue, it's just that until now rpm didn't sanity check the file
>>> data.
>>>
>>> The right thing to do is to reload the spec, I doubt it ever *really*
>>> worked
>>> correctly.
>>
>>
>> OK I'll commit my fix in the VC then.
>> There's still one last testsuite failure with RPM4 when verifying a
>> rpmdb after rebuilding it :
>>
>> $ LC_ALL=C perl -Iblib/lib -Iblib/arch t/05transaction.t 2>&1|grep -A2
>> -B36 "not ok"
>> error: rpmdb: Enhancename: 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.
>>
>> The initdb creates the proper files, but after rebuilddb, there's only
>> "Packages" (+ the __db.000 env)
>> This used to work.
>> Any idea?
>>
>
> Yeah, see
> https://github.com/rpm-software-management/rpm/commit/b62d85d78b07d6d43ca26fd7cda489c636a5796b
> :)
>
> (and yes that'll be in 4.14.0 too)
>
> - Panu -

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

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault

[Thierry Vignaud]

On 5 October 2017 at 11:40, Panu Matilainen  wrote:
>> Yeah, I'm getting segfaults all the way to rpm 4.11.x, didn't test
>> earlier because this already shows it's not a regression in 4.14.x but
>> something else. A bug in perl-RPM4 perhaps, as compiling it with -Og
>> makes
>> the crash go away, other optimization levels make it blow up with
>> different
>> levels of spectacular. I dont see anything obvious in there but that
>> doesn't
>> mean much, I know diddly about perl and its extensions.
>
>
>
> I ran it with some added debugging on rpm side which I'm more familiar
> with, and the crash happens because a totally garbage pointer is passed
> to
> headerFree(). Well indeed, it was passing the address of the header
> pointer
> variable as the header itself into the callback, and when you try do
> stuff
> with that, well...
>
> This fixes it:
>
> diff --git a/src/RPM4.xs b/src/RPM4.xs
> index 04c65ee..6604477 100644
> --- a/src/RPM4.xs
> +++ b/src/RPM4.xs
> @@ -246,7 +246,7 @@ static void *
>s_what = "INST_START";
>if (h) {
>mXPUSHs(newSVpv("header", 0));
> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, h));
>#ifdef HDRPMMEM




 Oh and you'll want to fix the debug printf too, even though it's
 obviously
 harmless (but then useless for debugging):

>PRINTF_NEW(bless_header, , -1);


^^
>>>
>>>
>>>
>>> Blech, one of those days...
>>>
>>> The above is closer to mark but still not quite right and will crash too,
>>> only in a different way because the refcount is wrong. Here's the real
>>> deal:
>>>
>>> diff --git a/src/RPM4.xs b/src/RPM4.xs
>>> index 04c65ee..f7cfd33 100644
>>> --- a/src/RPM4.xs
>>> +++ b/src/RPM4.xs
>>> @@ -246,9 +246,9 @@ static void *
>>>   s_what = "INST_START";
>>>   if (h) {
>>>   mXPUSHs(newSVpv("header", 0));
>>> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>> headerLink(h)));
>>>   #ifdef HDRPMMEM
>>> -PRINTF_NEW(bless_header, , -1);
>>> +PRINTF_NEW(bless_header, h, -1);
>>>   #endif
>>>   }
>>>   break;
>>>
>>>  - Panu -
>>>
>>
>> Thanks
>> Now remains the issue with several builds on the same spec object
>>
>
> Yeah, I was just about to write about that.
>
> I totally misunderstood the case initially (that's what happens if you try
> to understand the world by peeking through a keyhole), I thought your
> testcase was looking at the number of files by itself and finding one more
> than expected. When the error actually comes from rpm itself.

Yeah we had a misunderstanding there :-)

> That file entries get messed when reusing the same spec is probably an ages
> old issue, it's just that until now rpm didn't sanity check the file data.
>
> The right thing to do is to reload the spec, I doubt it ever *really* worked
> correctly.

OK I'll commit my fix in the VC then.
There's still one last testsuite failure with RPM4 when verifying a
rpmdb after rebuilding it :

$ LC_ALL=C perl -Iblib/lib -Iblib/arch t/05transaction.t 2>&1|grep -A2
-B36 "not ok"
error: rpmdb: Enhancename: 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.

The initdb creates the proper files, but after rebuilddb, there's only
"Packages" (+ the __db.000 env)
This used to work.
Any idea?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault

[Thierry Vignaud]

On 5 October 2017 at 10:15, Panu Matilainen  wrote:
 Yeah, I'm getting segfaults all the way to rpm 4.11.x, didn't test
 earlier because this already shows it's not a regression in 4.14.x but
 something else. A bug in perl-RPM4 perhaps, as compiling it with -Og makes
 the crash go away, other optimization levels make it blow up with different
 levels of spectacular. I dont see anything obvious in there but that 
 doesn't
 mean much, I know diddly about perl and its extensions.
>>>
>>>
>>> I ran it with some added debugging on rpm side which I'm more familiar
>>> with, and the crash happens because a totally garbage pointer is passed to
>>> headerFree(). Well indeed, it was passing the address of the header pointer
>>> variable as the header itself into the callback, and when you try do stuff
>>> with that, well...
>>>
>>> This fixes it:
>>>
>>> diff --git a/src/RPM4.xs b/src/RPM4.xs
>>> index 04c65ee..6604477 100644
>>> --- a/src/RPM4.xs
>>> +++ b/src/RPM4.xs
>>> @@ -246,7 +246,7 @@ static void *
>>>   s_what = "INST_START";
>>>   if (h) {
>>>   mXPUSHs(newSVpv("header", 0));
>>> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, h));
>>>   #ifdef HDRPMMEM
>>
>>
>>
>> Oh and you'll want to fix the debug printf too, even though it's obviously
>> harmless (but then useless for debugging):
>>
>>>   PRINTF_NEW(bless_header, , -1);
>>
>>   ^^
>
>
> Blech, one of those days...
>
> The above is closer to mark but still not quite right and will crash too,
> only in a different way because the refcount is wrong. Here's the real deal:
>
> diff --git a/src/RPM4.xs b/src/RPM4.xs
> index 04c65ee..f7cfd33 100644
> --- a/src/RPM4.xs
> +++ b/src/RPM4.xs
> @@ -246,9 +246,9 @@ static void *
>  s_what = "INST_START";
>  if (h) {
>  mXPUSHs(newSVpv("header", 0));
> -mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header, ));
> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
> headerLink(h)));
>  #ifdef HDRPMMEM
> -PRINTF_NEW(bless_header, , -1);
> +PRINTF_NEW(bless_header, h, -1);
>  #endif
>  }
>  break;
>
> - Panu -
>

Thanks
Now remains the issue with several builds on the same spec object
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[Thierry Vignaud]

On 4 October 2017 at 17:59, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
>>>>>>>>> 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 d

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[Thierry Vignaud]

On 4 October 2017 at 14:17, Thierry Vignaud <thierry.vign...@gmail.com> 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 

Re: [Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[Thierry Vignaud]

On 4 October 2017 at 13:26, 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.
>>
>>
>> Intestingly, perl-RPM4 no more segfaults (there still faillures
>> though) if I alter the transrun() method (which calls rpmtsRun in
>> rpmlib) 's perl callback to *not* call std rpmShowProgress())
>> See attached patch
>>
>> Aka previously it runs both the passed perl callback + rpmlib default
>> callback which worked smoothly.
>> But since rpm-4.14, calling std rpm callback results a segfault...
>> I'm happy to not call that and I don't think we have any tool actually
>> running transactions^W installing packages through RPM4 right now but
>> still that's a regression in rpm...
>> Maybe some new unlink call or sg like that
>>
>
> Are you saying you still get that segfault with this fix?
> https://github.com/rpm-software-management/rpm/commit/082e6e77dd613efa643b02ee0417c1382f520893

That fix was for URPM segfaulting while verifying bad rpms, here I'm
talking about RPM4 segfaulting while installing packages
(different binding, different issue)
The URPM issue is fixed by the above commit (s/is/should/ - I hadn't
actually tested your fix)
The RPM4 issue is a different issue, even if both happen in headerFree() .
You might get confused by the perl gdb traces that looks similar but
the issues really are different.
They show the point 

[Rpm-maint] rpm4.14 makes perl-RPM4 testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[Thierry Vignaud]

On 3 October 2017 at 09:12, 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.

Intestingly, perl-RPM4 no more segfaults (there still faillures
though) if I alter the transrun() method (which calls rpmtsRun in
rpmlib) 's perl callback to *not* call std rpmShowProgress())
See attached patch

Aka previously it runs both the passed perl callback + rpmlib default
callback which worked smoothly.
But since rpm-4.14, calling std rpm callback results a segfault...
I'm happy to not call that and I don't think we have any tool actually
running transactions^W installing packages through RPM4 right now but
still that's a regression in rpm...
Maybe some new unlink call or sg like that
diff -up ./src/RPM4.xs.tv ./src/RPM4.xs
--- ./src/RPM4.xs.tv2017-10-03 20:26:06.787713414 +0200
+++ ./src/RPM4.xs   2017-10-03 20:23:09.328596076 +0200
@@ -292,6 +292,7 @@ static void *
 SPAGAIN;
   
 /* Running rpmlib callback, returning its value */
+return NULL;
 return rpmShowProgress(h,
 what, 
 amount, 
diff -up ./t/05transaction.t.tv ./t/05transaction.t
--- ./t/05transaction.t.tv  2017-10-03 19:56:01.565902942 +0200
+++ ./t/05transaction.t 2017-10-03 19:59:33.485538487 +0200
@@ -71,7 +71,11 @@ ok($ts->transcheck == 0, "Checking trans
 ok($ts->transorder == 0, "Run transaction order");
 
 ok(defined($ts->transflag([qw(JUSTDB)])), "Set transflags");
+warn ">> BEFORE SEGFAULT\n";
+#use MDK::Common 'backtrace';
+#*RPM4::Header::DESTROY = sub { warn ">> " . backtrace() };
 ok($ts->transrun(sub { my %a = @_; print STDERR "$a{what} $a{amount} 

Re: [Rpm-maint] rpm4.14 makes urpmi testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[Thierry Vignaud]

On 4 October 2017 at 09:41, 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. 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 slightly disagree. IMHO that's a rpm-4.14 regression in the case of
>> urpmi:
>> - header was used to be initialized by calling rpmReadPackageFile()
>> - this has worked for a decade
>> - this works smoothly if I replace the bogus pkgs by good ones
>> - header is no more initialized only for bogus packages, which is hit
>> by the testsuite
>>
>
> I was going to say it's relying on undocumented behavior, but something told
> me to check my facts before posting :) Turns out you're the one who's
> correct here:
>
> /** \ingroup header
>  * Return package header from file handle, verifying digests/signatures.
>  * @param tstransaction set
>  * @param fdfile handle
>  * @param fnfile name
>  * @retval hdrp address of header (or NULL)
>  * @return  RPMRC_OK on success
>  */
> rpmRC rpmReadPackageFile(rpmts ts, FD_t fd, const char * fn,
>  Header * hdrp);
>
> So it is actually documented behavior, and a ~15min empirical study shows
> that roughly half of the 3rd party API users from my sample actually rely on
> it.
>
>> Anyway I workarounded it with:
>>
>> http://gitweb.mageia.org/software/rpm/perl-URPM/commit/?id=87dbde4f3b078173e53cd45cac000c2d2751b370
>> But I still smell a bad regression in the way librpm treats bogus rpms.
>>
>
> It being documented makes it a no-brainer, but just the fact that so much
> third party software relies on it would've been enough to warrant
> reinstating the old behavior, especially since it's on the
> security-sensitive path, and no way to issue compiler warnings on the change
> either AFAICS.
>
> Fixed now in both git master and 4.14.x branch, thanks for reporting and
> persevering :)

Thx for fixing it :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] rpm4.14 makes urpmi testsuite to segfault (was: Re: [Rpm-announce] RPM 4.14.0 release candidate 2 is out)

[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. 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 slightly disagree. IMHO that's a rpm-4.14 regression in the case of urpmi:
- header was used to be initialized by calling rpmReadPackageFile()
- this has worked for a decade
- this works smoothly if I replace the bogus pkgs by good ones
- header is no more initialized only for bogus packages, which is hit
by the testsuite

Anyway I workarounded it with:
http://gitweb.mageia.org/software/rpm/perl-URPM/commit/?id=87dbde4f3b078173e53cd45cac000c2d2751b370
But I still smell a bad regression in the way librpm treats bogus rpms.
___
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

[Thierry Vignaud]

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

[Thierry Vignaud]

On 3 October 2017 at 08:00, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
> On 3 October 2017 at 07:34, Panu Matilainen <pmati...@redhat.com> 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

[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

[Thierry Vignaud]

On 2 October 2017 at 23:06, Thierry Vignaud <thierry.vign...@gmail.com> 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

[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

[Thierry Vignaud]

On 2 October 2017 at 15:50, Thierry Vignaud <thierry.vign...@gmail.com> 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

[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

[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

[Thierry Vignaud]

On 2 October 2017 at 12:34, Panu Matilainen <pmati...@redhat.com> wrote:
> On 10/02/2017 12:20 PM, Thierry Vignaud wrote:
>>
>> On 28 September 2017 at 16:06, Panu Matilainen <pmati...@redhat.com>
>> 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

[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

[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

Re: [Rpm-maint] [PATCH] debugedit: Support String/Line table rewriting for larger/smaller paths.

[Thierry Vignaud]

On 4 March 2017 at 10:28, Panu Matilainen  wrote:
>> From: Mark Wielaard 
>>
>> debugedit --base to --dest rewriting of debug source file paths only
>> supported dest paths that were smaller or equal than the base path
>> (and the size should differ more than 1 character for correct debug
>> lines).
>> All paths were changed "in place". Which could in theory mess up debug str
>> sharing.
>>
>> This rewrite supports base and dest strings of any size (some limitations,
>> see below). This is done by reconstructing the debug_str and debug_line
>> tables and updating the references in the debug_info attributes pointing
>> to these tables. Plus, if necessary (only for ET_REL kernel modules),
>> updating any relocations for the debug_info and debug_line sections.
>>
>> This has the nice benefit of merging any duplicate strings in the
>> debug_str table which might resulting on slightly smaller files.
>> kernel modules are ET_REL files that often contain a lot of duplicate
>> strings.
>>
>> The rewrite uses elfutils (either libebl or libdw) to reconstruct the
>> debug_str table. Since we are changing some section sizes now we cannot
>> just use mmap and rawdata to poke the values, but need to read in and
>> write out the changed sections. This does take a bit more memory because
>> we now also need to keep track of all string/line references.
>
>
> I dont feel qualified to really review this, and perhaps others are feeling
> the same way since it's been out there for a week now with no comments at
> all.
>
> Because this seems quite awesome (even if also a bit scary), to avoid
> stalling forever with no-one to review it: if there are no objections raised
> by Monday I'm going to just apply it (and the couple of other recent
> debuginfo patches). So anybody having doubts, speak up now.

If it does fix the infamous "Dest dir longer than base dir is not
supported", the merrier.
Though that didn't impact that much users in practice (but we did get
a report in mga a long time ago from one guy who set _topdir to
/RPM...).
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] lost doc on rpm.org

[Thierry Vignaud]

Hi
All of http://rpm.org/api/* content has disappeared
eg old links such as http://rpm.org/api/4.4.2.2/ldebug_8h.html result
in 404 not found

Also books, eg: http://rpm.org/max-rpm/index.html

Could you restore the doc contents?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0 rc2 released

[Thierry Vignaud]

On 21 October 2016 at 11:33, Panu Matilainen  wrote:
>>> Ah, I did run the test-suite but not from the created tarball. One more
>>> thing to remember when cutting releases. Or rather *cough* to document
>>> *cough*.
>>>
>>> Applied (with a slightly expanded comments).
>>
>>
>> If you could cherry-pick in rpm-4.13.x branch too, that would be nice :-)
>
>
> I will, eventually. Lets see what other things turn up first.
>
 After that, 2 unexpected failures remain:

  85: rpmbuild debuginfo dwz gnu_debuglink crcFAILED
 (rpmbuild.at:468)
>>>
>>>
>>>
>>> ...but this I had just missed. It appears to be cured by commit
>>> cherry-picking commit 3929ce4d58ab18c810b9a776f5c49d56cb436026.
>>
>>
>> This commit doen't exist in git
>> The attached patch fixes it anyway
>
>
> Sorry, should've been 41c4dcf507e2208585d6dc0952f59686a3a69d69, which commit
> 4ec7c396fb9464a3fcff006408871f8175ab169b apparently depends on.

That works fine as well.

 277: spec parse  FAILED
 (rpmpython.at:70)
>>>
>>>
>>>
>>> ...and this I'm not seeing at all. Please post
>>> tests/rpmtests.dir/277/rpmtests.log ... or does it happen to go away if you
>>> cherry-pick commit 3c74e34e8d8c5b3db024dbe04a352e807ed2b627 ?
>>
>>
>> That doesn't help.
>> I've attached the relevant logs plus a fix.
>>
>
> That's somewhat curious - why am I not seeing that? It suggests something
> outside the testing root is leaking into the tests and affecting things. The
> python tests would be more prone to that than the others since it doesn't
> occur inside the fakechroot of course...

Yeah but you didn't see "85: rpmbuild debuginfo dwz gnu_debuglink crc" too.

Might also be a different fakechroot version...
Nope, both are using 2.18.

Though Mageia has this rpm related patch:
http://svnweb.mageia.org/packages/cauldron/fakechroot/current/SOURCES/fakechroot-rpm-glob64.patch?revision=883248=markup
"Workaround for glob* vs rpm glob*

glob/glob64 is also defined by rpm in librpmio, which breaks fakechroot.
This patch tries to find which library is defining the symbol
(using dladdr, which is gnu specific) and if found, check if the symbol
comes from libc. If it's not from libc, call it directly."
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0 rc2 released

[Thierry Vignaud]

On 20 October 2016 at 15:32, Panu Matilainen <pmati...@redhat.com> wrote:
> After couple of weeks of headache from trying to sort this out somehow, here 
> comes 4.13.0 rc2.
>
> As explained earlier [1], in order to get the release train back on track, 
> pronto, this is mostly just a collection of backports that distros have 
> actually been running in the meanwhile rather than considering all the 
> commits in master by importance as I'd normally do. Plus a few patches based 
> on the feedback I got here. And some security fixes. Yeah, those. Some of 'em 
> have barely hatched and have little real world exposure, but can't be helped. 
> If we'll need rc3 then we'll have rc3, it's not the end of the world. Just 
> bleeping annoying. But on with the show.
>
> In this slot it normally says go to rpm.org release page for details but 
> rpm.org Trac is not letting me in. I'll be damned before I let that aging 
> s***box (soap! it says soap!) prevent me from doing this release and doing so 
> right now. So we'll do it the old-fashiened way then:
>
> The tarball is at http://rpm.org/releases/testing/rpm-4.13.0-rc2.tar.bz2
> and the SHA1SUM is 58dfe53cceb49d76315492d25efa8231b5fcf1fb.

(...)

> Please test and report any anomalies. From rc2 to final only regression fixes 
> will be allowed. Unless of course something really strange comes up, you 
> never know. Or I forgot something absolutely vital. THAT would not count as a 
> strange incident though.

Humm Testsuite won't pass
2 tests are failing because of missing files...
Please apply the attached patch
It fixes:
84: rpmbuild debuginfo dwz  FAILED (rpmbuild.at:396)
86: rpmbuild implicit suid binary   FAILED (rpmbuild.at:509)

After that, 2 unexpected failures remain:

 85: rpmbuild debuginfo dwz gnu_debuglink crcFAILED (rpmbuild.at:468)
277: spec parse  FAILED (rpmpython.at:70)

> [1] http://lists.rpm.org/pipermail/rpm-maint/2016-October/004595.html &
> http://lists.rpm.org/pipermail/rpm-maint/2016-October/004604.html
>
> P.S. We'll try to figure out what to do with rpm.org and its content in the 
> next few months, and things might be a bit muddy before they get better. Try 
> to bear with us.
>
> P.P.S. It's good to be back :)
From 5b17cd58f56c91d1cfbcb9d6366186992c3f0ad2 Mon Sep 17 00:00:00 2001
From: Thierry Vignaud <thierry.vign...@gmail.com>
Date: Fri, 21 Oct 2016 02:18:06 +0200
Subject: [PATCH] fix testsuite faillures: include missing files

---
 tests/Makefile.am | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 779b92f..7a5cc65 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -37,6 +37,8 @@ EXTRA_DIST += $(TESTSUITE_AT)
 EXTRA_DIST += data/SPECS/attrtest.spec
 EXTRA_DIST += data/SPECS/hello.spec
 EXTRA_DIST += data/SPECS/hello-script.spec
+EXTRA_DIST += data/SPECS/hello2.spec
+EXTRA_DIST += data/SPECS/hello2-suid.spec
 EXTRA_DIST += data/SPECS/foo.spec
 EXTRA_DIST += data/SPECS/globtest.spec
 EXTRA_DIST += data/SPECS/versiontest.spec
-- 
2.10.1

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

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Thierry Vignaud]

On 19 October 2016 at 12:35, Panu Matilainen  wrote:
>>> Anyway, the list above is not set in stone, otherwise there'd be little
>>> point in posting it here. If you think something absolutely critical is
>>> missing from that list, or that something should not be there, now is the
>>> time to speak up.
>>
>>
>> It would be nice to fix lib/rpmscript.c  so that filetriggers
>> warnings/errors would be reported as such instead of as regular (aka
>> package) triggers errors
>>
>> The issue is that rpmScriptNew() doesn't know the type of triggers
>> (package, file) and thus it doesn't store the right thing in script->desc
>>
>> Ie when findTag() is called, it doesn't know the type of triggers
>> (package, file), it just has enough info to know whether the script
>> comes from a trigger or from a regular scriptlet but file & pkg
>> triggers are threaded the same way because we don't have a
>> rpmscriptTriggerModes variable to consider
>> This makes harder to debug issues...
>>
>
> Please please people, would be nices have no place on this particular list.
> See this explanation for the kind of things that matter right now:
> http://lists.rpm.org/pipermail/rpm-maint/2016-October/004604.html
>
> The time for would be nices is after we get 4.13.0 out of the door. OTOH
> there too in order to backport something to 4.13.1 it'd need to be fixed in
> master first :)

I understand that but:
filetriggers is a new feature of 4.13.0 and it generate bogus error messages...
That should be fixed, maybe not in RC2, but in final release at least IMHO
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Thierry Vignaud]

On 14 October 2016 at 15:33, Panu Matilainen  wrote:
> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll need
> to cut -rc2 first, there's just too much change to jump right into final.
>
> The idea is to get -rc2 out next week (ie by Oct 21st at latest). If all
> goes well we'll just rename that to -final in a few weeks time, if all goes
> to hell we'll just have another -rc. Which I really, really dont want to
> happen. So what I've planned for -rc2 is this rather conservative
> cherry-picks from git master on top of the 4.13.x branch:
>
> d20b7d2 Fix rpmrichOpStr to use the new syntax
> 54f24ec Fix reading a memory right after the end of an allocated area.
> 7a84b45 Add support for various types of dependencies to rpmdeps tool
> 73ea59e fix %autopatch when patch do not exist
> 0d214a1 Permit scriptlet exec context setting to fail in non-enforcing modes
> f5bab7c Warn if epoch is not unsigned integer (rhbz:1251453)
> 5e94633 Make terminating build if version format is wrong configurable
> 90d8cc1 Ignore SIGPIPE signals during execucton of scriptlets (rhbz:1264198)
> 2dd0693 Fix SIGSEGV in case of old unsupported gpg keys (rhbz:1277464)
> 9c36ca4 Fix crash when parsing corrupted RPM file (rhbz:1273360)
> 1af568a Fix next_brace_sub() to return NULL if braces don't match.
> 61838b0 Remove size limit when expanding macros
> a0f2d94 Add possibility to disable file triggers.
> 5e4c16f Remove option --priority for file triggers, leave option -P
> aee8446 Rename expandMacrosU to rpmExpandMacros
> ddf9ec7 rpmExpandMacros() is modified to be able to return more return codes
> 8e847d5 Sanity check that there is at least one tag in header region
> 9aff39d Fix not chrooting transaction file triggers
> 8efe51e Add support for %missingok as a standalone file attribute
> 33158b3 Fix recursive calling of rpmdeps tool (rhbz:1297557)
> 231a721 Fix %autosetup to not cause errors during run of rpmspec tool
> 6e23e20 Fix memory leak in file triggers
> 448db68 Add RPMCALLBACK_ELEM_PROGRESS callback type
> 83219d0 Also block idle and sleep in the systemd-inhibit plugin
> cd02e06 Add support for MIPS release 6 - Add mips32 mips64 mipsel and mipseb
> macros
> 2166133 Use pkg->dpaths during dependency generation instead of buildRoot +
> filename
> d53499d Use %_build_cpu instead of noarch when evaluating ExcludeArch and
> ExclusiveArch
> cc61141 Fix memory leaks in rpmGetSubkeys() and pgpPrtParamsSubkeys()
> 19fe0d9 Add posix.redirect2null
> 877d5b1 Fix non-working combination of %lang and %doc directive
> (rhbz:1254483)
> 50905f4 Use fuzz settings for %autopatch/%autosetup
> dddc6e7 Misleading indentation fixes (GCC6)
> 4695533 Fix index generation of rich dependencies with an else part
> 9c1e995 Make creating index records consistent for rich and rich-weak deps
> e297b51 Add enahance dependency forgotten in the recent commit [1]
> 66a6082 Add %{_default_patch_flags} to %__patch which is used in %autosetup
> 69ed95e Enable --no-backup-if-mismatch by default in %patch macro
> (rhbz:884755)
> b722cf8 Fix reading rpmtd behind its size in formatValue() (rhbz:1316896)
> cddf43a Fix sigsegv in stringFormat() (rhbz:1316903)
> b4f0e7e Make sure getNEVRA always sets td.data
> 6ac793b Filter unversioned deps if corresponding versioned deps exist
> (rhbz:678605)
> 5d5dd56 Use armv7hl isa for all armhfp (armv7h*l) arches (#1326871)
> 258e306 Fix signing with non-ASCII uid keys (rhbz:1243963)
> 0964912 Fix off-by-one error
> 1aeddbc fix segfault when calling with args==NULL
> 4ec7c39 Add sepdebugcrcfix to fixup old style gnu_debuglink CRC checksum.
> 6b3b435 Add dwz debuginfo compression support.
> b33a41d Add find-debuginfo.sh -m minisymtab support.
> cf56793 rpmrc: Convert uname.machine == "riscv" to
> "riscv32"/"riscv64"/"riscv128".
> d9d47e0 RISCV 64-bit (riscv64) support.
> f255c6b Fix overflow in cpio filename by limiting the allowed length to 4kB
> e41550e Fix misleading-indentation in rpmplugins.c
> 7e26e2b Create files with with 000 permissions to avoid leaking yet
> unchecked data
> a6e662f rpm2archive: return 0 on success instead of stop iteration
> bd76111 find-debuginfo.sh: Don't copy extra sections into .gnu_debugdata.
> 6e7c6d1 Revised fix for CVE-2013-6435
>
> If that seems somewhat strange selection, that's because ... well, I agree
> it is. To minimize the risk of breaking anything, this is almost exactly
> what has been included in Fedora and Mageia rpm during the past year. Which
> means its reasonably tried and true code, which is exactly what we want to
> get the thing out of the door, fast.
>
> I know there's a huge pile of other important fixes and enhancements in git
> master waiting for an outlet. The idea is to get 4.13.0 out as soon as we
> can reasonably can, just to break the current logjam. And then immediately
> start looking forward to both new major release and backporting more goodies
> to 4.13.x in the meanwhile. Think on the order of three months max to
> 

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Thierry Vignaud]

On 17 October 2016 at 11:42, Panu Matilainen <pmati...@laiskiainen.org> wrote:
> On 10/17/2016 12:30 PM, Thierry Vignaud wrote:
>>
>> On 17 October 2016 at 10:10, Panu Matilainen <pmati...@laiskiainen.org>
>> wrote:
>>>>
>>>> What is the chance to get [1, 2] into the release? I mildly remember,
>>>> that once I was offered to get this patch into Fedora, but that never
>>>> materialized and now it is almost a year. I don't think this is
>>>> controversial change which should make anything break.
>>>>
>>>> Thx for considering.
>>>>
>>>>
>>>> Vít
>>>>
>>>>
>>>> [1] https://github.com/rpm-software-management/rpm/pull/27
>>>> [2]
>>>>
>>>>
>>>> https://github.com/rpm-software-management/rpm/commit/89d1dd0a7c63c7497d334e9f240ce7e36ca89434
>>>
>>>
>>>
>>> Hmm, that has actually been in Mageia for over a year so it's certainly
>>> gotten its share of soak-time (so at least it's not breaking anything
>>> else)
>>> and people are probably depending on it in Mageia so it'd be a reasonable
>>> candidate.
>>
>>
>> Actually, it's been here at least in Mageia from much more earlier:
>>
>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.6.1-setup-rubygems.patch?view=markup=343
>>
>> I think the original patch went in in October 2010, previously we were
>> using a separate %gem_unpack macro
>>
>> But it's not the same implementation as the one that has been merged
>> in master. Mageia one is:
>>
>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.12.90-setup-rubygems.patch?revision=860276=markup
>
>
> Oh, I wasn't aware there were two implementations, I just assumed its the
> same implementation. Thanks for pointing this out, but it does mean the
> upstream implementation is not real-world tested so its not 4.13.0 material.
> In this circumstance anyway. Such minor enhancements are perfectly welcome
> in 4.13.1 though once we get there.
>
>>
>> But if it works the same, Mageia will be happy to drop one more patch :-)
>
>
> Since you obviously have existing users for the feature, please test the
> upstream patch with your packages and see what if anything is
> missing/broken. Me, I've no clue about Ruby business :)

@Pascal: could you run an autobuild
(http://pkgsubmit.mageia.org/autobuild/) with 2 packages from a custom
repo/medium?
You would need the following packages:
- rpm: just replace Patch2006 with 0001-Add-RubyGems-support.patch
generated by running:
git clone https://github.com/rpm-software-management/rpm.git
git format-patch 89d1dd0a7c63c7~1..89d1dd0a7c63c7

- ruby-RubyGems (apply rubygems.macros.diff to SOURCE1:rubygems.macros)
(patch is in the previous mail I CC:ed you)

Then if all packages build smoothly, we can as well switch to the upstream patch

You could restrict the autobuild to ruby* packages in order to speed it up.
WDYT?
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Thierry Vignaud]

On 17 October 2016 at 12:06, Vít Ondruch <vondr...@redhat.com> wrote:
> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
>> On 17 October 2016 at 10:10, Panu Matilainen <pmati...@laiskiainen.org> 
>> wrote:
>>>> What is the chance to get [1, 2] into the release? I mildly remember,
>>>> that once I was offered to get this patch into Fedora, but that never
>>>> materialized and now it is almost a year. I don't think this is
>>>> controversial change which should make anything break.
>>>>
>>>> Thx for considering.
>>>>
>>>>
>>>> Vít
>>>>
>>>>
>>>> [1] https://github.com/rpm-software-management/rpm/pull/27
>>>> [2]
>>>>
>>>> https://github.com/rpm-software-management/rpm/commit/89d1dd0a7c63c7497d334e9f240ce7e36ca89434
>>>
>>> Hmm, that has actually been in Mageia for over a year so it's certainly
>>> gotten its share of soak-time (so at least it's not breaking anything else)
>>> and people are probably depending on it in Mageia so it'd be a reasonable
>>> candidate.
>> Actually, it's been here at least in Mageia from much more earlier:
>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.6.1-setup-rubygems.patch?view=markup=343
>>
>> I think the original patch went in in October 2010, previously we were
>> using a separate %gem_unpack macro
>>
>> But it's not the same implementation as the one that has been merged
>> in master. Mageia one is:
>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.12.90-setup-rubygems.patch?revision=860276=markup
>>
>> But if it works the same, Mageia will be happy to drop one more patch :-)
>
> They are a bit different indeed. These are two main differences I can see:
>
> 1) The upstream patch is using 'gem' command to unpack the sources
> instead of using 'tar'. The advantage of this approach is that it should
> be always able to unpack every gem. Please note that historically, the
> .gem format was internally different and the format might change again
> in the future. The disadvantage is the dependency on external tool, but
> this is just soft dependency, since RPM can handle the missing 'gem'
> command gracefully.
>
> 2) There is provided the %{gem_name}.gemspec file alongside the unpacked
> code, which is in Fedora used to repackage patched gem, prior installation.

As it turns out, there's at least one other difference which breaks
build for us:
eg for ruby-gemcutter
(http://svnweb.mageia.org/packages/cauldron/ruby-gemcutter/current/SPECS/ruby-gemcutter.spec?revision=947391=markup)
our implementation creates eg:
BUILD/ruby-gemcutter-0.7.1
whereas the patch merged upstream creates eg:
BUILD/gemcutter-0.7.1

This breaks the couple packages I tried.
This would need to patch the macros we ships with ruby-RubyGems
(see attached rubygems.macros.diff)

Then the build succeeds
(see attached build.diff)
--- /tmp/rubygems.macros2016-10-17 14:35:07.904237907 +0200
+++ /etc/rpm/macros.d/rubygems.macros   2016-10-17 14:43:29.890878794 +0200
@@ -13,8 +13,7 @@
 %gem_name %{?oname}%{!?oname:%(echo %{name}|cut -d\- -f2-)}
 
 %gem_setup \
-%setup -q \
-tar xmf data.tar.gz \
+%setup -q -n %{gem_name}-%{version} \
 if [ ! -f %{gem_name}.gemspec ]; then \
 %{_bindir}/gem specification -l --ruby %{SOURCE0} > 
%{gem_name}.gemspec \
 fi \
--- LOG12016-10-17 14:26:05.103145564 +0200
+++ LOG22016-10-17 14:43:37.727029153 +0200
@@ -5,29 +5,29 @@
 processing package ruby-gemcutter-0.7.1-%mkrel 12
 building binary packages
 succeeded!
-Executing(%prep): /bin/sh -e 
/home/tv/mga/pkgs/N/ruby-gemcutter/BUILDROOT/rpm-tmp.2jNRu2
+Executing(%prep): /bin/sh -e 
/home/tv/mga/pkgs/N/ruby-gemcutter/BUILDROOT/rpm-tmp.4n5bXt
 + umask 022
 + cd /home/tv/mga/pkgs/N/ruby-gemcutter/BUILD
 + '[' 1 -eq 1 ']'
 + '[' 1 -eq 1 ']'
 + '[' 1 -eq 1 ']'
 + cd /home/tv/mga/pkgs/N/ruby-gemcutter/BUILD
-+ rm -rf ruby-gemcutter-0.7.1
-+ /usr/bin/mkdir -p ruby-gemcutter-0.7.1
-+ cd ruby-gemcutter-0.7.1
-+ /usr/bin/tar -xmof 
/home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem
-+ '[' -f data.tar.gz ']'
-+ tar -xmof data.tar.gz
++ rm -rf gemcutter-0.7.1
++ /usr/bin/gem unpack 
/home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem
+Unpacked gem: '/home/tv/mga/pkgs/N/ruby-gemcutter/BUILD/gemcutter-0.7.1'
++ /usr/bin/gem spec 
/home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem --ruby
++ STATUS=0
++ '[' 0 -ne 0 ']'
++ cd gemcutter-0.7.1
 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
-+ tar xmf data.tar.gz
 + '[' '!' -f gemcutter.gemspec ']'
 + /usr/bin/gem specification -l --ruby 
/home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem
 + sed -i -e 's/`git ls-files`/`find -type f`

Re: [Rpm-maint] Planning for rpm 4.13.0 (-rc2)

[Thierry Vignaud]

On 14 October 2016 at 15:33, Panu Matilainen  wrote:
> Time to get rpm 4.13.0 out of the door. But in order to do that, we'll need
> to cut -rc2 first, there's just too much change to jump right into final.
>
> The idea is to get -rc2 out next week (ie by Oct 21st at latest). If all
> goes well we'll just rename that to -final in a few weeks time, if all goes
> to hell we'll just have another -rc. Which I really, really dont want to
> happen. So what I've planned for -rc2 is this rather conservative
> cherry-picks from git master on top of the 4.13.x branch:

(...)

> If that seems somewhat strange selection, that's because ... well, I agree
> it is. To minimize the risk of breaking anything, this is almost exactly
> what has been included in Fedora and Mageia rpm during the past year. Which
> means its reasonably tried and true code, which is exactly what we want to
> get the thing out of the door, fast.

Thanks for restarting the process.
It has been months I was thinking about pinging for a RC2 but I was too lazy.
I'd started cherry-picks the patches shared by FC/mga but I stoped
months ago and never submit it so thx for doing it

> P.S. Yes, I'm back at rpm work, officially started this Monday. Lest anybody
> have funny ideas: this was set in motion out of my own will well before the
> recent "crisis" reported on lwn.net, although the timing of that was quite a
> coincindence. But as they say, old flames die hard ;)

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

Re: [Rpm-maint] [PATCH v2 1/4] ima-plugin: Have executable configuration files signed

[Thierry Vignaud]

On 23 September 2016 at 08:44, Panu Matilainen  wrote:
> Also generally it's preferred to avoid magic numbers when it can be easily
> expressed with defined names, (S_IXUSR|S_IXGRP|S_IXOTH) is easier for the
> reader than 0111.

That actually depends on the reader :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH 3/4] Add sepdebugcrcfix to fixup old style gnu_debuglink CRC checksum.

[Thierry Vignaud]

On 6 June 2016 at 23:00, Mark Wielaard  wrote:
> Some old tools might still use the .gnu_debuglink section to find
> separate debuginfo files instead of build-id style lookups. When
> dwz has compresses the .debug files the original CRC in the main
> ELF file will no longer match. Make sure to run sepdebugcrcfix
> after dwz to recalculate the CRC.
>
> The original fix was created by Jan Kratochvil based on code
> from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
> I added a testcase to make sure the CRCs were all correctly
> updated after dwz has run to compress a debuginfo package.

WARNING: Note that the original Fedora patch has issues!
Panu (the then upstream rpm.org maintainer) said it should _not_ be
upstreamed when we bring the issue up:

Once we applied this patch to rpm-4.12 in Mageia, rpm silently dropped
the suid/sgid bits from files if they were re not explicitely listed with %attr
This was breaking packages...
See https://bugs.mageia.org/show_bug.cgi?id=14691

We tracked it down to:
rpm-4.11.1-sepdebugcrcfix.patch
("fix .gnu_debuglink CRC32 after dwz (rhbz#971119)")

See https://bugs.mageia.org/show_bug.cgi?id=14691#c4


Panu answered:

== BEGIN
As for the "are you sure we (still) need this patch" question, the
answer has always been "almost certainly not".

The short summary is that the issue it fixes only is present if you
use dwz to compress the debuginfo (like Fedora does), and even then
case it only affects a handful of toolchain developers in the entire
world.

See https://bugzilla.redhat.com/show_bug.cgi?id=971119 for further
explanation of the issue, comment #9 answers the who is affected part.

Personally my opinion is "just kick out the stupid patch already" :)
but judge for yourselves.
== END

Florian, you should still have the details in your mailbox ("rpm
silently loosing suid/sgid bits" private discussion in 2014
December/2015 February between me, Panu & you)

This shows I should have used the list instead of using private mails :-(

So I would say to _not_ merge this patch.
It should remain in Fedora's rpm, not be upstreamed.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH 2/4] Add dwz debuginfo compression support.

[Thierry Vignaud]

On 6 June 2016 at 23:00, Mark Wielaard  wrote:
> Support for dwz compression has been in Fedora since a couple of years.
> https://fedoraproject.org/wiki/Features/DwarfCompressor

And in some other distros as well (eg: Mageia).
So if this this lands upstream, we'll be happy too :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH v9 09/13] Add file signature support to package signing

[Thierry Vignaud]

On 11 May 2016 at 22:35, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
>> This patch modifies rpmSign to include file signatures in the header.
>> Since the header is altered, the package digest and package+archive
>> digest need to be recalculated and updated in the signature header.
>> Defer resigning the header digests to replaceSignature().
>>
>> Changelog:
>> - remAdd file signature support to package signing
>
> The following change makes perl-RPM4's testsuite to fail due to segfault:
> (see attached gdb trace)
>
>> @@ -720,5 +878,5 @@ int rpmPkgSign(const char *path, const struct 
>> rpmSignArgs * args)
>>
>>  int rpmPkgDelSign(const char *path)
>>  {
>> -return rpmSign(path, 1);
>> +return rpmSign(path, 1, 0);
>>  }
>
> The attached patch fixes that.
> It's against the 4.13.x branch but should apply on master too.
>
> Please apply
> Thanks

Ping?
the doc explicitely describe "args" as "signing parameters (or NULL for
defaults)"

This no more true since commit 6e9eab345a18d01f0c2c35fa8bb842744093364c
As such, with rpm-4.13, some callers will segfault (eg: perl-RPM4's
testsuite)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] broken filetriggers implementation when using a chroot

[Thierry Vignaud]

On 9 January 2016 at 02:56, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
> On 6 January 2016 at 12:42, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
>> Sadly, the current filetriggers doesn't honour rpm's chroot.
>> Thus it works fine with our rpm front-end (urpmi which is like yum/dns
>> for FC) for online updates.
>>
>> But not with our installer (Drakx) which installs packages in a chroot
>> (like Anaconda does for FC)
>> See https://bugs.mageia.org/show_bug.cgi?id=17217
>> And urpmi can reproduce this too when using a chroot:
>
> The 3 attached patches fix this bug.
> I've split them into 3 parts:
> - add a new API for package state machine
> - use it in psm.c
> - fix the remaining issues in transaction.c
>   (aka file triggers in _other_ packages)
>
> Please apply.
>
> Patches are against the rpm-4.13.x branch.
> When merged in HEAD, there'll be a trivial conflict in the last bit of
> the 3rd patch due to
> "Add possibility to disable file triggers" commit
>
> Thanks

Though we now have the following error:

error: cannot open Transfiletriggername index using db5 - No such file
or directory (2)

It wrongly include the chroot path in the rpmdb path where it's
already chrooted in:

chroot("/home/tv/TL2/") = 0
stat("/home/tv/TL2/var/lib/rpm/Transfiletriggername", 0x7ffefa1ac9b0)
= -1 ENOENT (No such file or directory)
stat("/home/tv/TL2/var/lib/rpm/Transfiletriggername", 0x7ffefa1aca60)
= -1 ENOENT (No such file or directory)
stat("/home/tv/TL2/var/lib/rpm/Transfiletriggername", 0x7ffefa1ac9b0)
= -1 ENOENT (No such file or directory)
stat("/home/tv/TL2/var/lib/rpm/Transfiletriggername", 0x7ffefa1aca60)
= -1 ENOENT (No such file or directory)
stat("/home/tv/TL2/var/lib/rpm/__db.Transfiletriggername",
0x7ffefa1ac8d0) = -1 ENOENT (No such file or directory)
open("/home/tv/TL2/var/lib/rpm/__db.Transfiletriggername",
O_RDWR|O_CREAT|O_EXCL, 0644) = -1 ENOENT (No such file or directory)
error: cannot open Transfiletriggername index using db5 - No such file
or directory (2)
chroot(".") = 0

Which means we'll fail to honor file triggers priority
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] broken filetriggers implementation when using a chroot

[Thierry Vignaud]

On 6 January 2016 at 12:42, Thierry Vignaud <thierry.vign...@gmail.com> wrote:
> Sadly, the current filetriggers doesn't honour rpm's chroot.
> Thus it works fine with our rpm front-end (urpmi which is like yum/dns
> for FC) for online updates.
>
> But not with our installer (Drakx) which installs packages in a chroot
> (like Anaconda does for FC)
> See https://bugs.mageia.org/show_bug.cgi?id=17217
> And urpmi can reproduce this too when using a chroot:

The 3 attached patches fix this bug.
I've split them into 3 parts:
- add a new API for package state machine
- use it in psm.c
- fix the remaining issues in transaction.c
  (aka file triggers in _other_ packages)

Please apply.

Patches are against the rpm-4.13.x branch.
When merged in HEAD, there'll be a trivial conflict in the last bit of
the 3rd patch due to
"Add possibility to disable file triggers" commit

Thanks


0001-runImmedFileTriggersInChroot-introduce-it.patch
Description: application/binary


0002-fix-transfiletrigger-iu-n-file-triggers.patch
Description: application/binary


0003-fix-transaction-filetriggers-in-other-package-s.patch
Description: application/binary
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm] Rename pythonXegg to pythonX.Ydist and read .dist-info (#33)

[Thierry Vignaud]

On 21 November 2015 at 17:50, Neal Gompa (ニール・ゴンパ)  wrote:

> Per the recommendation of Nick Coghlan and Toshio Kuratomi, pythonXegg(M)
> is being renamed to pythonX.Ydist(M).
>
​I disagree.
This deps script is widely used​

​by one rpm.org user for years: Mageia Linux.
We use the the "pythonegg(X)(M)" style.
eg: "pythonegg(3)(pyicu)"

I agree with integrating them upstream.
But I disagree with breaking the _one_ rpm.org user.
If the deps style changes from "pythonegg(X)(M)", this means wide breakage
for Mageia Linux.

So please don't!​

> An option has also been added to add a pythonXdist(M) Provides for
> distributions that may prefer to have it. The option is intended for use if
> only one python stack per major version will be available at a given time,
> as unexpected results may occur if there are multiple independent Python
> stacks per major version available.
>
> Consequently, it will not be on by default when using the generator for
> generating Provides.
>
> Additionally, .egg-info data is being replaced with .dist-info data, so we
> need to handle that case, too.
>
> See for more details:
> https://lists.fedoraproject.org/archives/list/python-devel%40lists.fedoraproject.org/thread/SQBSAS4T25HK5YJBNBSFDD7KDQWDELL6/
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/rpm-software-management/rpm/pull/33
> Commit Summary
>
>- Rename to pythonX.Ydist & read .dist-info
>
> File Changes
>
>- *R* scripts/pythondistdeps.py
>
>(47)
>
> Patch Links:
>
>- https://github.com/rpm-software-management/rpm/pull/33.patch
>- https://github.com/rpm-software-management/rpm/pull/33.diff
>
> —
> Reply to this email directly or view it on GitHub
> .
>
> ___
> Rpm-maint mailing list
> Rpm-maint@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint
>
>
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] fix %doc with glob with some locales

[Thierry Vignaud]

Hi

We've some spec files that fail to build under some locales, when %doc
is used with glob

See eg:
%build
touch author AUTHORS Ch cha
(...)
%files
%doc [A-Z]*

Which results in:

LANG=fr LC_COLLATE=fr LC_ALL=fr rpmbuild -ba SPECS/null.spec
(...)
error: Installed (but unpackaged) file(s) found:
   /usr/share/doc/null/cha
   /usr/share/doc/null/debugfiles.list
   /usr/share/doc/null/debuglinks.list
   /usr/share/doc/null/debugsources.list

RPM build errors:
Installed (but unpackaged) file(s) found:
   /usr/share/doc/null/cha
   /usr/share/doc/null/debugfiles.list
   /usr/share/doc/null/debuglinks.list
   /usr/share/doc/null/debugsources.list

Which is obviously not expected

While I don't think using such globs with %doc is such a nice idea,
it's still a bug and the attached patch fixes it.

Please apply.


0001-fix-doc-with-glob-with-some-locales.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] fix %autopatch when patch do not exist

[Thierry Vignaud]

On 18 September 2015 at 11:50, Dimitri John Ledkov
 wrote:
> So this %autopatch thing is a bit useless to me at the moment,
> specifically because of the requirement to have patches in
> rpmbuild/SOURCES/.

Uh?
Patches can be anywhere.
They're found where %patch is looking for them.
There's nothing changed there.
It can be anywhere...

> And it's not nice to operate against packaging committed to git.

Uh?
What?
You've the choice. You can use git or not.
Both are supported. And more.

It works nicely for Mageia. It has been tested by lots of packages in
lots of different locations
(rpmbuild/SOURCES, /SOURCES, ...)
It works nicely with either manual rpmbuild or with iurt (~~mock for Mageia).

> I have a git tree with foo.spec & foo.patch. And use mock to build it:
>
> $ mock --buildsrpm --source=./ --spec=foo.spec --results=results/
>
> %autopatch / %autosetup then looks for patches in the wrong location.
> Am I missing something to use both %autopatch and patches from the
> same location as the spec file?

I think you needs to show your spec up.
But I bet that mock --buildsrpm works smoothly.
Are you sure mock --spec/--sources works for your foo.spec with
regular plain %patch macros?
I've never used --spec/--sources but maybe there's a regression and it
doesn't set right the path macros (eg: %_sourcedir).

But please open a __new mail thread__ for that.
Thanks :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] fix %autopatch when patch do not exist

[Thierry Vignaud]

Hi

The attached patch fixes %autopatch (& thus %autosetup too) when a
patch doesn't actually exist.

Indeed, unlike Mageia's %apply_patches which inspired it, %autopatch
continues instead of exiting when it fails to apply a patch because it
doesn't exists. Eg:

+ /usr/bin/cat /home/tv/rpmbuild/SOURCES/test.patch2
+ /usr/bin/patch -p1 -s
/usr/bin/cat: /home/tv/rpmbuild/SOURCES/test.patch2: No such file or directory
+ /usr/bin/cat /home/tv/rpmbuild/SOURCES/test.patch
+ /usr/bin/patch -p1 -s

With the attached patch, the build stops as soon as the error is seen.

Please apply.
It should be backported to 4.12.x & 4.13.x branches too

See you


0001-fix-autopatch-when-patch-do-not-exist.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] incompatible pythoneggs deps generator merged

[Thierry Vignaud]

Hi

I see that you've merged pythoneggs generator in rpm.org:
http://rpm.org/gitweb?p=rpm.git;a=log;h=ce15157774833c81f9610693b1473556f8cd

I would suggests merging Mageia's one instead:
http://gitweb.mageia.org/software/rpm/rpm-setup/plain/pythoneggs.attr
http://gitweb.mageia.org/software/rpm/rpm-setup/plain/pythoneggs.py

Rationale:
- it's plugged it with the internal deps generator;
- it works with the internal deps generator
- it doesn't mix typelib() deps with pythoneggs() ones[1]
- it doesn't rely on a non existent gi-find-deps.sh script[1]
- it's well tested with rpm.org as we used it for a couple years
whereas the one imported is just one that was used with rpm5.

Also currently that would make rpm-4.13 break deps on Mageia Linux
(b/c of pythoneggs(3) vs python3egg deps) whereas if Per Oyvind's
distro switches from rpm5 to rpm.org, they'll need mass rebuild b/c of
all the changes between rpm5 & rpm.org, so I think they could afford
migration from pythonXegg() to pythoneggs(X)()

What's more, this commit suggests that it actually changes the deps
style against what's currently used by them currently with rpm5:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=3523921ea9366746623bb634c5d304c258e67354

So the less intrusive change would be to stick with Mageia pythoneggs(x) style:
It would be useless & gratuitous to break deps for Mageia when the
distro that's thinking about switching from rpm5 to rpm.org will
actually have to switch deps style already.
It's better to have only one distro to switch deps style rather than
two, isn't it?

What's more, from what I've read on the cooker ml, the switch to
rpm.org hasn't been agreed yet, it's just a proposal.
So that's one more reason for not breaking Mageia

My 2 cents

Summary: Please do not break Mageia
Thanks

See you

[1] if we merge typelib() generators, please bring in the Suse guys
are they're the ones who write it and we're using their version too.
Please stick which was is used by current rpm.org users instead of
what's may used by a distro which might switch from rpm5 to rpm.org
(which doesn't seem decided yet)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] do not bytecompile python scripts in docdir

[Thierry Vignaud]

Hi

This patch prevents bytecompiling python scripts in docdir (which is useless)

See you


0001-do-not-bytecompile-python-scripts-in-docdir.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] support for multi-threaded compressors

[Thierry Vignaud]

On 28 August 2015 at 14:30, Thierry Vignaud thierry.vign...@gmail.com wrote:
 Objectives of this patch is to speed up the compression in rpmbuild. To
 achieve this, the patch implements support for a new compressor, functioning
 as an interface against external (multi-threaded) compressors. The main
 issue with these external compressor-wrappers is the lack of libraries (i.e.
 gzwrite, lzwrite). There's no corresponding functions for PIGZ, PBZIP2, PXZ
 etc. The new compressor has been written to as closely as possible emulate
 these functions, while piping the data from Fwrite to an external process,
 reading any data from the (external) compressor to prevent buffer overflows
 and/or excessive memory usage. To use pigz (instead of gzip) just add to the
 spec-file:
 %define _source_payload w9.pigzdio
 %define _binary_payload w9.pigzdio
 and for pxz (instead of xz):
 %define _source_payload w9.pxzdio
 %define _binary_payload w9.pxzdio

 There's lot of gratuitous space/indent changes there.
 Please remove them...

Also it's not against latest git master...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] Transmeta Crusoe is i686

[Thierry Vignaud]

Hi

This old patch from TurboLinux makes rpm treat Transmeta Crusoe as i686:

Crusoe CPUs say that their CPU family is 5 but they have enough
features for i686.

See you


0006-Transmeta-Crusoe-is-i686.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] skip plain, regular comments

[Thierry Vignaud]

Hi

This patchs makes rpm skip plain, regular comments when computing perl deps

See you


0003-skip-plain-regular-comments.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] ignore non module perl files for provides

[Thierry Vignaud]

Hi

This patchs makes rpm ignores perl provides from non module perl files

rationale:
Don't search perl files for provides if they don't end with .pm (because
if they don't, the perl interpreter won't look them up in @INC)

See you


0002-ignore-non-module-perl-files-for-provides-if.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] support for multi-threaded compressors

[Thierry Vignaud]

On 28 August 2015 at 13:42, fredrik fred...@skri.net wrote:
 Objectives of this patch is to speed up the compression in rpmbuild. To
 achieve this, the patch implements support for a new compressor, functioning
 as an interface against external (multi-threaded) compressors. The main
 issue with these external compressor-wrappers is the lack of libraries (i.e.
 gzwrite, lzwrite). There's no corresponding functions for PIGZ, PBZIP2, PXZ
 etc. The new compressor has been written to as closely as possible emulate
 these functions, while piping the data from Fwrite to an external process,
 reading any data from the (external) compressor to prevent buffer overflows
 and/or excessive memory usage. To use pigz (instead of gzip) just add to the
 spec-file:
 %define _source_payload w9.pigzdio
 %define _binary_payload w9.pigzdio
 and for pxz (instead of xz):
 %define _source_payload w9.pxzdio
 %define _binary_payload w9.pxzdio

There's lot of gratuitous space/indent changes there.
Please remove them...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 25 August 2015 at 13:11, Thierry Vignaud thierry.vign...@gmail.com wrote:
 The problem is when you upgrade distro N to N+2 both triggers should
 be run but only one was run, which was confusing so we disallowed
 triggers fired by the same package with overlapping version intervals.
 And initscripts = 4.72 and initscripts = 8.38-2 overlaps.
 Have a look at bugs #585384, #702378 that initiate this change.

 OK for that but there's a related issue with file triggers:
 I was testing converting our old filetriggers to new upstream filetriggers.
 However it looks like it's no more possible to have 2 different
 filetriggers (for %trans* ones) on the same directory:

 D: %triggerin(null-1:11-11.mga6.x86_64): waitpid(19591) rc 19591 status 0
 rpm: backend/dbiset.c:62: dbiIndexSetUniq: Assertion `set-count  0' failed.

 See the calls to rpmtsUniqTriggers() in lib/rpmtriggers.c
err, s/rpmtsUniqTriggers/rpmdbUniqIterator/

 Why is that?

 For now, I've workarounded the case I've seen but there may be other cases...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 4 August 2015 at 15:43, Lubos Kardos lkar...@redhat.com wrote:
 The problem is when you upgrade distro N to N+2 both triggers should
 be run but only one was run, which was confusing so we disallowed
 triggers fired by the same package with overlapping version intervals.
 And initscripts = 4.72 and initscripts = 8.38-2 overlaps.
 Have a look at bugs #585384, #702378 that initiate this change.

OK for that but there's a related issue with file triggers:
I was testing converting our old filetriggers to new upstream filetriggers.
However it looks like it's no more possible to have 2 different
filetriggers (for %trans* ones) on the same directory:

D: %triggerin(null-1:11-11.mga6.x86_64): waitpid(19591) rc 19591 status 0
rpm: backend/dbiset.c:62: dbiIndexSetUniq: Assertion `set-count  0' failed.

See the calls to rpmtsUniqTriggers() in lib/rpmtriggers.c
(added in:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=30a5603159083f2840bfae801ab27ba5f78c36e7)

Why is that?

For now, I've workarounded the case I've seen but there may be other cases...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 25 August 2015 at 13:41, Thierry Vignaud thierry.vign...@gmail.com wrote:
 The problem is when you upgrade distro N to N+2 both triggers should
 be run but only one was run, which was confusing so we disallowed
 triggers fired by the same package with overlapping version intervals.
 And initscripts = 4.72 and initscripts = 8.38-2 overlaps.
 Have a look at bugs #585384, #702378 that initiate this change.

 OK for that but there's a related issue with file triggers:
 I was testing converting our old filetriggers to new upstream filetriggers.
 However it looks like it's no more possible to have 2 different
 filetriggers (for %trans* ones) on the same directory:

 D: %triggerin(null-1:11-11.mga6.x86_64): waitpid(19591) rc 19591 status 0
 rpm: backend/dbiset.c:62: dbiIndexSetUniq: Assertion `set-count  0' failed.

 See the calls to rpmtsUniqTriggers() in lib/rpmtriggers.c
 err, s/rpmtsUniqTriggers/rpmdbUniqIterator/

 Why is that?

 For now, I've workarounded the case I've seen but there may be other cases...

And I've encountered more cases.
The attached patch fixes that situation
diff -up ./lib/rpmtriggers.c.tv ./lib/rpmtriggers.c
--- ./lib/rpmtriggers.c.tv  2015-07-23 08:41:00.651210888 -0400
+++ ./lib/rpmtriggers.c 2015-08-25 09:41:58.339200191 -0400
@@ -124,7 +124,6 @@ void rpmtriggersPrepPostUnTransFileTrigs
 }
 rpmdbIndexIteratorFree(ii);
 
-rpmdbUniqIterator(mi);
 if (rpmdbGetIteratorCount(mi)) {
/* Filter triggers and save only trans postun triggers into ts */
while((trigH = rpmdbNextIterator(mi)) != NULL) {
@@ -317,7 +316,6 @@ static const char *matchFilesNext(matchF
RPMDBI_DIRNAMES, mfi-pfx, 0);
 
rpmdbFilterIterator(mfi-pi, mfi-tranPkgs, 0);
-   rpmdbUniqIterator(mfi-pi);
 
} while (fx = 0);
 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] translations updates

[Thierry Vignaud]

On 17 August 2015 at 09:22, Lubos Kardos lkar...@redhat.com wrote:
 Hi,
 the best way how to contribute to translations is to modify strings in rpm
 project on www.transifex.com. We pull our translations from there. In future
 we plan to remove translations from git completely and just pull them during
 build. So if you can then please update rpm project on transifex.

OK, I'm waiting for my submission as a translator to be ACKed
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [dev] rpm python3 binding giving an error

[Thierry Vignaud]

On 9 August 2015 at 21:34, Olav Vitters o...@vitters.nl wrote:

 import rpm._rpmb
 ImportError: /usr/lib64/python3.4/site-packages/rpm/_rpmb.cpython-34m.so: 
 undefined symbol: PyString_FromString

The attached patch fixes it.
Lubos, can you commit this?
Thanks


0014-Fix-last-occurence-of-PyString.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] translations updates

[Thierry Vignaud]

Hi

Could you apply those translations updates?
Thanks


0003-typo-fix.patch
Description: Binary data


0013-unfuzzy.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 4 August 2015 at 20:53, Thierry Vignaud thierry.vign...@gmail.com wrote:
 The problem is when you upgrade distro N to N+2 both triggers should
 be run but only one was run, which was confusing so we disallowed
 triggers fired by the same package with overlapping version intervals.
 And initscripts = 4.72 and initscripts = 8.38-2 overlaps.
 Have a look at bugs #585384, #702378 that initiate this change.

 It would have been better to explain it the log message then :-)
 So can you adjust the release notes draft in order to explain this.
 Thus it will be easier to be sold to packagers :-)

BTW, we've --triggers option in order to see what I would call package triggers
Could you add a --filetriggers option in order to see file triggers too?
See the attached patch (including doc)
Thanks


0013-add-filetriggers-option.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 24 July 2015 at 13:48, Florian Festi ffe...@redhat.com wrote:
 Time to wrap things up and stabilize all that changes to a new release.
 There are two big new features that we hope to get feedback on:

  * Boolean (aka Rich) Dependencies
  * File triggers

 Beside that there are many other fixes, improvements and cleanups.

 For download information and further details, see the draft release
 notes: http://rpm.org/wiki/Releases/4.13.0

 On behalf of the rpm-team,

Humm...

rpm-4.13 is stricter about multiple (classic package) triggers:
error: line 320: Trigger fired by the same package is already defined
in spec file: %triggerpostun -- initscripts  8.88-5

This is caused by this which worked fine until now:

%triggerpostun -- initscripts = 4.72
(...)

%triggerpostun -- initscripts = 8.38-2
(...)

Here I can safely kill very old triggers.
But there's obviously real cases where we might want to have two
similar triggers, only differing by the version that trigger it.
(eg: fixing a 1st issue when upgrading to distro N to N+2, and fixing
another one when upgrading from distro N+1 to N+2)

This is due to this commit:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=3ae1c414f69a0eddbfecd4341dd27c7a5e90e12a

This is breaking existing packages
Why imposing this limit?
Why would it be OK for file triggers but not for package triggers?
Do we really want to enforce at rpm level the fact that some distro
only support upgrading from version N to version N+1?

I suggest we revert that commit ( adjust http://rpm.org/wiki/Releases/4.13.0)
WDYT?

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

Re: [Rpm-maint] [PATCH] drop rtld(GNU_HASH) hack

[Thierry Vignaud]

On 17 September 2014 09:35, Panu Matilainen pmati...@laiskiainen.org wrote:
 The attached patch drops the drop rtld(GNU_HASH) hack

 The patch does much more than drop a couple of lines:
 $ diffstat no-rtld_GNU_HASH_req.diff
  lib/tagexts.c   |   54
 ++
  tools/elfdeps.c |8 
  2 files changed, 54 insertions(+), 8 deletions(-)

 That aside...

argh, sorry two patches got merged.
(too much undersleeping due to baby caring :-) )
Of course, I only intented to submit you the elfdeps bits

 Drop automatically generated rtld(GNU_HASH) dependencies.
 It's been provided by glibc for 7 years now and can safely be assumed
 that there's no longer any need for it, reducing ~5K packages'
 dependency in repository metadata on it during next rebuild.


 ... NAK, distros where GNU_HASH is not supported are still widely deployed
 (RHEL/Centos = 5 and no doubt Suse Enterprise versions of that era).

Seriously :-) ?
rpm-4.12+ on RHEL5.x :-) ?
It's using rpm-4.4.2.3. Even RHEL6 is stuch at rpm-4.8
I don't think they could install a package from a GNU_HASH aware package
due to the different payload compressor or due to new lib deps.
Anyway that would be a

 I guess we could add a cli-switch to allow easily disabling it, but then
 repository metadata is better trimmed and filtered in createrepo (it already
 does this for rpmlib() dependencies etc)

Not everybody uses createrepo :-)
We use genhdlist2 in Mageia.

Also note that whereas less deps in repo metadata is nice for deps solvers,
less deps in package headers is also nice for rpm when checking/ordering
the transaction.
I won't pretend if will shape a new future but it's an easy low fruit
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] perl.{prov,req} improvments

[Thierry Vignaud]

On 17 September 2014 10:39, Panu Matilainen pmati...@laiskiainen.org wrote:
Mageia just switched to internal deps generator (at least).
 In the process, I unforked as most scripts as possible.
 Here's some old fixes:

 skip-plain-regular-comments.diff:
 just skip plain, regular perl comments...


 What's the reproducer for the case where this is needed? At least in my
 trivial testcase, a comment is handled as it should, eg only perl(foo) is
 provided from

 package foo;
 #package bar;

 support-for-_-in-perl-module-version.diff:
 support for _ in perl module version


 This looks fairly obvious, too obvious in fact. Makes me wonder if its being
 omitted on purpose, but I've not a perl person and haven't got a clue
 about perl conventions. Ville (or others), thoughts?

I'll let Jerome explain.
As a side note, another improvement would be to ignore use/require in evals.
That would saves quite a lot requires excludes but of course it might not be
trivial...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] drop rtld(GNU_HASH) hack

[Thierry Vignaud]

Hi

The attached patch drops the drop rtld(GNU_HASH) hack

Drop automatically generated rtld(GNU_HASH) dependencies.
It's been provided by glibc for 7 years now and can safely be assumed
that there's no longer any need for it, reducing ~5K packages'
dependency in repository metadata on it during next rebuild.

See you
commit 12d6f89719c06e05ca186ade116608f7ba60c8ae
Author: Thierry Vignaud thierry.vign...@gmail.com
Date:   Tue Sep 16 14:52:06 2014 +0200

drop rtld(GNU_HASH) hack

Drop automatically generated rtld(GNU_HASH) dependencies.
It's been provided by glibc for 7 years now and can safely be assumed
that there's no longer any need for it, reducing ~5K packages'
dependency in repository metadata on it during next rebuild.

basically reverting commit 8b8e27ec

diff --git a/lib/tagexts.c b/lib/tagexts.c
index 0d2b1d3..2d20fd5 100644
--- a/lib/tagexts.c
+++ b/lib/tagexts.c
@@ -735,6 +735,27 @@ static int epochnumTag(Header h, rpmtd td, headerGetFlags 
hgflags)
 return 1;
 }
 
+static int depnameTag(Header h, rpmtd td, headerGetFlags hgflags,
+   rpmTagVal tag)
+{
+rpmds ds = rpmdsNew(h, tag, 0);
+int ndeps = rpmdsCount(ds);
+
+if (ndeps  0) {
+   char **deps = xmalloc(sizeof(*deps) * ndeps);
+   int i;
+   while ((i = rpmdsNext(ds)) = 0) {
+   deps[i] = rpmdsN(ds);
+   }
+   td-data = deps;
+   td-type = RPM_STRING_ARRAY_TYPE;
+   td-count = ndeps;
+   td-flags |= (RPMTD_ALLOCED | RPMTD_PTR_ALLOCED);
+}
+rpmdsFree(ds);
+return (ndeps  0);
+}
+
 static int depnevrsTag(Header h, rpmtd td, headerGetFlags hgflags,
rpmTagVal tag)
 {
@@ -758,6 +779,32 @@ static int depnevrsTag(Header h, rpmtd td, headerGetFlags 
hgflags,
 
 #define RPMSENSE_STRONG (1  27)
 
+
+static int depnameTagFiltered(Header h, rpmtd td, headerGetFlags hgflags,
+   rpmTagVal tag, int strong)
+{
+rpmds ds = rpmdsNew(h, tag, 0);
+int ndeps = rpmdsCount(ds);
+
+if (ndeps  0) {
+   char **deps = xmalloc(sizeof(*deps) * ndeps);
+   ndeps = 0;
+   while (rpmdsNext(ds) = 0) {
+   if ((rpmdsFlags(ds)  RPMSENSE_STRONG) == (strong ? RPMSENSE_STRONG 
: 0))
+   deps[ndeps++] = rpmdsN(ds);
+   }
+   if (ndeps) {
+   td-data = deps;
+   td-type = RPM_STRING_ARRAY_TYPE;
+   td-count = ndeps;
+   td-flags |= (RPMTD_ALLOCED | RPMTD_PTR_ALLOCED);
+   } else {
+   _free(deps);
+}
+}
+rpmdsFree(ds);
+return (ndeps  0);
+
 static int depnevrsTagFiltered(Header h, rpmtd td, headerGetFlags hgflags,
rpmTagVal tag, int strong)
 {
@@ -789,6 +836,12 @@ static int requirenevrsTag(Header h, rpmtd td, 
headerGetFlags hgflags)
 return depnevrsTag(h, td, hgflags, RPMTAG_REQUIRENAME);
 }
 
+static int recommendnameTag(Header h, rpmtd td, headerGetFlags hgflags)
+{
+return depnameTag(h, td, hgflags, RPMTAG_RECOMMENDNAME) ||
+   depnameTagFiltered(h, td, hgflags, RPMTAG_OLDSUGGESTSNAME, 0);
+}
+
 static int recommendnevrsTag(Header h, rpmtd td, headerGetFlags hgflags)
 {
 return depnevrsTag(h, td, hgflags, RPMTAG_RECOMMENDNAME) ||
@@ -875,6 +928,7 @@ static const struct headerTagFunc_s 
rpmHeaderTagExtensions[] = {
 { RPMTAG_EPOCHNUM, epochnumTag },
 { RPMTAG_INSTFILENAMES,instfilenamesTag },
 { RPMTAG_REQUIRENEVRS, requirenevrsTag },
+{ RPMTAG_RECOMMENDNAME,recommendnameTag},
 { RPMTAG_RECOMMENDNEVRS,   recommendnevrsTag},
 { RPMTAG_SUGGESTNEVRS, suggestnevrsTag},
 { RPMTAG_SUPPLEMENTNEVRS,  supplementnevrsTag},
diff --git a/tools/elfdeps.c b/tools/elfdeps.c
index cf22cc6..5a25090 100644
--- a/tools/elfdeps.c
+++ b/tools/elfdeps.c
@@ -306,14 +306,6 @@ static int processFile(const char *fn, int dtype)
 }
 
 /*
- * For DSOs which use the .gnu_hash section and don't have a .hash
- * section, we need to ensure that we have a new enough glibc.
- */
-if (ei-isExec  ei-gotGNUHASH  !ei-gotHASH  !soname_only) {
-   argvAdd(ei-requires, rtld(GNU_HASH));
-}
-
-/*
  * For DSOs, add DT_SONAME as provide. If its missing, we can fake
  * it from the basename if requested. The bizarre looking DT_DEBUG
  * check is used to avoid adding basename provides for PIE executables.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] drop interpreter deps when already handled

[Thierry Vignaud]

Hi

The attached patch drops interpreter deps when already handled:

Drop automatically generated dependencies on interpreters we either
don't need dependencies on or that we have other dedicated dependency
generators for making them duplicate, reducing ~5K packages'
dependencies in repository metadata on next rebuild:
- perl/python: we already have dedicated dependency generators for these

Those are basically duplicates (and replacing file deps by requires on
regular provides is good IMHO).

Note that Mageia also drop requires on other but I don't submit them b/c:
- ruby: dedicated dependency generator is not upstream
- /bin/sh  /bin/bash: we really don't need to add these dependencies as
  they're required by glibc and therefore guaranteed to be satisfied
  This is not true for most distros that don't have a /bin/sh scriptlet


See you
commit db0df477f5a44ea5aa9c2ace7e7370c647f54d2d
Author: Thierry Vignaud thierry.vign...@gmail.com
Date:   Tue Sep 16 15:00:23 2014 +0200

drop interpreter deps when already handled

Drop automatically generated dependencies on interpreters we either
don't need dependencies on or that we have other dedicated dependency
generators for making them duplicate, reducing ~5K packages'
dependencies in repository metadata on next rebuild:
- perl/python: we already have dedicated dependency generators for these

Note that Mageia also drop requires on:
- ruby: dedicated dependency generator is not upstream
- /bin/sh  /bin/bash: we really don't need to add these dependencies as
  they're required by glibc and therefore guaranteed to be satisfied

diff --git a/scripts/script.req b/scripts/script.req
index 950dc4a..2375a6d 100755
--- a/scripts/script.req
+++ b/scripts/script.req
@@ -1,9 +1,21 @@
 #!/bin/sh
 
+BLACKLIST=bin/(perl|python)
+
 # TODO: handle #!/usr/bin/env foo somehow
 while read filename; do
 # common cases 
-sed -n -e '1s:^#![[:space:]]*\(/[^[:space:]]\{1,\}\).*:\1:p' $filename
+INTERP=$(sed -n -e '1s:^#![[:space:]]*\(/[^[:space:]]\{1,\}\).*:\1:p' 
$filename)
+if echo $INTERP|grep -E $BLACKLIST /dev/null; then
+   # drop automatically generated dependencies on interpreters we 
either don't
+   # need dependencies on or that we have other dedicated dependency 
generators
+   # for making them duplicate, reducing ~5K packages' dependencies at
+   # next rebuild.
+   # - perl/python: we already have dedicated dependency generators 
for these
+   :
+else
+   echo $INTERP
+fi
 #!/usr/bin/env /foo/bar
 sed -n -e 
'1s:^#![[:space:]]*[^[:space:]]*/bin/env[[:space:]]\{1,\}\(/[^[:space:]]\{1,\}\):\1:p'
 $filename
 done
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] perl.{prov,req} improvments

[Thierry Vignaud]

Hi

Mageia just switched to internal deps generator (at least).
In the process, I unforked as most scripts as possible.
Here's some old fixes:

skip-plain-regular-comments.diff:
just skip plain, regular perl comments...

support-for-_-in-perl-module-version.diff:
support for _ in perl module version
commit 2af13ef2dccbe7c3dc88b4f2b5a5329f0e135a99
Author: Jérôme Quelin jque...@mandriva.org
Date:   Fri Mar 12 17:22:23 2010 +

skip plain, regular comments. how comes this has not been spotted earlier? 
(sigh)

diff --git a/scripts/perl.prov b/scripts/perl.prov
index 8f5d53b..3113cb2 100755
--- a/scripts/perl.prov
+++ b/scripts/perl.prov
@@ -117,7 +117,7 @@ sub process_file {
   $inover = 0;
 }
 
-if ($incomment || $inover) {
+if ($incomment || $inover || m/^\s*#/) {
next;
 }
 
commit 0f1dd7bebbea6916dc5d698099a8a4cbfb829e81
Author: Jerome Quelin jque...@mageia.org
Date:   Sat Feb 26 12:04:53 2011 +

1.118 - support for _ in perl module version

diff --git a/scripts/perl.prov b/scripts/perl.prov
index a6d68bb..85b8e81 100755
--- a/scripts/perl.prov
+++ b/scripts/perl.prov
@@ -171,7 +171,7 @@ sub process_file {
 
   if (m/\$Revision: (\d+[.0-9]+)/) {
 $version = $1;
-  } elsif (m/[']?(\d+[.0-9]+)[']?/) {
+  } elsif (m/[']?(\d+[._0-9]+)[']?/) {
 
 # look for a static number hard coded in the script
 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] speeding up internal deps generator

[Thierry Vignaud]

Hi

We've recently switched to internal deps generator.

However one of the deps scripts we use [1] is very slow b/c of this[2]:

 +for path in \
+$(for tlpath in \
+$(find ${RPM_BUILD_ROOT}/usr/lib64 ${RPM_BUILD_ROOT}/usr/lib
/usr/lib64 /usr/lib -name '*.typelib'); do
+dirname $tlpath; done | uniq ); do
+export GI_TYPELIB_PATH=$GI_TYPELIB_PATH:$path
+done

Previously, it was run once (with so called external deps generator).
With internal deps generator, rpm forks it for every matching file.
When lots of files match, this is very slow as it runs tons of find
for every matching file.

This could be workarounded if internal deps generator could offer a
new flag (instead of just exeonly  magic_and_path ) that, if
found in the .attr file, would make rpm to call the script just once
with the whole list of files instead of calling it once per file.
It could be named all_in_one, fork_once_only, or whatever.

This would be helpfull for most packages builds as most of standard
prov/req scripts already handle more than on file name and thus could
use this new flag.

WDYT?

[1] 
https://build.opensuse.org/package/view_file/openSUSE:Factory/gobject-introspection/gi-find-deps.sh?expand=1
[2] 
https://build.opensuse.org/package/rdiff/openSUSE:Factory/gobject-introspection?linkrev=baserev=36
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 rc1 released

[Thierry Vignaud]

On 27 August 2014 08:44, Panu Matilainen pmati...@redhat.com wrote:

 As usual, the full details  download info are at

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

Hi
It looks like the following requires is no more emitted:
  rpmlib(PayloadIsXz) = 5.2-1
Note that I care much but is that intended?
See you
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 rc1 released

[Thierry Vignaud]

On 9 September 2014 12:07, Panu Matilainen pmati...@laiskiainen.org wrote:

 It looks like the following requires is no more emitted:
rpmlib(PayloadIsXz) = 5.2-1
 Note that I care much but is that intended?

 Sigh, that'd be yet another regression from the dependency refactoring
 between alpha and beta. Fixed by this:
 http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=cac311c2ddb43b62ad9dbdb5543d50848eb9fd65

 ...and needs to go into 4.12.0 final.

 Thanks for spotting and reporting!

Well just add one more test to the testsuite and it will never happen again ;-)
Like calling sg like rpm -qp --qf %{payloadcompressor} foobar.rpm
and checking its output the default payload compressor

As well as tests for the previous regressions that weren't covered
by the testsuite.
My 2 cents :-)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [Rpm-announce] RPM 4.11.3 released!

[Thierry Vignaud]

On 5 September 2014 14:56, Panu Matilainen pmati...@redhat.com wrote:
 This is a bugfix maintenance release to the 4.11.x series for an
 assortment of issues. Download information and further details are
 available at

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


 Argh. That's what you get from excessive copy-pasting of past announcements...

 That should obviosly be

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

You also forgot to update the git branch...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 rc1 released

[Thierry Vignaud]

On 27 August 2014 08:44, Panu Matilainen pmati...@redhat.com wrote:
 The beta turned out to be a bit of a disaster with several new regressions
 introduced, and then fixes to those regressions actually causing different
 As usual, the full details  download info are at

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

typo fix: s/previosly previously/ on that page...

also you should mention that %pretrans failures are no more silently
ignored (rhbug:736960)
(this affects urpmi testsuite)
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 rc1 released

[Thierry Vignaud]

On 27 August 2014 12:06, Panu Matilainen pmati...@laiskiainen.org wrote:
 That change went into rpm 4.10 already, http://rpm.org/wiki/Releases/4.10.0
 mentions:

 * %pretrans scriptlet failure now fails the install of the package
 (similarly to %pre and %preun semantics)

 The %pretrans change in 4.12 that might well affect a test-suite is:
 * Fix $1 argument to %pretrans, %posttrans and %verifyscript to behave like
 all other scripts

 Ie if you're testing that %pretrans (or the other two) scripts are always
 (incorrectly) receiving zero as the first argument, that could trip you up.

Sorry, a test was disabled on rpm-4.10+ but we failed to parse version string
with RC in it...

Else, for the record like beta1+patches, both  URPM  urpmi testsuite
patches after adapting to new weak tags.

Previously, we only handled suggests among the 4 weak deps tags (whereas
we should have used Recommends instead  we should have ignored Suggests)
so I'm considering switching from suggests to recommends as the only
tag supported by URPM/urpmi (with a mga specific patch for rpm that makes
recommendnevrsTag() try new RECOMMENDNAME then OLDSUGGESTSNAME
_without_ the strong hint).
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 beta1 released

[Thierry Vignaud]

On 26 August 2014 11:47, Panu Matilainen pmati...@laiskiainen.org wrote:
 Right... changing the error handling in Fclose() closer to what it was
 previously fixes this thing:

Thanks, I'll test.
Could you add a test to rpm's testsuite BTW?

 However AFAICS the original is broken for a different case (if the io is not
 stacked then an error from close would go unnoticed). Need to take a closer
 look I guess.

 In the meanwhile, 4.12 beta1 is pretty broken. Testing for things like this
 is good, but you dont want to distribute packages built with it, I'll try to
 put beta2 together tomorrow.

Don't fear, this remains in a local chroot, with your patches from FC.
This will never go in Mageia Cauldron's core/updates_testing repository without
first having URPM  urpmi testsuites to pass.
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] RPM 4.12.0 beta1 released

[Thierry Vignaud]

On 18 August 2014 10:44, Panu Matilainen pmati...@redhat.com wrote:
 As usual, the full details  download info are at

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

The attached program shows a regression that is affecting URPM.
Now Fclose() returns -2 in the same code path where rpm-4.11.x returned 0:


# RPM-4.11:
$ gcc -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
-fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall
-Wextra -fno-strict-aliasing -DRPM490 -O2 -g -pipe -Wformat
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
--param=ssp-buffer-size=4 -fPIC -lrpm -lrpmio -lrpmbuild t.c -o tt
./tt
Fclose() ==0
START=1; END=

# RPM-4.12:
$ ./tt
Fclose() ==-2
close() 1 = OK=0
NOT OK


(just put any compressed string in the target path.eg: echo toto
|xzt/synthesis.sample-xz.cz)

#include sys/utsname.h
#include sys/select.h
#include sys/time.h
#include sys/types.h
#include sys/stat.h
#include sys/wait.h
#include fcntl.h
#include unistd.h
#include libintl.h
#include stdio.h

#include string.h
#include stdlib.h
#include errno.h

#include rpm/rpmio.h
#include rpm/rpmdb.h
#include rpm/rpmts.h
#include rpm/rpmte.h
#include rpm/rpmps.h
#include rpm/rpmpgp.h
#include rpm/rpmcli.h
#include rpm/rpmbuild.h
#include rpm/rpmlog.h


// fix compiling (error: conflicting types for ‘fflush’):
#undef Fflush
#undef Mkdir
#undef Stat
#undef Fstat


int main () {
  char *filename = ./t/synthesis.sample-xz.cz;
  FD_t f = NULL;
  char *t;
  int start_id = 1;
  rpmCompressedMagic compressed = COMPRESSED_OTHER;

  int rc = rpmFileIsCompressed (filename, compressed);

  switch (compressed) {
  case COMPRESSED_BZIP2:
t = r.bzip2;
break;
  case COMPRESSED_LZMA:
  case COMPRESSED_XZ:
t = r.xz;
break;
  case COMPRESSED_OTHER:
  default:
t = r.gzip;
break;
  }
  f = Fopen (filename, r.fdio);

  int ok = 1;
  if (!rc  (f = Fdopen (f, t)) != NULL  !Ferror (f)) {
int res = Fclose (f);
fprintf (stderr, Fclose() ==%d\n, res);
if (res != 0) {
  ok = 0;
  fprintf (stderr, close() 1 = OK=0\n);
}
if (ok)
  printf (START=%d; END=\n, start_id);
else
  fprintf (stderr, NOT OK\n);
  }
}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] splitting packages

[Thierry Vignaud]

On 30 June 2014 15:52, Ales Kozumplik akozu...@redhat.com wrote:
 Hello people,

 this is about [1], i.e. the fact that DNF currently doesn't support an
 upgrade path where a package is split into several new packages. It would be
 better suited for yum-devel but I'm posting it here since Michael doesn't
 read yum-devel.

 There are two approaches to this out there that I know of: the Fedora way
 where N new packages obsolete the old package [2] [3]. When Yum sees this
 during 'yum upgrade' it installs all the N new pacakges and removes the old
 one. Note that the Fedora guidelines and even the Yum manual page are quite
 vague on the exact semantics of how splitting and renaming works. I'd be
 interested to find a better description somewhere.

 There is a different convention used in SUSE [4] that employs a special
 'split-alias' provide. Michael said in the bugzilla this is not a desirable
 approach.

 Before I try to come up with a proposal on fixing this, does somebody have a
 proposal at hand? Could supplements: or similar help? Are there reasons to
 move away from what Yum does (besides that using 'obsoletes:' is a bit
 random thing for it, i.e. I imagine it was more picked because it didn't
 break anything else in the RPM world than picked as a design decision)?

I think the appropriate ml would be DNF one, not this one...
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] The usage of basename()

[Thierry Vignaud]

On 18 August 2013 17:19, Kamil Rytarowski n...@gmx.com wrote:
 There are two main implementations of basename() in the GNU system, one is
 libgen.h and one from string.h (being accessible here as _GNU_SOURCE).
 Currently we do not support systems other than with GNU Lib C (except
 possible compatibility layers), because we assume the basename() is shipped
 with string.h.

 There is a fundamental question before adding a header of libgen.h: the
 POSIX standard explicitly allows to modify the input -- is it acceptable?

 Should be there a rewriten a xbasename() version of this function to make
 sure it's portable across systems?

See man basename or http://man7.org/linux/man-pages/man3/basename.3.html#BUGS :
BUGS
   In the glibc implementation of the POSIX versions of these
functions they modify their argument, and segfault when called with a
static string  like  /usr/.

And I can guaranty you from my previous experience with other non GNU libc
that the odds're very high that you'll indeed get strange segfaults
My 2 cents
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint