Skip to content
Snippets Groups Projects
Select Git revision
  • riscv-cbqri-rfc-v2
  • riscv-cbqri-rfc
  • staging
  • master default protected
  • stable-7.2
  • stable-6.1
  • stable-6.0
  • stable-6.0-staging
  • stable-5.0
  • stable-4.2
  • stable-4.1
  • stable-4.0
  • stable-3.1
  • stable-3.0
  • stable-2.12
  • stable-2.11
  • stable-2.10
  • stable-2.9
  • stable-2.8
  • stable-2.7
  • v8.0.0-rc3
  • v7.2.1
  • v8.0.0-rc2
  • v8.0.0-rc1
  • v8.0.0-rc0
  • v7.2.0
  • v7.2.0-rc4
  • v7.2.0-rc3
  • v7.2.0-rc2
  • v7.2.0-rc1
  • v7.2.0-rc0
  • v7.1.0
  • v7.1.0-rc4
  • v7.1.0-rc3
  • v7.1.0-rc2
  • v7.1.0-rc1
  • v7.1.0-rc0
  • v7.0.0
  • v7.0.0-rc4
  • v7.0.0-rc3
40 results
Search by author
  • Any Author
0 authors
  1. Apr 20, 2023
  3. Mar 24, 2023
  5. Mar 21, 2023
  7. Mar 16, 2023
    • Peter Maydell's avatar
      docs/sphinx/kerneldoc.py: Honour --enable-werror · 36420664
      Peter Maydell authored 
      Currently, the kerneldoc Sphinx plugin doesn't honour the
--enable-werror configure option, so its warnings are never fatal.
This is because although we do pass sphinx-build the -W switch, the
warnings from kerneldoc are produced by the scripts/kernel-doc script
directly and don't go through Sphinx's "emit a warning" function.

When --enable-werror is in effect, pass sphinx-build an extra
argument -Dkerneldoc_werror=1.  The kerneldoc plugin can then use
this to determine whether it should be passing the kernel-doc script
-Werror.

We do this because there is no documented mechanism for
a Sphinx plugin to determine whether sphinx-build was
passed -W or not; if one is provided then we can switch to
that at a later date:
https://github.com/sphinx-doc/sphinx/issues/11239



Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
Message-Id: <20230314114431.1096972-1-peter.maydell@linaro.org>
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
      36420664
  9. Mar 15, 2023
  11. Mar 10, 2023
  13. Mar 08, 2023
  15. Mar 07, 2023
  17. Mar 05, 2023
  19. Mar 03, 2023
  21. Mar 02, 2023
  23. Mar 01, 2023
  25. Feb 27, 2023
  27. Feb 23, 2023
  29. Feb 20, 2023
    • Paolo Bonzini's avatar
      docs: build-platforms: refine requirements on Python build dependencies · 8d0efbcf
      Paolo Bonzini authored 
      
Historically, the critical dependency for both building and running
QEMU has been the distro packages.  Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like conda or wrapdb), C dependencies of QEMU would target the
version that is shipped in relatively old but still commonly used distros.

For non-C libraries, however, the situation is different, as these
languages have their own package management tool (cpan, pip, gem, npm,
and so on).  For some of these languages, the amount of dependencies
for even a simple program can easily balloon to the point that many
distros have given up on packaging non-C code.  For this reason, it has
become increasingly normal for developers to download dependencies into
a self-contained local environment, instead of relying on distro packages.

Fortunately, this affects QEMU only at build time, as qemu.git does
not package non-C artifacts such as the qemu.qmp package; but still,
as we make more use of Python, we experience a clash between a support
policy that is written for the C world, and dependencies (both direct
and indirect) that increasingly do not care for the distro versions
and are quick at moving past Python runtime versions that are declared
end-of-life.

For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62
(released the following March) already dropped support for it.  Yet,
Python 3.6 is the default version of the Python runtime for RHEL/CentOS
8 and SLE 15, respectively the penultimate and the most recent version
of two distros that QEMU would like to support.  (It is also the version
used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022).

There are good reasons to move forward with the deprecation of Python
3.6 in QEMU as well: completing the configure->meson switch (which
requires Meson 0.63), and making the QAPI generator fully typed (which
requires newer versions of not just mypy but also Python, due to PEP563).

Fortunately, these long-term support distros do include newer versions of
the Python runtime.  However, these more recent runtimes only come with
a very small subset of the Python packages that the distro includes.
Because most dependencies are optional tests (avocado, mypy, flake8)
and Meson is bundled with QEMU, the most noticeably missing package is
Sphinx (and the readthedocs theme).  There are four possibilities:

* we change the support policy and stop supporting CentOS 8 and SLE 15;
  not a good idea since CentOS 8 is not an unreasonable distro for us to
  want to continue to support

* we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
  supported.  This is a possibility---but we may want to revise the support
  policy anyway because SLE 16 has not even been released, so this would
  mean delaying those desirable reasons for perhaps three years;

* we support Python 3.6 just for building documentation, i.e. we are
  careful not to use Python 3.7+ features in our Sphinx extensions but are
  free to use them elsewhere.  Besides being more complicated to understand
  for developers, this can be quite limiting; parts of the QAPI generator
  run at sphinx-build time, which would exclude one of the areas which
  would benefit from a newer version of the runtime;

* we only support Python 3.7+, which means CentOS 8 CI and users
  have to either install Sphinx from pip or disable documentation.

This proposed update to the support policy chooses the last of these
possibilities.  It does by modifying three aspects of the support
policy:

* it introduces different support periods for *native* vs. *non-native*
  dependencies.  Non-native dependencies are currently Python ones only,
  and for simplicity the policy only mentions Python; however, the concept
  generalizes to other languages with a well-known upstream package
  manager, that users of older distributions can fetch dependencies from;

* it opens up the possibility of taking non-native dependencies from their
  own package index instead of using the version in the distribution.  The
  wording right now is specific to dependencies that are only required at
  build time.  In the future we may have to refine it if, for example, parts
  of QEMU will be written in Rust; in that case, crates would be handled
  in a similar way to submodules and vendored in the release tarballs.

* it mentions specifically that optional build dependencies are excluded
  from the platform policy.  Tools such as mypy don't affect the ability
  to build QEMU and move fast enough that distros cannot standardize on
  a single version of them (for example RHEL9 does not package them at
  all, nor does it run them at rpmbuild time).  In other cases, such as
  cross compilers, we have alternatives.

Right now, non-native dependencies have to be download manually by
running "pip" before "configure".  In the future, it will be desirable
for configure to set up a virtual environment and download them in the
same way that it populates git submodules (but, in this case, without
vendoring them in the release tarballs).

Just like with submodules, this would make things easier for people
that can afford accessing the network in their build environment; the
option to populate the build environment manually would remain for
people whose build machines lack network access.  The change to the
support policy neither requires nor forbids this future change.

[Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions
 that were copied or summarized in the above commit message]

Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8d0efbcf
  31. Feb 17, 2023
  33. Feb 16, 2023