From: "Philippe Mathieu-Daudé" <email@example.com> To: Paolo Bonzini <firstname.lastname@example.org>, "Dr. David Alan Gilbert" <email@example.com> Cc: "Peter Maydell" <firstname.lastname@example.org>, "Daniel P. Berrangé" <email@example.com>, "Samuel Ortiz" <firstname.lastname@example.org>, "Kashyap Chamarthy" <email@example.com>, "Richard Henderson" <firstname.lastname@example.org>, "QEMU Developers" <email@example.com>, "Stefan Hajnoczi" <firstname.lastname@example.org>, "Alex Bennée" <email@example.com> Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs Date: Fri, 23 Aug 2019 15:15:01 +0200 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 8/22/19 7:05 PM, Paolo Bonzini wrote: > On 22/08/19 18:50, Dr. David Alan Gilbert wrote: >> * Paolo Bonzini (firstname.lastname@example.org) 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 index Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-16 18:16 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 publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
QEMU-Devel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \ email@example.com public-inbox-index qemu-devel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git