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, &tagflags)) {
+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, &data))
@@ -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 14:07, Igor Gnatenko
 wrote:
>> For the record
>> BTW, the latest issue I've with rpm-4.14 is that its testsuite has
>> several debugsources related failures  when building it with rpm-4.14
>> tpoo
>> http://pkgsubmit.mageia.org/uploads/done/cauldron/core/release/201710
>> 05114000.tv.duvel.20120/rpm-4.14.0-
>> 0.rc2.4.mga7/build.0.20171005114003.log
>> Have you tried building rpm-4.14 with rpm-4.14?
> I think the problem is that you have enabled producing debugsource in
> RPM while we have it in redhat-rpm-config in Fedora. I've seen same
> failures when I tried to enable debugsource packages directly in RPM...

Nope.
It's not enabled in rpm but it is in the pkg equivalent to
redhat-rpm-config (rpm-mageia-setup), which is installed by default in
build chroots
After all we do want rpm-debugsource
Also di
___
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  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,
>>>>>>>> &h));
>>>>>>>> +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, &h, -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, &h));
>>>>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>>>>> headerLink(h)));
>>>>>>#ifdef HDRPMMEM
>>>>>> -PRINTF_NEW(bless_header, &h, -1);
>>>>>> +PRINTF_NEW(bless_header, h, -1);
>>>>>>#endif
>>>>>>}
>>>>>>break;
>>>>>>
>>>>>>   - Panu -
>>>>>>
>>>>>
>>>>> Thanks
>>>>> Now remains the issue with severa

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,
>>> &h));
>>> +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, &h, -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, &h));
> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
> headerLink(h)));
>#ifdef HDRPMMEM
> -PRINTF_NEW(bless_header, &h, -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, &h));
> +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, &h, -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, &h));
>>> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
>>> headerLink(h)));
>>>   #ifdef HDRPMMEM
>>> -PRINTF_NEW(bless_header, &h, -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, &h));
>>> +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, &h, -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, &h));
> +mXPUSHs(sv_setref_pv(newSVpvs(""), bless_header,
> headerLink(h)));
>  #ifdef HDRPMMEM
> -PRINTF_NEW(bless_header, &h, -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  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 depend o

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

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 where the perl interpre

[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} / 
$a{total}\n" }) == 

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  wrote:
> On 10/02/2017 11:54 PM, Thierry Vignaud wrote:
>>
>> On 2 October 2017 at 15:08, Panu Matilainen  wrote:
>>>>>>
>>>>>> perl-RPM4's testsuite seems to have caught a regression:
>>>>>> Simulating several simulate rpm -bi in a row now fails with:
>>>>>> error: Wrong number of entries for tag Filemodes: 2 found but 1
>>>>>> expected.
>>>>>>
>>>>>> As a workaround, we've to reload the spec file between 2 tests:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://svnweb.mageia.org/packages/cauldron/perl-RPM4/current/SOURCES/reload-spec-file-before-builds.patch?revision=1143572&view=markup
>>>>>>
>>>>>> I've attached the output of erl t/04spec.t with & w/o this patch
>>>>>>
>>>>>
>>>>> Wild guess: debuginfo link creation.
>>>>>
>>>>> Does setting %_build_id_links to "none" or "alldebug" make the issue go
>>>>> away?
>>>
>>>
>>>
>>> ...without the actual quotes, that is.
>>>
>>>>
>>>> None of that fixes it
>>>
>>>
>>>
>>> So what is the extra entry that's getting added then?
>>>
>>>  - Panu -
>>
>>
>> That's in the logs:
>> "error: Wrong number of entries for tag Filemodes: 2 found but 1
>> expected."
>> This cames from lib/rpmfi.c 's _hgfi()
>
>
> Yes I saw the log, there's an unexpected file entry in there. And I'm asking
> *what* that unexpected *file* is - it's path you know :)
>
> I'm fairly positive it's an intentionally added debuginfo thing and thus
> notabug, but until proven...
>
> - Panu -

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

I think you overshot what I initially said: the test works fine if the
spec file is reloaded.
Or if the test is only done once. Repeating the same test will just got:

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

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

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

[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  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  0x003f512e2c41 in Pe

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  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:08, Panu Matilainen  wrote:
 perl-RPM4's testsuite seems to have caught a regression:
 Simulating several simulate rpm -bi in a row now fails with:
 error: Wrong number of entries for tag Filemodes: 2 found but 1
 expected.

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


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

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

>>>
>>> Wild guess: debuginfo link creation.
>>>
>>> Does setting %_build_id_links to "none" or "alldebug" make the issue go
>>> away?
>
>
> ...without the actual quotes, that is.
>
>>
>> None of that fixes it
>
>
> So what is the extra entry that's getting added then?
>
> - Panu -

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

Thus this cames from rpmfilesPopulate():
lib/rpmfi.c:1533:   _hgfi(h, RPMTAG_FILEMODES, &td, scareFlags, fi->fmodes);
___
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  wrote:
> On 10/02/2017 12:20 PM, Thierry Vignaud wrote:
>>
>> On 28 September 2017 at 16:06, Panu Matilainen 
>> wrote:
>>>
>>>
>>> There aren't that many changes since rc1, but enough to warrant a second
>>> release candidate instead of going for final. The important ones being:
>>>
>>> - Fix a bug of file triggers failing on some packages (MgBug:18797, in
>>> 4.13.x already)
>>> - Fix a regression on 32bit architectures on generation of packages over
>>> 2GB
>>> in size (RhBug:1492587)
>>> - Fix rpm following arbitrary directory symlinks on installation
>>> (CVE-2017-7500)
>>> - Fix rpm following symlinks on file creation (CVE-2017-7501)
>>> - Adjust verification to match the new directory symlink rule
>>> - Forbid 'if' richops in 'or' context and 'unless' richops in 'and'
>>> context
>>>
>>> As usual, the details + download info at:
>>>
>>>  http://rpm.org/wiki/Releases/4.14.0
>>>
>>> Oh and release notes changed to use SHA256 instead of SHA1 for the source
>>> checksum. Guess it's about time.
>>
>>
>> perl-RPM4's testsuite seems to have caught a regression:
>> Simulating several simulate rpm -bi in a row now fails with:
>> error: Wrong number of entries for tag Filemodes: 2 found but 1 expected.
>>
>> As a workaround, we've to reload the spec file between 2 tests:
>>
>> http://svnweb.mageia.org/packages/cauldron/perl-RPM4/current/SOURCES/reload-spec-file-before-builds.patch?revision=1143572&view=markup
>>
>> I've attached the output of erl t/04spec.t with & w/o this patch
>>
>
> Wild guess: debuginfo link creation.
>
> Does setting %_build_id_links to "none" or "alldebug" make the issue go
> away?

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&view=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&view=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 21 October 2016 at 08:51, Panu Matilainen  wrote:

>>> 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)
>
>
> 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 :-)

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

>> 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.
## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
277. rpmpython.at:70: testing spec parse ...
./rpmpython.at:70:
cat << EOF > test.py
import rpm, sys
dbpath=rpm.expandMacro('%_dbpath')
rpm.addMacro('_dbpath', '${abs_builddir}/testing%s' % dbpath)
def myprint(msg = ''):
sys.stdout.write('%s\n' % msg)

# TODO: add a better test spec with sub-packages etc
spec = rpm.spec('${RPMDATA}/SPECS/hello.spec')
for (name, num, flags) in spec.sources:
myprint('src %s %d %d' % (name, num, flags))
for pkg in spec.packages:
myprint(pkg.header.format('%{nvr}'))
myprint(spec.sourceHeader.format('%{nvr}'))

EOF
python test.py

--- -   2016-10-21 10:36:41.596671971 +0200
+++ 
/home/tv/mga/pkgs/rpm/BUILD/rpm-4.13.0-rc2/tests/rpmtests.dir/at-groups/277/stdout
  2016-10-21 10:36:41.593694885 +0200
@@ -1,5 +1,6 @@
 src hello-1.0-modernize.patch 0 2
 src hello-1.0.tar.gz 0 1
 hello-1.0-1
+hello-debuginfo-1.0-1
 hello-1.0-1
 
277. rpmpython.at:70: 277. spec parse (rpmpython.at:70): FAILED 
(rpmpython.at:70)


0001-fix-calling-sepdebugcrcfix.patch
Description: application/binary


0001-fix-testsuite-adjust-pkg-list.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 4.13.0 rc2 released

[Thierry Vignaud]

