Description of problem: if you build a rpm for armv7hnl the isa shows as armv7hnl-32 resulting in uninstallable rpms as the isa for armv7hl is armv7hl-32 we should ensure that the armhfp isa is armv7hl-32 for all armv7h*l arches diff -uNr rpm-4.13.0-rc1.orig/installplatform rpm-4.13.0-rc1/installplatform --- rpm-4.13.0-rc1.orig/installplatform 2016-04-13 10:14:28.731942821 -0500 +++ rpm-4.13.0-rc1/installplatform 2016-04-13 10:19:15.203361436 -0500 @@ -96,6 +96,12 @@ CANONARCH=${ARCH} CANONCOLOR=0 ;; + armv7h*) + ISANAME=armv7hl + ISABITS=32 + CANONARCH=arm + CANONCOLOR=0 + ;; arm*) ISANAME=`echo ${ARCH} | sed "s/^\([^-]*\)-.*/\1/"` ISABITS=32 is probably what is needed to fix this
Interesting that %{?_isa} macro contents looks different on different stages. If i try to use it during %build or %install stages I've got "(armv7hl-32)" which is fine. However if I try to get it during dependency checking (see the next line), it will pass wrong value. https://github.com/lemenkov/erlang-rpm-macros/blob/master/erlang.attr %__erlang_requires %{_rpmconfigdir}/erlang-find-requires.py -b %{buildroot} -i %{?_isa} -l %{_libdir}
(In reply to Peter Lemenkov from comment #1) > Interesting that %{?_isa} macro contents looks different on different > stages. If i try to use it during %build or %install stages I've got > "(armv7hl-32)" which is fine. However if I try to get it during dependency > checking (see the next line), it will pass wrong value. > > https://github.com/lemenkov/erlang-rpm-macros/blob/master/erlang.attr > > %__erlang_requires %{_rpmconfigdir}/erlang-find-requires.py -b %{buildroot} > -i %{?_isa} -l %{_libdir} The reason why you have different %_isa during build and dependency generation is that you build armv7hl package (using --target armv7hl) on armv7hnl and you use the old mechanism for filtering dependency. This old dependency mechanism uses the obsoleted external dependency generator (script /usr/lib/rpm/redhat/find-requires) instead of the internal one. The target value (armv7hl) is not passed to this external dependency generator so it is ignored and because the machine is armv7hnl, the %_isa macro is filled with armv7hnl. So this problem can be solved by using the new mechanism for filtering dependencies [1] which uses the internal dependency generator. If the internal dependency generator is used then all macros are set according to the target option if it is present on rpmbuild commandline. Whether the %_isa macro should be set to "armv7hl" also during build on armv7hnl machine when the option "--target armv7hl" is not used is different question. That would mean that some armv7hnl package could work with armv7hl library similarly as i686 package can work with i586 library.
[1] https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
> Whether the %_isa macro should be set to "armv7hl" also during build on > armv7hnl machine when the option "--target armv7hl" is not used is different > question. That would mean that some armv7hnl package could work with armv7hl > library similarly as i686 package can work with i586 library. I am not the one who can decide this. Peter can you help and provide your opinion. Thanks.
Thanks for the explanation, Ľuboš! So I suppose we may close this ticket. Also we should remove outdated scripts you mentioned entirely, since they cause issues like that.
(In reply to Peter Lemenkov from comment #5) > Thanks for the explanation, Ľuboš! > > So I suppose we may close this ticket. Also we should remove outdated > scripts you mentioned entirely, since they cause issues like that. I am not sure I can remove these scripts right now some people can still depend on them, but at least I added a warning when the deprecated external dependency generator is used [1] [1] https://github.com/rpm-software-management/rpm/commit/cfcdd942ade7e50e8738b4721fad0c19008d9b84
you can install and run armv7hnl packages with armv7hl, they are the equivalent of i586 and i686. the isa probably should be armhfp but that would require a mass rebuild and a workaround to allow an isa of armv7hl to be installed in the short term.
The problem which blocked building of some packages was explained and solved (see comment 5). I also added a warning to rpm upstream which is showed when deprecated external generator is used. So I am closing this bug. If you want to change isa for armv7hnl and armv7hl to armhfp as it was suggested in comment 7 then please open a new bug for that request.
This bug was opened to have the isa changed. I am not sure we can change to armhfp without carrying some extra patches so that armv7hl is valid also as we transition.
Patch applied upstream [1] and in rawhide [2]. [1] https://github.com/rpm-software-management/rpm/commit/5d5dd569d01300db833e434ff49beb8b22627310 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=767042
(In reply to Ľuboš Kardoš from comment #6) > I am not sure I can remove these scripts right now some people can still > depend on them, but at least I added a warning when the deprecated external > dependency generator is used [1] > > [1] > https://github.com/rpm-software-management/rpm/commit/ > cfcdd942ade7e50e8738b4721fad0c19008d9b84 How can we avoid this new warning? I mean, how we can force to use the internal generator? I've tried this in our .spec in RHEL 8 Beta but the warning is still shown: %define _use_internal_dependency_generator 1 Thanks, Albert
(In reply to Albert Gil from comment #11) > How can we avoid this new warning? > I mean, how we can force to use the internal generator? The internal generator is always used, unless overridden in system/user-specific configuration or the spec. > > I've tried this in our .spec in RHEL 8 Beta but the warning is still shown: > %define _use_internal_dependency_generator 1 There's something else overriding that, in the spec. Not knowing what "our spec" is I have to resort to guessing: the most common cause is %filter_setup which predates the filtering capabilities in the internal generator, and, whose use should be avoided. We should probably add a warning the %filter_setup macro itself. - Panu -
(In reply to Panu Matilainen from comment #12) > The internal generator is always used, unless overridden in > system/user-specific configuration or the spec. Ok. > There's something else overriding that, in the spec. Not knowing what "our > spec" is I have to resort to guessing: the most common cause is > %filter_setup which predates the filtering capabilities in the internal > generator, and, whose use should be avoided. We should probably add a > warning the %filter_setup macro itself. This is our current .spec: https://github.com/SchedMD/slurm/blob/master/slurm.spec And you are totally right, we are actually using an external generator: %global _use_internal_dependency_generator 0 %global __find_requires %{_builddir}/%{buildsubdir}/find-requires.sh I just missed it. Sorry for the noise, Albert
Right: cat > find-requires.sh <<'EOF' exec %{__find_requires} "$@" | egrep -v '^libpmix.so|libevent' EOF Such tricks used to be necessary but since rpm >= 4.9 there's no need to use the external generator for filtering anymore, see http://rpm.org/user_doc/dependency_generators
(In reply to Panu Matilainen from comment #14) > Such tricks used to be necessary but since rpm >= 4.9 there's no need to use > the external generator for filtering anymore, see > http://rpm.org/user_doc/dependency_generators Thanks Panu!