Re: [Qemu-devel] more automated/public CI for QEMU pullreqs

["Alex Bennée" <alex.bennee@linaro.org>]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 8/22/19 7:05 PM, Paolo Bonzini wrote:
>> On 22/08/19 18:50, Dr. David Alan Gilbert wrote:
>>> * Paolo Bonzini (pbonzini@redhat.com) wrote:
>>>> On 22/08/19 18:31, Dr. David Alan Gilbert wrote:
>>>>>> With both these points in mind, I think it is  pretty hard sell to
>>>>>> say we should write & maintain a custom CI system just for QEMU
>>>>>> unless it is offering major compelling functionality we can't do
>>>>>> without.
>>>
>>> (That was Dan's comment)
>>>
>>>> In theory I agree.
>>>>
>>>> In practice, the major compelling functionality is portability.  If it
>>>> is true that setting up runners is problematic even on aarch64, frankly
>>>> GitLab CI is dead on arrival.  If it is not true, then I'd be very happy
>>>> to use GitLab CI too.
>>>
>>> IMHO if for some weird reason Gitlab has problems on aarch64 then we
>>> just need to get that fixed.
>>
>> I'm sure it's just some packaging or deployment issue.  But
>> https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725 has been
>> open for more than one year; the last two messages are:
>>
>> * 1 month ago: "I hope we will be able to merge it soon"
>>
>> * 3 weeks ago: "Today I tried use gitlab-runner on my arm64 box, however
>> it kept mysteriously failing"
>>
>> So the question is simply who does the work.
>
> IIRC Samuel Ortiz told he was using GitLab with Aarch64 runners around
> Nov 2018, but "compiling from source". Alex Bennée tried building it on
> our Packet server during early 2019.
> Later an (unattended?) Ubuntu upgrade installed a package that does not
> work anymore with current GitLab server. I noticed this few months ago,
> built it again and tested it, then looked at what was wrong with the
> upstream MR. The Aarch64 packaging succeed when cross-building on x86_64
> host, but fails when building natively... Since part of it is "built or
> tested in the cloud" and involving Go, I simply let a comment:
> https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/725#note_183470145

I need to have another look at this but from memory it is because the
"cross-build" approach they use is to try and build all arches with a
qemu-user controlled docker build. However if the host architecture is
the target you are aiming for that should run normally - however it
failed on qemu-test because you can't build the armhf binaries there as
not all AArch64 machines support AArch32. There is a bug in the Debian
binfmt_misc scripts that I raised but needs proper fixing.

I think the easiest thing to do would be to document how to build
exactly 1 architecture at a time so you don't have to succeed in
building everything at once and can build something natively without
jumping through hoops.

>
> So to confirm what Paolo said, GitLab runners work on Aarch64
> (and we have it well tested), however there is a packaging issue,
> so it does not work "out of the box".
>
>
> Related to:
>
>   Runner compiled with Go 1.8.7 seems to not work properly with
>   multiarch support. Executing the binary built with Go 1.8.7
>   results with an error [...]
>
> There has been 1 recent fix for the go runner:
> https://bugs.launchpad.net/qemu/+bug/1838946/comments/1
>
> And there is an ongoing discussion about "patch to swap SIGRTMIN + 1
> and SIGRTMAX - 1".

Much as I champion qemu-user for solving build problems I think being
able to build natively should be the quicker and easier fix (not that we
shouldn't fix qemu-user bugs as well).

--
Alex Bennée