From: Thomas Huth <thuth@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PULL 00/21] machine + QOM queue, 2020-10-05
Date: Tue, 6 Oct 2020 20:47:29 +0200 [thread overview]
Message-ID: <deb55fbb-637b-0b94-6efb-c508c5dc691a@redhat.com> (raw)
In-Reply-To: <20201006144215.GK2482221@redhat.com>
On 06/10/2020 16.42, Daniel P. Berrangé wrote:
> On Tue, Oct 06, 2020 at 03:38:56PM +0100, Peter Maydell wrote:
>> On Tue, 6 Oct 2020 at 15:36, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>
>>> On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote:
>>>> Compile failure on OSX:
>>>>
>>>> ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned
>>>> char' but the argument has type 'int' [-Werror,-Wformat]
>>>> node->level - 1);
>>>> ^~~~~~~~~~~~~~~~
>>>> /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note:
>>>> expanded from macro 'error_setg'
>>>> (fmt), ## __VA_ARGS__)
>>>> ~~~ ^~~~~~~~~~~
>>>> 1 error generated.
>>>
>>> Is there a CI system where this is tested? I'd like to be able
>>> to detect this kind of failure before sending pull requests.
>>
>> Currently this is still my ad-hoc setup. I think there is
>> some CI that tests OSX compiles, though I have no idea how
>> individual maintainers set up to use it.
>
> Cirrus CI will cover macOS builds. You just need to register with
> Cirrus CI via your GitLab login, then pushing a branch to gitlab
> should trigger both GitLab CI and Cirrus CI, which covers a vast
> majority of combinations.
I think Cirrus-CI needs a github account? Is there a way to use Gitlab now
instead? (just like Travis recently added Gitlab support?)
We should eventually set up the cirrus-run tool, so we can use gitlab, too,
but I think you then still need at least a dummy github account to be able
to use it, don't you?
Thomas
next prev parent reply other threads:[~2020-10-06 18:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 21:09 [PULL 00/21] machine + QOM queue, 2020-10-05 Eduardo Habkost
2020-10-05 21:09 ` [PULL 01/21] numa: hmat: require parent cache description before the next level one Eduardo Habkost
2020-10-05 21:09 ` [PULL 02/21] hw/core/qdev-properties: Use qemu_strtol() in set_mac() handler Eduardo Habkost
2020-10-05 21:09 ` [PULL 03/21] hw/core/qdev-properties: Use qemu_strtoul() in set_pci_host_devaddr() Eduardo Habkost
2020-10-05 21:09 ` [PULL 04/21] hw/core/qdev-properties: Fix code style Eduardo Habkost
2020-10-05 21:09 ` [PULL 05/21] hw/core/qdev-properties: Export enum-related functions Eduardo Habkost
2020-10-05 21:09 ` [PULL 06/21] hw/core/qdev-properties: Export qdev_prop_enum Eduardo Habkost
2020-10-05 21:09 ` [PULL 07/21] hw/core/qdev-properties: Export some integer-related functions Eduardo Habkost
2020-10-05 21:09 ` [PULL 08/21] hw/core/qdev-properties: Extract system-mode specific properties Eduardo Habkost
2020-10-05 21:09 ` [PULL 09/21] hw/core/cpu: Add missing 'exec/cpu-common.h' include Eduardo Habkost
2020-10-05 21:09 ` [PULL 10/21] qom: Improve error message displayed with missing object properties Eduardo Habkost
2020-10-05 21:09 ` [PULL 11/21] qom: Fix DECLARE_*CHECKER documentation Eduardo Habkost
2020-10-05 21:09 ` [PULL 12/21] docs/devel/qom: Fix indentation of bulleted list Eduardo Habkost
2020-10-05 21:09 ` [PULL 13/21] docs/devel/qom: Fix indentation of code blocks Eduardo Habkost
2020-10-05 21:09 ` [PULL 14/21] docs/devel/qom: Use *emphasis* for emphasis Eduardo Habkost
2020-10-05 21:09 ` [PULL 15/21] docs/devel/qom: Remove usage of <code> Eduardo Habkost
2020-10-05 21:09 ` [PULL 16/21] docs/devel/qom: Avoid long lines Eduardo Habkost
2020-10-05 21:09 ` [PULL 17/21] kernel-doc: Handle function typedefs that return pointers Eduardo Habkost
2020-10-05 21:09 ` [PULL 18/21] kernel-doc: Handle function typedefs without asterisks Eduardo Habkost
2020-10-05 21:09 ` [PULL 19/21] qom: Explicitly tag doc comments for typedefs and structs Eduardo Habkost
2020-10-05 21:09 ` [PULL 20/21] memory: Explicitly tag doc comments for structs Eduardo Habkost
2020-10-05 21:10 ` [PULL 21/21] kernel-doc: Remove $decl_type='type name' hack Eduardo Habkost
2020-10-06 14:03 ` [PULL 00/21] machine + QOM queue, 2020-10-05 Peter Maydell
2020-10-06 14:36 ` Eduardo Habkost
2020-10-06 14:38 ` Peter Maydell
2020-10-06 14:42 ` Daniel P. Berrangé
2020-10-06 18:47 ` Thomas Huth [this message]
2020-10-06 19:10 ` Paolo Bonzini
2020-10-07 9:10 ` Daniel P. Berrangé
2020-10-07 8:17 ` Daniel P. Berrangé
2020-10-06 14:41 ` Paolo Bonzini
2020-10-06 15:04 ` Igor Mammedov
2020-10-06 15:23 ` Igor Mammedov
2020-10-06 15:42 ` Paolo Bonzini
2020-10-06 16:14 ` Igor Mammedov
2020-10-06 18:43 ` Thomas Huth
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=deb55fbb-637b-0b94-6efb-c508c5dc691a@redhat.com \
--to=thuth@redhat.com \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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
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).