Re: [PATCH 2/2] ci: Add compat arch support

[Jan Kiszka <jan.kiszka@siemens.com>]

On 10.09.20 08:51, [ext] Jan Kiszka wrote:
> On 09.09.20 15:44, Henning Schild wrote:
>> On Tue, 8 Sep 2020 10:53:58 +0200
>> "[ext] Jan Kiszka" <jan.kiszka@siemens.com> wrote:
>>
>>> On 04.09.20 14:47, [ext] Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> Build hello-isar and libisar for the compat arch if that is enabled.
>>>> Set ISAR_ENABLE_COMPAT_ARCH for all supported combinations in CI.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> ---
>>>>  meta-isar/recipes-app/hello-isar/hello-isar.bb | 3 +++
>>>>  meta-isar/recipes-app/libhello/libhello.bb     | 3 +++
>>>>  scripts/ci_build.sh                            | 6 ++++++
>>>>  3 files changed, 12 insertions(+)
>>>>
>>>> diff --git a/meta-isar/recipes-app/hello-isar/hello-isar.bb
>>>> b/meta-isar/recipes-app/hello-isar/hello-isar.bb index
>>>> 144a433e..8c3ba8b2 100644 ---
>>>> a/meta-isar/recipes-app/hello-isar/hello-isar.bb +++
>>>> b/meta-isar/recipes-app/hello-isar/hello-isar.bb @@ -20,4 +20,7 @@
>>>> SRC_URI = " \ file://yet-another-change.txt;apply=yes;striplevel=0"
>>>>  SRCREV = "a18c14cc11ce6b003f3469e89223cffb4016861d"
>>>>  
>>>> +# NOTE: This is just to test 32-bit building on 64-bit archs.
>>>> +PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
>>>> +
>>>>  inherit dpkg
>>>> diff --git a/meta-isar/recipes-app/libhello/libhello.bb
>>>> b/meta-isar/recipes-app/libhello/libhello.bb index
>>>> ab271b58..5c44de50 100644 ---
>>>> a/meta-isar/recipes-app/libhello/libhello.bb +++
>>>> b/meta-isar/recipes-app/libhello/libhello.bb @@ -13,4 +13,7 @@ PV =
>>>> "0.1-98f2e41" SRC_URI =
>>>> "git://github.com/ilbers/libhello.git;protocol=https;destsuffix=${P}"
>>>> SRCREV = "98f2e41e7d05ab8d19b0c5d160b104b725c8fd93" 
>>>> +# NOTE: This is just to test 32-bit building on 64-bit archs.
>>>> +PACKAGE_ARCH_compat-arch = "${COMPAT_DISTRO_ARCH}"
>>>> +
>>>>  inherit dpkg
>>>> diff --git a/scripts/ci_build.sh b/scripts/ci_build.sh
>>>> index d2c707b8..461fd5cc 100755
>>>> --- a/scripts/ci_build.sh
>>>> +++ b/scripts/ci_build.sh
>>>> @@ -139,6 +139,12 @@ if [ ! -d "$BUILD_DIR" ]; then
>>>>  fi
>>>>  source isar-init-build-env "$BUILD_DIR"
>>>>  
>>>> +cat >>conf/local.conf <<EOF
>>>> +ISAR_ENABLE_COMPAT_ARCH_amd64 = "1"
>>>> +ISAR_ENABLE_COMPAT_ARCH_arm64 = "1"
>>>> +ISAR_ENABLE_COMPAT_ARCH_debian-stretch_amd64 = "0"
>>>> +EOF
>>>> +
>>>>  if [ -n "$CROSS_BUILD" ]; then
>>>>      sed -i -e 's/ISAR_CROSS_COMPILE ?= "0"/ISAR_CROSS_COMPILE ?=
>>>> "1"/g' conf/local.conf fi
>>>>   
>>>
>>> This triggers a problem:
>>>
>>> In a multiconfig setup like our CI, building the 32-bit package from
>>> both the native 32-bit arch as well as the 64-bit arch now races. If
>>> the 64-bit arch tries to install its self-built compat package, that
>>> may just be under re-deployment by the 32-bit arch, and the build
>>> fails.
>>>
>>> Options:
>>>  - somehow express that both archs provide the same package (though
>>> that may defeat the purpose of testing the compat build)
>>
>> The purpose is that people want to use compat because they have just
>> one image.
> 
> Well, one could imagine building a legacy application for both an old
> ARMv7 device as well as for a new ARMv8 design. All that in one build
> run (mc:...). Then the user would have to express that
> my_beloved_legacy_app is actually a dependency that only needs to be
> built once, and it would not matter if that is done by the armhf
> buildchroot or via compat by the arm64 one.
> 

I think I know the answer for our testing scenario: call the the
compat-variant of hello-isar "hello-isar-compat" and request that
package in the 64-bit image. Then both build paths are stressed, and
everyone gets what is desired.

Let me try that later...

Jan

>>
>>>  - split isar-apt per arch, not just per distro
>>
>> But would the compat not need to include both now, and the mc enemy
>> would still mess with one of them?
> 
> We would have isar-apt/apt/debian-buster-armhf, debian-buster-arm64
> etc., but all of them able to carry packages for any arch.
> 
>>
>> - better/more locking around isar-apt readers and writers
>>
> 
> Nope, that would only paper over the fact that a package is built twice
> and the one to be used would be chosen by chance. Bad for reliable testing.
> 
> Jan
> 
>>> Suggestions?
>>
>> Well one thing ... but i do not want to repeat myself ... 
>>
>> Henning
>>
>>> Jan
>>>
>>
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux