Re: [PATCH v2 00/24] Sbuild/Schroot migration

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

On 26.11.21 09:03, Uladzimir Bely wrote:
> In mail from Friday, 26 Nov 2021. 09:43:58 +03 user Jan Kiszka wrote:
>> On 23.11.21 14:05, Uladzimir Bely wrote:
>>>> Current limitations:
>>>> - there is an unsolved problem with building foreigh architectures
>>>> using kas-docker.
>>
>> What exactly is the problem here?
>>
> 
> Actually, the problem was related to UsrMerge. Our Jenkins root is also based 
> on buster, but /bin, /lib are symlinks to /usr/bin, /usr/lib and so on. While 
> in buster-slim used in kas-docker /bin, /lib are separate directories. And 
> schroot version used in buster couldn't work in this case (qemu-*-static 
> packages couldn't find some libraries).
> 
> But when I schroot version from bullseye seems to support both kinds of 
> rootfs. So, no changes were needed in sbuild patches, I just preinstalled 
> newer schroot (from bullseye) in kas-docker image (in addition to a newer 
> sbuild), and it works.

Ah, ok. Then we will be automatically fine when moving the complete kas
image to bullseye.

> 
>>>> ...
>>
>> I've commented on some aspects of you kas patch. It generally looks
>> feasible, just some smaller details should be improved.
>>
> 
> Yes, I saw your comments on github. I'm not yet experienced in kas 
> development, so my implementation is not ideal.
> 

No problem, that can be sorted out. If you have questions, just drop
them on kas mailing list.

>>> ...
>>> So, gitlab will use external ("/m/ws-10/schroot-10a/union") directory on
>>> host. Also, there should be empty "overlay" and "underlay" directories
>>> created in it.
>>
>> That's also not unrealistic, given that we already need to provide
>> special runners for the purpose of granting privileges and allowing
>> binfmt_misc. One target would be
>> https://gitlab.com/cip-project/cip-testing/gitlab-cloud-ci, the backend
>> for many of our gitlab CI runners that are Isar-compatible.
>>
>> Jan
> 
> Ok, I'll take a look at it.
> 
> Currently I'm trying to find/fix possible issues in downstreams. I took meta-
> iot2050 for experiments. For now it seems to use quite old docker image and 
> isar codebase. At first, I made sure it can build with no errors current Isar 
> 'next' branch with using my modified docker image. But for now it is not yet 
> able to build even partial (preparation patches only) sbuild patchset and I'm 
> trying to understand and fix the issues.
> 

Yeah, meta-io2050 dependencies were frozen for an upcoming release. Try
bumping them first and building those with unpatched Isar and unpatched
kas 2.6.2 (that should work, see
https://github.com/siemens/meta-iot2050/pull/205), then modify kas and
finally patch isar. If there are issues already in the first step, let
me know.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux