The following changes since commit 3e40748834923798aa57e3751db13a069e2c617b:

  Merge remote-tracking branch 'remotes/rth/tags/pull-mb-20201014' into staging (2020-10-15 20:30:24 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 61f6bb4b9b3b33d0371e5f76d756838df372f2ec:

  ci: include configure and meson logs in all jobs if configure fails (2020-10-16 10:01:43 -0400)

----------------------------------------------------------------
* Drop ninjatool and just require ninja (Paolo)
* Fix docs build under msys2 (Yonggang)
* HAX snafu fix (Claudio)
* Disable signal handlers during fuzzing (Alex)
* Miscellaneous fixes (Bruce, Greg)

----------------------------------------------------------------
Alexander Bulekov (1):
      fuzz: Disable QEMU's SIG{INT,HUP,TERM} handlers

Bruce Rogers (3):
      meson.build: don't condition iconv detection on library detection
      configure: fix handling of --docdir parameter
      meson: Only install icons and qemu.desktop if have_system

Claudio Fontana (1):
      hax: unbreak accelerator cpu code after cpus.c split

Greg Kurz (1):
      Makefile: Ensure cscope.out/tags/TAGS are generated in the source tree

Paolo Bonzini (13):
      submodules: bump meson to 0.55.3
      tests/Makefile.include: unbreak non-tcg builds
      make: run shell with pipefail
      tests: add missing generated sources to testqapi
      configure: move QEMU_INCLUDES to meson
      dockerfiles: enable Centos 8 PowerTools
      add ninja to dockerfiles, CI configurations and test VMs
      build: cleanups to Makefile
      build: replace ninjatool with ninja
      build: add --enable/--disable-libudev
      meson: cleanup curses/iconv test
      meson: move SPHINX_ARGS references within "if build_docs"
      ci: include configure and meson logs in all jobs if configure fails

Yonggang Luo (3):
      docs: Fix Sphinx configuration for msys2/mingw
      meson: Move the detection logic for sphinx to meson
      cirrus: Enable doc build on msys2/mingw

 .cirrus.yml                                |   21 +-
 .gitlab-ci.yml                             |    6 +-
 .travis.yml                                |   21 +-
 Makefile                                   |  134 ++--
 configure                                  |   99 +--
 docs/conf.py                               |    2 +-
 docs/devel/build-system.rst                |    6 +-
 docs/meson.build                           |   46 ++
 docs/sphinx/kerneldoc.py                   |    2 +-
 meson                                      |    2 +-
 meson.build                                |  185 ++---
 meson_options.txt                          |    6 +
 scripts/mtest2make.py                      |    3 +-
 scripts/ninjatool.py                       | 1008 ----------------------------
 target/i386/hax-cpus.c                     |    1 +
 tests/Makefile.include                     |    2 +-
 tests/docker/dockerfiles/centos7.docker    |    1 +
 tests/docker/dockerfiles/centos8.docker    |    5 +-
 tests/docker/dockerfiles/debian10.docker   |    1 +
 tests/docker/dockerfiles/fedora.docker     |    1 +
 tests/docker/dockerfiles/travis.docker     |    2 +-
 tests/docker/dockerfiles/ubuntu.docker     |    1 +
 tests/docker/dockerfiles/ubuntu1804.docker |    1 +
 tests/docker/dockerfiles/ubuntu2004.docker |    1 +
 tests/include/meson.build                  |    8 +-
 tests/meson.build                          |   14 +-
 tests/qapi-schema/meson.build              |   88 +--
 tests/qtest/fuzz/fuzz.c                    |    8 +
 tests/vm/centos                            |    2 +-
 tests/vm/centos.aarch64                    |    2 +-
 tests/vm/fedora                            |    2 +-
 tests/vm/freebsd                           |    1 +
 tests/vm/netbsd                            |    1 +
 tests/vm/openbsd                           |    1 +
 tests/vm/ubuntu.aarch64                    |    2 +-
 tests/vm/ubuntu.i386                       |    2 +-
 ui/meson.build                             |    7 +-
 37 files changed, 387 insertions(+), 1308 deletions(-)
 delete mode 100755 scripts/ninjatool.py
-- 
2.26.2

On Fri, 16 Oct 2020 at 16:56, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> The following changes since commit 3e40748834923798aa57e3751db13a069e2c617b:
>
>   Merge remote-tracking branch 'remotes/rth/tags/pull-mb-20201014' into staging (2020-10-15 20:30:24 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 61f6bb4b9b3b33d0371e5f76d756838df372f2ec:
>
>   ci: include configure and meson logs in all jobs if configure fails (2020-10-16 10:01:43 -0400)
>
> ----------------------------------------------------------------
> * Drop ninjatool and just require ninja (Paolo)
> * Fix docs build under msys2 (Yonggang)
> * HAX snafu fix (Claudio)
> * Disable signal handlers during fuzzing (Alex)
> * Miscellaneous fixes (Bruce, Greg)

Half my build hosts fail with a weird backtrace from mtest2make:
Traceback (most recent call last):
  File "scripts/mtest2make.py", line 37, in <module>
    introspect = json.load(sys.stdin)
  File "/usr/lib/python3.6/json/__init__.py", line 299, in load
    parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
make: *** Deleting file 'Makefile.mtest'

followed by:

ERROR: Cannot find Ninja

If you're going to introduce a new build-dependency not satisfied
by a submodule, it would be nice to mention it in the pullrequest
cover letter...

-- PMM

On Sat, 17 Oct 2020 at 14:09, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 16 Oct 2020 at 16:56, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > The following changes since commit 3e40748834923798aa57e3751db13a069e2c617b:
> >
> >   Merge remote-tracking branch 'remotes/rth/tags/pull-mb-20201014' into staging (2020-10-15 20:30:24 +0100)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/bonzini/qemu.git tags/for-upstream
> >
> > for you to fetch changes up to 61f6bb4b9b3b33d0371e5f76d756838df372f2ec:
> >
> >   ci: include configure and meson logs in all jobs if configure fails (2020-10-16 10:01:43 -0400)
> >
> > ----------------------------------------------------------------
> > * Drop ninjatool and just require ninja (Paolo)
> > * Fix docs build under msys2 (Yonggang)
> > * HAX snafu fix (Claudio)
> > * Disable signal handlers during fuzzing (Alex)
> > * Miscellaneous fixes (Bruce, Greg)
>
> Half my build hosts fail with a weird backtrace from mtest2make:
> Traceback (most recent call last):
>   File "scripts/mtest2make.py", line 37, in <module>
>     introspect = json.load(sys.stdin)
>   File "/usr/lib/python3.6/json/__init__.py", line 299, in load
>     parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
>   File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
>     return _default_decoder.decode(s)
>   File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
>     obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
>     raise JSONDecodeError("Expecting value", s, err.value) from None
> json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
> make: *** Deleting file 'Makefile.mtest'
>
> followed by:
>
> ERROR: Cannot find Ninja

I'm updating various build machines and will give the pullreq a
retry, but in the meantime:

The NetBSD tests/vm setup fails slightly differently:

ERROR: Could not detect Ninja v1.7 or newer

thanks
-- PMM

On 17/10/20 15:22, Peter Maydell wrote:
> I'm updating various build machines and will give the pullreq a
> retry, but in the meantime:
> 
> The NetBSD tests/vm setup fails slightly differently:
> 
> ERROR: Could not detect Ninja v1.7 or newer

That's because ninja is apparently a chat program on NetBSD...

Paolo

On 17/10/20 15:09, Peter Maydell wrote:
> Traceback (most recent call last):
>   File "scripts/mtest2make.py", line 37, in <module>
>     introspect = json.load(sys.stdin)
>   File "/usr/lib/python3.6/json/__init__.py", line 299, in load
>     parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
>   File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
>     return _default_decoder.decode(s)
>   File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
>     obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib/python3.6/json/decoder.py", line 357, in raw_decode
>     raise JSONDecodeError("Expecting value", s, err.value) from None
> json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
> make: *** Deleting file 'Makefile.mtest'
> 
> followed by:
> 
> ERROR: Cannot find Ninja

The most likely cause is that the Makefile is forcing configure to rerun
because you don't have ninja in config-host.mak; this works (as shown by
the error) but only after mtest2make has barfed.  I can add a dependency
from Makefile.mtest to config-host.mak which technically isn't needed
but doesn't hurt.

OpenBSD and NetBSD call the ninja package "ninja-build" unlike FreeBSD.
 I'm sure I had used the right name but well I didn't.  I'll send a v3.

Paolo

On Sat, 17 Oct 2020 at 14:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
> OpenBSD and NetBSD call the ninja package "ninja-build" unlike FreeBSD.
>  I'm sure I had used the right name but well I didn't.  I'll send a v3.

OpenBSD built OK but meson produces this new warning:

Library iconv found: NO
../src/meson.build:531: WARNING: iconv required for curses UI but not
available, disabling

thanks
-- PMM

On 17/10/20 16:39, Peter Maydell wrote:
> On Sat, 17 Oct 2020 at 14:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> OpenBSD and NetBSD call the ninja package "ninja-build" unlike FreeBSD.
>>  I'm sure I had used the right name but well I didn't.  I'll send a v3.
> 
> OpenBSD built OK but meson produces this new warning:
> 
> Library iconv found: NO
> ../src/meson.build:531: WARNING: iconv required for curses UI but not
> available, disabling

Hrm, the curses test was not plainly converted from shell to meson (guys
please do *one* thing per patch, things are already complex enough!);
and it is messed up in more ways than I had first noticed (of which the
most blatant is using /usr/include/ncursesw as a library path).  I'll
fix everything up and resend this pull request when I'm done.

I'm not sure if that will remove the warning or not, but I'll check (and
if it does remain, it'll be of the "useful" kind which documents some
unexpected dependency between options).

Paolo

On 17/10/20 17:37, Paolo Bonzini wrote:
> On 17/10/20 16:39, Peter Maydell wrote:
>> Library iconv found: NO
>> ../src/meson.build:531: WARNING: iconv required for curses UI but not
>> available, disabling
> 
> I'm not sure if that will remove the warning or not, but I'll check (and
> if it does remain, it'll be of the "useful" kind which documents some
> unexpected dependency between options).

Ok, so the warning remains when everything is fixed, though the text is
slightly different (and better):

  Library iconv found: NO
  Run-time dependency ncursesw found: NO (tried pkgconfig)
  Library ncursesw found: YES
  Library cursesw found: NO
  ../src/meson.build:540: WARNING: curses library not usable, disabling

In this case, meson.build warns because curses doesn't always have a .pc
file; therefore when meson.build doesn't find the headers it can't but
proceed without curses suport.

The "library found"/"curses support disabled" situation is a bit
confusing, which is why I've been adding some kind of message for those
few cases in which we cannot just use pkg-config.  (The multipath test
is already warning, but those libraries are a bit niche so you probably
don't even have the libraries installed).

Peter, I would like your input on these two things:

1) are you going to pull v3 and I can fix up everything later?  Or would
you prefer me to send v4 once the new curses test is reviewed?

2) would you prefer the "library was found but headers weren't" to warn,
issue an informative message, or be completely silent?

Paolo

On Sat, 17 Oct 2020 at 17:37, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Ok, so the warning remains when everything is fixed, though the text is
> slightly different (and better):
>
>   Library iconv found: NO
>   Run-time dependency ncursesw found: NO (tried pkgconfig)
>   Library ncursesw found: YES
>   Library cursesw found: NO
>   ../src/meson.build:540: WARNING: curses library not usable, disabling
>
> In this case, meson.build warns because curses doesn't always have a .pc
> file; therefore when meson.build doesn't find the headers it can't but
> proceed without curses suport.

> The "library found"/"curses support disabled" situation is a bit
> confusing, which is why I've been adding some kind of message for those
> few cases in which we cannot just use pkg-config.  (The multipath test
> is already warning, but those libraries are a bit niche so you probably
> don't even have the libraries installed).
>
> Peter, I would like your input on these two things:
>
> 1) are you going to pull v3 and I can fix up everything later?  Or would
> you prefer me to send v4 once the new curses test is reviewed?

If the only issue with v3 is that stray warning message I'm
OK with applying it and improving the test later.

> 2) would you prefer the "library was found but headers weren't" to warn,
> issue an informative message, or be completely silent?

I think the build system should just say whether it found a
working curses setup or not, and do our usual "this is fatal
if --enable-whatever, otherwise just disable feature". If we
happen to have convenient information to put in whatever
the new build system's equivalent of config.log is [ie the
saved-for-debug-purposes log], we might as well put it in,
but we don't need to put that in the stdout. (We shouldn't
say "ncurses found: YES" unless we actually found a working
version, ideally.)

