From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Samuel Ortiz" <sameo@linux.intel.com>,
"Kashyap Chamarthy" <kchamart@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
Date: Sat, 24 Aug 2019 08:44:48 +0100 [thread overview]
Message-ID: <877e732ej3.fsf@linaro.org> (raw)
In-Reply-To: <a9fdc89e-bc75-59c5-2e1a-12c50b3e92de@redhat.com>
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
next prev parent reply other threads:[~2019-08-24 7:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-16 18:16 [Qemu-devel] more automated/public CI for QEMU pullreqs Peter Maydell
2019-08-22 10:49 ` Stefan Hajnoczi
2019-08-22 11:04 ` Peter Maydell
2019-08-22 11:14 ` Paolo Bonzini
2019-09-30 12:53 ` Peter Maydell
2019-10-04 9:31 ` Stefan Hajnoczi
2019-08-22 11:47 ` [Qemu-devel] " Daniel P. Berrangé
2019-08-22 16:31 ` Dr. David Alan Gilbert
2019-08-22 16:48 ` Paolo Bonzini
2019-08-22 16:50 ` Dr. David Alan Gilbert
2019-08-22 17:05 ` Paolo Bonzini
2019-08-23 13:15 ` Philippe Mathieu-Daudé
2019-08-24 7:44 ` Alex Bennée [this message]
2019-08-22 17:03 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877e732ej3.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kchamart@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sameo@linux.intel.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).