From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@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>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
Date: Fri, 23 Aug 2019 15:15:01 +0200 [thread overview]
Message-ID: <a9fdc89e-bc75-59c5-2e1a-12c50b3e92de@redhat.com> (raw)
In-Reply-To: <b9f98b17-49c4-a227-ab87-de4a6f42f089@redhat.com>
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
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".
next prev parent reply other threads:[~2019-08-23 13:16 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é [this message]
2019-08-24 7:44 ` Alex Bennée
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=a9fdc89e-bc75-59c5-2e1a-12c50b3e92de@redhat.com \
--to=philmd@redhat.com \
--cc=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=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).