Bug 1326871 - _isa on armv7hnl is incorrect
Summary: _isa on armv7hnl is incorrect
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 24
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-13 15:22 UTC by Dennis Gilmore
Modified: 2019-02-11 10:25 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-19 11:42:47 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Dennis Gilmore 2016-04-13 15:22:31 UTC
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

Comment 1 Peter Lemenkov 2016-04-13 17:45:17 UTC
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}

Comment 2 Ľuboš Kardoš 2016-04-18 09:37:30 UTC
(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.

Comment 4 Ľuboš Kardoš 2016-04-18 09:47:47 UTC
> 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.

Comment 5 Peter Lemenkov 2016-04-18 09:49:06 UTC
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.

Comment 6 Ľuboš Kardoš 2016-04-18 12:48:56 UTC
(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

Comment 7 Dennis Gilmore 2016-04-18 14:10:23 UTC
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.

Comment 8 Ľuboš Kardoš 2016-05-09 08:56:09 UTC
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.

Comment 9 Dennis Gilmore 2016-05-11 20:27:09 UTC
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.

Comment 11 Albert Gil 2019-02-08 18:04:15 UTC
(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

Comment 12 Panu Matilainen 2019-02-11 09:09:56 UTC
(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 -

Comment 13 Albert Gil 2019-02-11 09:42:25 UTC
(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

Comment 14 Panu Matilainen 2019-02-11 09:55:43 UTC
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

Comment 15 Albert Gil 2019-02-11 10:25:23 UTC
(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!


Note You need to log in before you can comment on or make changes to this bug.