On 20 October 2016 at 15:32, Panu Matilainen  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 
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] %setup for RubyGems

[Thierry Vignaud]

On 19 October 2016 at 13:24, Pascal Terjan  wrote:
>>> 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&view=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)
>> So in reality you did not get the sources calling the %setup macro, you
>> actually unpacked just the first level archive and unpacking of the
>> second level archive is handled by %gem_setup, right? The 'gem unpack'
>> in upstream patch does this in single step.
>>
>> And I'd say that you should be able to simplify the %gem_setup macro
>> even more, since the lines:
>>
>> ```
>>  if [ ! -f %{gem_name}.gemspec ]; then \
>>  %{_bindir}/gem specification -l --ruby %{SOURCE0} > 
>> %{gem_name}.gemspec \
>>  fi \
>> ```
>>
>> are covered by RPM now, as can be seen in your log:
> Yes that's good
>
>> ```
>> ++ /usr/bin/gem spec 
>> /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem --ruby
>> ```
>>
>> vs
>>
>> ```
>>  + /usr/bin/gem specification -l --ruby 
>> /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem
>> ```
>>
>>
>> Actually, the log itself would be more useful, since I suspect that in
>> the %build section, you rebuild the gem, which is using the .gemspec
>> file somewhere, but that was stripped out from the diff.
> Yes and actually we have the code twice for the gemspec...
>
> -14: gem_build
> if [ ! -f %{gem_name}.gemspec ]; then
>%{_bindir}/gem specification -l --ruby %{SOURCE0} > 
> %{gem_name}.gemspec
> fi
> %{_bindir}/gem build %{gem_name}.gemspec
 Yes, I can see that in [1] now. You should be good to simplify the
 %gem_build to:

 ```
 %gem_build \
 %{_bindir}/gem build ../%{gem_name}-%{version}.gemspec
 ```

 These were the changes I proposed for Fedora [2].

 Please note that the .gemspec file one directory level above the sources
 has the advantage, that it does not collide with .gemspec, which might
 be shipped with the gem itself and it is always completely different
 from the generated .gemspec.
>>> Yes that's true, even if I have never noticed a gem containing a
>>> versioned gemspec name so far
>>>
>>
>> I just realized, that with the upstream patch, you can even drop the sed
>> from %gem_setup, since the .gemspec extracted from .gem file never
>> contains any "git ls-files" entries. Not sure about the version though.
>
> Yes I realized that too, for some reason I believed we were using a
> versioned gemspec but we are not and sometimes use the provided one
> which is the source of all the hacks :)
>
>> So how is your testing going? ;)
>
> I didn't have time to look into it, Thierry would you mind switching
> to that patch in our package?
> I can update the rubygems.macros tonight and try to rebuild everything
> + check the packages tomorrow

Done in rpm-4.13.0-0.rc1.36.mga6
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] %setup for RubyGems

[Thierry Vignaud]

On 19 October 2016 at 15:30, Thierry Vignaud  wrote:
> On 19 October 2016 at 13:24, Pascal Terjan  wrote:
>>>>>>>> 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&view=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)
>>>>>>> So in reality you did not get the sources calling the %setup macro, you
>>>>>>> actually unpacked just the first level archive and unpacking of the
>>>>>>> second level archive is handled by %gem_setup, right? The 'gem unpack'
>>>>>>> in upstream patch does this in single step.
>>>>>>>
>>>>>>> And I'd say that you should be able to simplify the %gem_setup macro
>>>>>>> even more, since the lines:
>>>>>>>
>>>>>>> ```
>>>>>>>  if [ ! -f %{gem_name}.gemspec ]; then \
>>>>>>>  %{_bindir}/gem specification -l --ruby %{SOURCE0} > 
>>>>>>> %{gem_name}.gemspec \
>>>>>>>  fi \
>>>>>>> ```
>>>>>>>
>>>>>>> are covered by RPM now, as can be seen in your log:
>>>>>> Yes that's good
>>>>>>
>>>>>>> ```
>>>>>>> ++ /usr/bin/gem spec 
>>>>>>> /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem --ruby
>>>>>>> ```
>>>>>>>
>>>>>>> vs
>>>>>>>
>>>>>>> ```
>>>>>>>  + /usr/bin/gem specification -l --ruby 
>>>>>>> /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem
>>>>>>> ```
>>>>>>>
>>>>>>>
>>>>>>> Actually, the log itself would be more useful, since I suspect that in
>>>>>>> the %build section, you rebuild the gem, which is using the .gemspec
>>>>>>> file somewhere, but that was stripped out from the diff.
>>>>>> Yes and actually we have the code twice for the gemspec...
>>>>>>
>>>>>> -14: gem_build
>>>>>> if [ ! -f %{gem_name}.gemspec ]; then
>>>>>>%{_bindir}/gem specification -l --ruby %{SOURCE0} > 
>>>>>> %{gem_name}.gemspec
>>>>>> fi
>>>>>> %{_bindir}/gem build %{gem_name}.gemspec
>>>>> Yes, I can see that in [1] now. You should be good to simplify the
>>>>> %gem_build to:
>>>>>
>>>>> ```
>>>>> %gem_build \
>>>>> %{_bindir}/gem build ../%{gem_name}-%{version}.gemspec
>>>>> ```
>>>>>
>>>>> These were the changes I proposed for Fedora [2].
>>>>>
>>>>> Please note that the .gemspec file one directory level above the sources
>>>>> has the advantage, that it does not collide with .gemspec, which might
>>>>> be shipped with the gem itself and it is always completely different
>>>>> from the generated .gemspec.
>>>> Yes that's true, even if I have never noticed a gem containing a
>>>> versioned gemspec name so far
>>>>
>>>
>>> I just realized, that with the upstream patch, you can even drop the sed
>>> from %gem_setup, since the .gemspec extracted from .gem file never
>>> contains any "git ls-files" entries. Not sure about the version though.
>>
>> Yes I realized that too, for some reason I believed we were using a
>> versioned gemspec but we are not and sometimes use the provided one
>> which is the source of all the hacks :)
>>
>>> So how is your testing going? ;)
>>
>> I didn't have time to look into it, Thierry would you mind switching
>> to that patch in our package?
>> I can update the rubygems.macros tonight and try to rebuild everything
>> + check the packages tomorrow
>
> Done in rpm-4.13.0-0.rc1.36.mga6

Argh, it's rpm-4.13.0-0.rc1.37.mga6
___
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
> 4.13.1.
>
> Anyway, the list a

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

[Thierry Vignaud]

On 17 October 2016 at 11:42, Panu Matilainen  wrote:
> On 10/17/2016 12:30 PM, Thierry Vignaud wrote:
>>
>> On 17 October 2016 at 10:10, Panu Matilainen 
>> 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&pathrev=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&view=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  wrote:
> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
>> On 17 October 2016 at 10:10, Panu Matilainen  
>> 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&pathrev=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&view=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&view=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 gemc

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

[Thierry Vignaud]

On 17 October 2016 at 10:10, Panu Matilainen  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&pathrev=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&view=markup

But if it works the same, Mageia will be happy to drop one more patch :-)

See you
___
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:

(...)

> 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 7 June 2016 at 11:50, 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
>
> Could you provide a small example? From the bug report it isn't clear if
> it really is a bug with that particular fix or that it is caused by bad
> usage of attributes. If we have a small example we can create a test
> case for it.

Here's one example attached.
With current FC patch applied to rpm (aka uncommenting the patch at
http://svnweb.mageia.org/packages/cauldron/rpm/current/SPECS/rpm.spec?revision=1018103&view=markup#l116)

With "%define debug_package %{nil}", "ll /bin/test2" shows:
-rwsr-xr-x 1 root root 6128 Eve  13 13:56 /bin/test2*
With "#define debug_package %{nil}", "ll /bin/test2" shows:
-rwxr-xr-x 1 root root 7184 Eve  13 13:55 /bin/test2*

When the rpm patch is not applied, both cases works OK (aka ls -[ol]
reports the suid bit)

>> 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
>
> I am missing some context here. But it reads like if you don't use dwz
> support then it doesn't fix any real issue. So, then you can drop that
> patch also. Which is true.
>
> But you do seem to use compressed debuginfo packages. In which case it
> does fix a real issue. The issue is that if you create .debug files
> with .gnu_debuglink support then you need to make sure that the CRC is
> calculated correctly.  I included a testcase to show what that issue is
> (the testcase will fail without the patch applied).

According to Panu, "t only affects a handful of toolchain developers
in the entire world" whereas it does break havoc here...

> Also note that one of the goals of improving and cleaning up debuginfo
> packages is so more people can easily use them, in which case it will
> impact more than just a few hackers that manage to get them properly
> installed.

I don't argue against that :-)
I'm just stating that the FC patch breaks suid here...
If suid bit is explicitely listed as %attr(...), it works as rpm enforces it.
But if it has been set by install/chmod/... then it's lost when
generating debuginfo with that patch

I would like for this to be fixed before the patch is merged :-)
You can add the attached test.spec to the testsuite
# If the next line is uncommented, "ll /bin/test2" shows:
#-rwsr-xr-x 1 root root 6128 Eve  13 13:56 /bin/test2*
# If it's commented out (s/%/#/), "ll /bin/test2" shows:
#-rwxr-xr-x 1 root root 7184 Eve  13 13:55 /bin/test2*
#define debug_package %{nil}

Name:		test
Version:	1
Release:	1.3
Summary:	test
License:	test
Group:		test
Source0:	test.c

%description
Test


%prep
%setup -c -T

%build
gcc %{SOURCE0} -o test2 %{optflags}

%install
mkdir -p %buildroot/usr/bin/
install -m 4755 test2 %buildroot/usr/bin/

%files
/usr/bin/test2

___
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  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] [PATCH v9 09/13] Add file signature support to package signing

[Thierry Vignaud]

On 21 July 2015 at 19:00, Fionnuala Gunter  wrote:
> From: "f...@linux.vnet.ibm.com" 
>
> 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
[tv@localhost RPM4-0.35]$ PERL5DIR=`pwd`/src/blib/arch  PERL_DL_NONLAZY=1 gdb 
-q --args perl  "-MExtUtils::Command::MM" "-MTest::Harness" t/06sign.t
Reading symbols from perl...Reading symbols from 
/usr/lib/debug/usr/bin/perl5.22.2.debug...done.
done.
(gdb) r
Starting program: /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness 
t/06sign.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
1..6

Program received signal SIGSEGV, Segmentation fault.
rpmPkgSign (path=path@entry=0x61f560 
"/tmp/6QmUdYmV8k/test-rpm-1.0-1mdk.noarch.rpm", args=args@entry=0x0) at 
rpmgensig.c:873
873 rc = rpmSign(path, 0, args->signfiles);
Missing separate debuginfos, use: debuginfo-install 
lib64bzip2_1-1.0.6-9.mga6.x86_64 lib64db5.3-5.3.28-10.mga6.x86_64 
lib64elfutils1-0.166-1.mga6.x86_64 lib64icu56-56.1-3.mga6.x86_64 
lib64lua5.2-5.2.3-9.mga6.x86_64 lib64lzma5-5.2.2-3.mga6.x86_64 
lib64magic1-5.25-4.mga6.x86_64 lib64ncurses6-6.0-5.mga6.x86_64 
lib64ncursesw6-6.0-5.mga6.x86_64 lib64nspr4-4.12-1.mga6.x86_64 
lib64nss3-3.23.0-1.mga6.x86_64 lib64nss-mdns2-0.10-16.mga6.x86_64 
lib64popt0-1.16-13.mga6.x86_64 lib64readline6-6.3-9.mga6.x86_64 
lib64rpmconstant0-0.1.4-7.mga6.x86_64 lib64sqlite3_0-3.12.2-1.mga6.x86_64 
lib64zlib1-1.2.8-9.mga6.x86_64 libgcc1-5.3.1-0.20160503.1.mga6.x86_64 
libstdc++6-5.3.1-0.20160503.1.mga6.x86_64 
perl-Digest-SHA1-2.130.0-18.mga6.x86_64
(gdb) bt
#0  rpmPkgSign (path=path@entry=0x61f560 
"/tmp/6QmUdYmV8k/test-rpm-1.0-1mdk.noarch.rpm", args=args@entry=0x0) at 
rpmgensig.c:873
#1  0x70f2c1da in rpmsign (passphrase=passphrase@entry=0xcbec00 "RPM4", 
rpm=rpm@entry=0x61f560 "/tmp/6QmUdYmV8k/test-rpm-1.0-1mdk.noarch.rpm") at 
RPM4.xs:475
#2  0x70f2c30a in XS_RPM4_rpmresign (my_perl=, 
cv=) at RPM4.xs:862
#3  0x0031564d4bda in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:3272
#4  0x0031564cdb46 in Perl_runops_standard (my_perl=0x603010) at run.c:41
#5  0x00315645b0d9 in S_run_body (oldscope=1, my_perl=0x603010) at 
perl.c:2448
#6  perl_run (my_perl=0x603010) at perl.c:2371
#7  0x00400e29 in main (argc=4, argv=0x7fffd9a8, 
env=0x7fffd9d0) at perlmain.c:116