thanks
-- PMM

On 17/10/20 21:48, Peter Maydell wrote:
>> 1) are you going to pull v3 and I can fix up everything later?  Or would
>> you prefer me to send v4 once the new curses test is reviewed?
> 
> If the only issue with v3 is that stray warning message I'm
> OK with applying it and improving the test later.

Yes.

>> 2) would you prefer the "library was found but headers weren't" to warn,
>> issue an informative message, or be completely silent?
> 
> I think the build system should just say whether it found a
> working curses setup or not, and do our usual "this is fatal
> if --enable-whatever, otherwise just disable feature". If we
> happen to have convenient information to put in whatever
> the new build system's equivalent of config.log is [ie the
> saved-for-debug-purposes log], we might as well put it in,
> but we don't need to put that in the stdout. (We shouldn't
> say "ncurses found: YES" unless we actually found a working
> version, ideally.)

Ok, I think we can at least use cc.find_library(has_headers: '...') to
avoid warning for the most basic failure mode, and then use cc.links()
to further refine the check.  If the curses header is present but the
test program fails to link, then we are in the same situation as the
multipath check and warning makes sense.

Paolo

On Sat, Oct 17, 2020 at 11:37 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 17/10/20 16:39, Peter Maydell wrote:
> > On Sat, 17 Oct 2020 at 14:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> OpenBSD and NetBSD call the ninja package "ninja-build" unlike FreeBSD.
> >>  I'm sure I had used the right name but well I didn't.  I'll send a v3.
> >
> > OpenBSD built OK but meson produces this new warning:
> >
> > Library iconv found: NO
> > ../src/meson.build:531: WARNING: iconv required for curses UI but not
> > available, disabling
>
> Hrm, the curses test was not plainly converted from shell to meson (guys
> please do *one* thing per patch, things are already complex enough!);
Oh, sorry for that,
> and it is messed up in more ways than I had first noticed (of which the
> most blatant is using /usr/include/ncursesw as a library path).  I'll
> fix everything up and resend this pull request when I'm done.
>
> I'm not sure if that will remove the warning or not, but I'll check (and
> if it does remain, it'll be of the "useful" kind which documents some
> unexpected dependency between options).
>
> Paolo
>


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo