%ifarch fails to properly detect armv7l builds on OBS?
Good morning/evening/afternoon/night, I am currently trying to package python-libtmux, that has different errors in the %checks on different architectures. I figured out which checks fail on which architecture and wrapped them in separate %ifarch sections:
# Failing tests on armv7l # https://github.com/tmux-python/libtmux/issues/479 %ifarch armv7l %pytest -k 'not ( \ test_capture_pane \ or test_function_times_out \ or test_function_times_out_no_rise \ or test_new_window_with_environment[environment0] \ or test_new_window_with_environment[environment1] \ or test_select_window \ )' %endif
However, the armv7l section is never used when building for "openSUSE Tumbleweed armv7l". The build log shows many different things regarding the architecture:
[ 0s] Using BUILD_ARCH=armv7l:armv6l:armv5tel [ 0s] Building python-libtmux for project 'home:ojkastl_buildservice:libtmux_bugreports' repository 'openSUSE_Tumbleweed' arch 'armv7l' srcmd5 'def7c83c25c69087de1ed1cde6ee11e4'
[ 11s] 2nd stage started in virtual machine [ 11s] machine type: aarch64
[ 11s] 2nd stage started in virtual machine [ 11s] machine type: armv8l
[ 18s] build target is armv7hl-suse-linux [ 18s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --target=armv7hl-suse-linux --undefine _enable_debug_packages --define 'disturl obs://build.opensuse.org/home:ojkastl_buildservice:libtmux_bugreports/openSUSE_Tumbleweed/def7c83c25c69087de1ed1cde6ee11e4-python-libtmux' /home/abuild/rpmbuild/SOURCES/python-libtmux.spec [ 20s] Building target platforms: armv7hl-suse-linux [ 20s] Building for target armv7hl-suse-linux
But in the end it falls back to the default:
[ 30s] + echo 'DEBUGGING BUILDARCH is NOT aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel' [ 30s] DEBUGGING BUILDARCH is NOT aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel [ 30s] + uname -a [ 30s] Linux obs-arm-10 6.1.7-1-default #1 SMP PREEMPT_DYNAMIC Wed Jan 18 11:12:34 UTC 2023 (872045c) armv7l armv7l armv7l GNU/Linux [ 30s] + IGNORED_TESTS='not (test_capture_pane_start or test_function_times_out_no_rise or test_function_times_out_no_raise_assert)'
I already tried to add things like armv6l armv5tel armv7l:armv6l:armv5tel to the %ifarch, but that did not help. What have I missed? Is this due to some cross-compilation used in OBS? How to properly detect armv7l? The package in question is (currently containing lots of debugging code not yet cleaned up):
https://build.opensuse.org/package/show/home:ojkastl_buildservice:libtmux_bu... Kind Regards, Johannes
Side note: I used several separate %ifarch conditions followed by a %ifnarch mentioning all of the architectures used before in the %ifarch conditions. I have not found any trace of %elsearch or %elifarch or anything like that, i.e. some kind of if-elseif-else-statement or case-like statement. If there is such a thing, please point me at it, I would like to make this more readable... :-) -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Freitag, 31. März 2023, 08:22:29 CEST Johannes Kastl wrote:
Good morning/evening/afternoon/night,
I am currently trying to package python-libtmux, that has different errors in the %checks on different architectures.
I figured out which checks fail on which architecture and wrapped them in separate %ifarch sections:
# Failing tests on armv7l # https://github.com/tmux-python/libtmux/issues/479 %ifarch armv7l %pytest -k 'not ( \ test_capture_pane \ or test_function_times_out \ or test_function_times_out_no_rise \ or test_new_window_with_environment[environment0] \ or test_new_window_with_environment[environment1] \ or test_select_window \ )' %endif
However, the armv7l section is never used when building for "openSUSE Tumbleweed armv7l". The build log shows many different things regarding the architecture:
[ 0s] Using BUILD_ARCH=armv7l:armv6l:armv5tel [ 0s] Building python-libtmux for project 'home:ojkastl_buildservice:libtmux_bugreports' repository 'openSUSE_Tumbleweed' arch 'armv7l' srcmd5 'def7c83c25c69087de1ed1cde6ee11e4'
[ 11s] 2nd stage started in virtual machine [ 11s] machine type: aarch64
[ 11s] 2nd stage started in virtual machine [ 11s] machine type: armv8l
[ 18s] build target is armv7hl-suse-linux [ 18s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --target=armv7hl-suse-linux --undefine _enable_debug_packages --define 'disturl obs://build.opensuse.org/home:ojkastl_buildservice:libtmux_bugreports/openSUSE_Tumbleweed/def7c83c25c69087de1ed1cde6ee11e4-python-libtmux' /home/abuild/rpmbuild/SOURCES/python-libtmux.spec [ 20s] Building target platforms: armv7hl-suse-linux [ 20s] Building for target armv7hl-suse-linux
But in the end it falls back to the default:
[ 30s] + echo 'DEBUGGING BUILDARCH is NOT aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel' [ 30s] DEBUGGING BUILDARCH is NOT aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel [ 30s] + uname -a [ 30s] Linux obs-arm-10 6.1.7-1-default #1 SMP PREEMPT_DYNAMIC Wed Jan 18 11:12:34 UTC 2023 (872045c) armv7l armv7l armv7l GNU/Linux [ 30s] + IGNORED_TESTS='not (test_capture_pane_start or test_function_times_out_no_rise or test_function_times_out_no_raise_assert)'
I already tried to add things like armv6l armv5tel armv7l:armv6l:armv5tel to the %ifarch, but that did not help.
What have I missed? Is this due to some cross-compilation used in OBS? How to properly detect armv7l?
Usig armv7hl instead? Or maybe just the gerneric %arm macro for all 32bit arm archs
The package in question is (currently containing lots of debugging code not yet cleaned up):
https://build.opensuse.org/package/show/home:ojkastl_buildservice:libtmux_bu... Kind Regards, Johannes
Side note: I used several separate %ifarch conditions followed by a %ifnarch mentioning all of the architectures used before in the %ifarch conditions. I have not found any trace of %elsearch or %elifarch or anything like that, i.e. some kind of if-elseif-else-statement or case-like statement. If there is such a thing, please point me at it, I would like to make this more readable... :-)
-- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de
B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Hi Adrian, On 31.03.23 at 08:51 Adrian Schröter wrote:
On Freitag, 31. März 2023, 08:22:29 CEST Johannes Kastl wrote:
What have I missed? Is this due to some cross-compilation used in OBS? How to properly detect armv7l?
Usig armv7hl instead?
OK, I think this was the one thing I did not try. I started with the name of the architecture in the build targets, which is armv7l without the h...
Or maybe just the gerneric %arm macro for all 32bit arm archs
That sounds like an idea. In the meantime I found out that apparently my "multiple ifarchs with an ifnarch at the end" did not work, as apparently all builds used the "ifnarch" part. I'll dig deeper into this... Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi all, On 03.04.23 at 07:50 Johannes Kastl wrote:
In the meantime I found out that apparently my "multiple ifarchs with an ifnarch at the end" did not work, as apparently all builds used the "ifnarch" part. I'll dig deeper into this...
OK, I give up, I fail to see my error in this. I noticed that the multiple %ifarch conditions were not used, so I added a hard "exit 99" to each one but the %ifnarch one. And sure enough, all builds (i586, x86_64, armv7l, aarch64) still succeed, as they always end up in the %else clauses for all of the %ifarch ones. I also added a %else to all of the %ifarch statements, and all of them seem to fall into the %else condition. Can someone please point out my error? I am failing to understand it. Thanks in advance, Johannes
https://build.opensuse.org/package/view_file/home:ojkastl_buildservice:libtm...
%ifarch ppc64le echo "DEBUGGING arch is ppc64le" uname -a exit 99 %else echo "Not ppc64le" %endif %ifarch %%arm echo "DEBUGGING arch is 32bit arm" uname -a exit 99 %else echo "Not 32bit arm" %endif %ifarch aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l echo "DEBUGGING arch is aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l" uname -a exit 99 %else echo "Not aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l" %endif %ifarch ppc64:ppc ppc64 ppc echo "DEBUGGING arch is ppc64:ppc ppc64 ppc" uname -a exit 99 %else echo "Not ppc64:ppc ppc64 ppc" %endif %ifnarch aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel %%arm echo "DEBUGGING arch is NOT aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel" uname -a %else echo "Arch is one of aarch64 aarch64_ilp32 armv8l aarch64:aarch64_ilp32:armv8l ppc64:ppc ppc64 ppc ppc64le armv7l armv6l armv5tel armv7l:armv6l:armv5tel %%arm" %endif
-- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Mon, 2023-04-03 at 14:59 +0200, Johannes Kastl wrote:
Hi all,
On 03.04.23 at 07:50 Johannes Kastl wrote:
In the meantime I found out that apparently my "multiple ifarchs with an ifnarch at the end" did not work, as apparently all builds used the "ifnarch" part. I'll dig deeper into this...
OK, I give up, I fail to see my error in this.
I noticed that the multiple %ifarch conditions were not used, so I added a hard "exit 99" to each one but the %ifnarch one. And sure enough, all builds (i586, x86_64, armv7l, aarch64) still succeed, as they always end up in the %else clauses for all of the %ifarch ones.
I also added a %else to all of the %ifarch statements, and all of them seem to fall into the %else condition.
Can someone please point out my error? I am failing to understand it.
You fell into a very obscure trap: BuildArch: noarch ifarch and noarch do not mingle
Hi Dominique, On 03.04.23 at 15:05 Dominique Leuenberger wrote:
You fell into a very obscure trap:
BuildArch: noarch
ifarch and noarch do not mingle
Thanks for telling me I am not totally losing my marbles. :-) OK, as the package is noarch and needs to stay that way, I will rewrite the %check section and exclude all of the tests on all architectures. I think this might be acceptable, as it is mostly the same tests that fail everywhere anyway... Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Montag, 3. April 2023 15:11:18 CEST Johannes Kastl wrote:
Hi Dominique,
On 03.04.23 at 15:05 Dominique Leuenberger wrote:
You fell into a very obscure trap:
BuildArch: noarch
ifarch and noarch do not mingle
Thanks for telling me I am not totally losing my marbles. :-)
OK, as the package is noarch and needs to stay that way, I will rewrite the
%check section and exclude all of the tests on all architectures. I think
this might be acceptable, as it is mostly the same tests that fail everywhere anyway... Kind Regards, Johannes
Only the subpackages need to be noarch, the package itself can be arch dependent. You "just" have to teach "%python_subpackages" to set "BuildArch: noarch" for each generated subpackage ... Regards, Stefan
participants (4)
-
Adrian Schröter -
Dominique Leuenberger -
Johannes Kastl -
Stefan Brüns