0001-fix-segfault-when-calling-with-args-NULL.patch
Description: application/binary
___
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 10 January 2016 at 10:35, Thierry Vignaud  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
>
> I've fixed this.
> I've replaced the 3rd patch in the serie by this one which seems to
> work smoothly in my tests

I've created pull requests #42 (for rpm-4.13.x branch) & #43 (for master)
___
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 22:48, Thierry Vignaud  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

I've fixed this.
I've replaced the 3rd patch in the serie by this one which seems to
work smoothly in my tests


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] broken filetriggers implementation when using a chroot

[Thierry Vignaud]

On 9 January 2016 at 02:56, Thierry Vignaud  wrote:
> On 6 January 2016 at 12:42, Thierry Vignaud  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  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

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

[Thierry Vignaud]

Hi

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:

Example: we've a ldconfig file trigger in glibc package:

$ rpm -q --filetriggers glibc
transfiletriggerin scriptlet (using /bin/sh) -- /lib/, /lib64/
grep -F '.so.' | ldconfig -X
transfiletriggerin scriptlet (using /bin/sh) -- /etc/ld.so.conf.d/
ldconfig -X


Let's test in a chroot with and without /sbin/ldconfig out of the chroot:
mkdir TL2
mv /sbin/ldconfig{,.tv}; urpmi --no-recommends --root TL2
basesystem-minimal 2>&1|tee LOG.chroot2
mkdir TL1
mv /sbin/ldconfig{.tv,}; urpmi --no-recommends --root TL1
basesystem-minimal 2>&1|tee LOG.chroot1
diff -u LOG.chroot?|grep -1 ldconfig >ldconf.diff

I've attached the resulting diff: you can see that when the program
used by the filetrigger doesn't exist _OUT_ of the chroot (whereas it
does exists _in_ the chroot), we got failures:

+   28/166: lib64archive13#
+/var/tmp/rpm-tmp.Czkj2B: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed,
exit status 127
--
+   36/166: lib64cap2 #
+/var/tmp/rpm-tmp.UNaOEz: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed,
exit status 127

BTW, the error message is slightly misleading.
"%filetriggerin" would be better instead of "%triggerin"


Same way, if I install in a chroot but remove ldconfig right after the
transaction where glibc was installed, there's not failed ldconfig
calls...

Checking with strace when installing in /rpm/TL3 chroot:

