qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
Date: Fri, 23 Aug 2019 15:15:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 8/22/19 7:05 PM, Paolo Bonzini wrote:
> On 22/08/19 18:50, Dr. David Alan Gilbert wrote:
>> * Paolo Bonzini (address@hidden) 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".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]