This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 1326871 - _isa on armv7hnl is incorrect
_isa on armv7hnl is incorrect
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-13 11:22 EDT by Dennis Gilmore
Modified: 2016-05-19 07:42 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-19 07:42:47 EDT
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)

  None (edit)
Description Dennis Gilmore 2016-04-13 11:22:31 EDT
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 13:45:17 EDT
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 05:37:30 EDT
(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 05:47:47 EDT
> 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 05:49:06 EDT
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 08:48:56 EDT
(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 10:10:23 EDT
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 04:56:09 EDT
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 16:27:09 EDT
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.

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