$ egrep 'chroot|ldconfig' LOG
(...)
chroot("/root/TL3/")= 0
chroot(".") = 0
write(31, "grep -F '.so.' | ldconfig -X", 28) = 28
[pid  3783] read(3, "grep -F '.so.' | ldconfig -X", 80) = 28
[pid  3783] read(255, "grep -F '.so.' | ldconfig -X", 28) = 28
[pid  3785] stat("/sbin/ldconfig", {st_mode=S_IFREG|0755,
st_size=939032, ...}) = 0
[pid  3785] stat("/sbin/ldconfig",  
[pid  3785] access("/sbin/ldconfig", X_OK 
[pid  3785] stat("/sbin/ldconfig",  
[pid  3785] access("/sbin/ldconfig", R_OK 
[pid  3785] stat("/sbin/ldconfig",  
[pid  3785] stat("/sbin/ldconfig",  
[pid  3785] access("/sbin/ldconfig", X_OK 
[pid  3785] stat("/sbin/ldconfig",  
[pid  3785] access("/sbin/ldconfig", R_OK 
[pid  3785] execve("/sbin/ldconfig", ["ldconfig", "-X"], [/* 41 vars
*/] 
(...)

=> indeed we left the chroot _before_ running the filetriggers...

So rpm calls ldconfig from outside the chroot instead of in the choot
(unlike old regular triggers or %pre/%post/... scriptlets) which
breaks DVD installer...

Those do get called in the chroot. eg:

$ egrep 'chroot|execve' LOG|grep -v curl
(...)
chroot("/root/TL3/")= 0
[pid  3782] execve("/bin/sh", ["/bin/sh", "/var/tmp/rpm-tmp.iv2rlk",
"1"], [/* 42 vars */]) = 0
chroot(".") = 0

Can you suggest a fix?

Thanks
+   28/166: lib64archive13#
+/var/tmp/rpm-tmp.Czkj2B: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+   36/166: lib64cap2 #
+/var/tmp/rpm-tmp.UNaOEz: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+   44/166: lib64gmp10#
+/var/tmp/rpm-tmp.hWL3YH: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+   52/166: lib64cap-ng0  #
+/var/tmp/rpm-tmp.Q7gwjb: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+   60/166: lib64pam_userpass1#
+/var/tmp/rpm-tmp.IoeveR: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+   76/166: perl-MDK-Common   #
+/var/tmp/rpm-tmp.kzFdPg: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
--
+  130/166: initscripts   #
+/var/tmp/rpm-tmp.9kxUv9: line 1: ldconfig: command not found
+warning: %triggerin(glibc-6:2.22-13.mga6.x86_64) scriptlet failed, exit status 
127
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/

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] really default to default XZ compression level

[Thierry Vignaud]

Hi

This patches makes rpm really default to default XZ compression level

BTW this fixes the default compression level which is 6 instead of 7.

See you


0007-really-default-to-default-XZ-compression-level.patch
Description: Binary data
___
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] allow having "identical" trans file triggers

[Thierry Vignaud]

Hi

This patch allows to have having "identical" trans file triggers

Without it, rpm exits on a assert() if two file triggers traps on the same path:
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.

What's more it leaves rpmdb in a bad state...

Last but not least, commit 3ae1c414f69a0eddbfecd4341dd27c7a5e90e12a
explicitly enables us to build a package with several "identical" file triggers,
so why abort when different packages provide file triggers on the same path?

See you


0005-allow-having-identical-trans-file-triggers.patch
Description: Binary data
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [PATCH] add support for _ in perl module version

[Thierry Vignaud]

Hi

This patch allows "_" character in perl module versions

see you


0004-add-support-for-_-in-perl-module-version.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 14:30, Thierry Vignaud  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

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

[Thierry Vignaud]

On 28 August 2015 at 13:42, fredrik  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

[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] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 25 August 2015 at 13:41, Thierry Vignaud  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] RPM 4.13.0-alpha released

[Thierry Vignaud]

On 24 July 2015 at 13:48, Florian Festi  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

One limitation of this implementation is that we fire more triggers
that in Mageia implementation.
The old implementation enables us to matches a RE against the full
path, so that we would eg: only run ldconfig when there were
new/updated *.so files in /lib{,64} but now it's fired whenever a perl
module or a tex packages install sg in eg /usr/lib/perl/ ...
This can also contribute to the issue of having FT on the same directory.
It would be nice to able to provide path as a RE...
___
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  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  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] [PATCH] translations updates

[Thierry Vignaud]

On 17 August 2015 at 09:22, Lubos Kardos  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

[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] [dev] rpm python3 binding giving an error

[Thierry Vignaud]

On 9 August 2015 at 21:34, Olav Vitters  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

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

[Thierry Vignaud]

On 7 August 2015 at 09:49, Lubos Kardos  wrote:
>> > 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)
>>
>> This patch doesn't work when you have a file trigger fired by several
>> packages. This error is showed:
>>
>> error: incorrect format: array iterator used with different sized arrays
>>
>> I will add FILETRIGGERTYPE and FILETRIGGERCONDS extension tags and
>> I will do --filtriggers option in the same way as --triggers option is done.
>
> I added "--filetriggers" option upstream [1] and also into fedora
> in package rpm-4.12.90-6.fc24.
>
> Lubos
>
> [1] 
> https://github.com/rpm-software-management/rpm/commit/d18fdd7f8964d01b4dfc39bf84133695cff5a13a

I've already integrated it yesterday evening :-) :
http://svnweb.mageia.org/packages/cauldron/rpm/current/SPECS/rpm.spec?r1=861242&r2=861501

But thanks you for telling us :-)  !
___
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  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