meson: subprojects: replace berkeley-{soft,test}float-3 with wraps

Unlike other subprojects, these require an overlay directory to include
meson rules to build the libraries. The rules are basicall

meson: subprojects: replace berkeley-{soft,test}float-3 with wraps

Unlike other subprojects, these require an overlay directory to include
meson rules to build the libraries. The rules are basically lifted
from tests/fp/meson.build, with a few changes to create platform.h
and publish a dependency.

The build defines are passed through a subproject option, and posted
back to users of the library via the dependency's compile_args.

The only remaining user of GIT_SUBMODULES and GIT_SUBMODULES_ACTION
is roms/SLOF, which is used to build pc-bios/s390-ccw. All other
roms submodules are only present to satisfy the license on pre-built
firmware blobs.

Best reviewed with --color-moved.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: subprojects: replace submodules with wrap files

Compared to submodules, .wrap files have several advantages:

* option parsing and downloading is delegated to meson

* the commit is stored in

meson: subprojects: replace submodules with wrap files

Compared to submodules, .wrap files have several advantages:

* option parsing and downloading is delegated to meson

* the commit is stored in a text file instead of a magic entry in the
git tree object

* we could stop shipping external dependencies that are only used as a
fallback, but not break compilation on platforms that lack them.
For example it may make sense to download dtc at build time, controlled
by --enable-download, even when building from a tarball. Right now,
this patch does the opposite: make-release treats dtc like libvfio-user
(which is not stable API and therefore hasn't found its way into any
distros) and keycodemap (which is a copylib, for better or worse).

dependency() can fall back to a wrap automatically. However, this
is only possible for libraries that come with a .pc file, and this
is not very common for libfdt even though the upstream project in
principle provides it; it also removes the control that we provide with
--enable-fdt={system,internal}. Therefore, the logic to pick system
vs. internal libfdt is left untouched.

--enable-fdt=git is removed; it was already a synonym for
--enable-fdt=internal.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing dow

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing downloads with .wrap files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source file

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source files.

This is also the first step towards managing downloads with .wrap
files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing dow

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing downloads with .wrap files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source file

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source files.

This is also the first step towards managing downloads with .wrap
files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing dow

meson: use subproject for keycodemapdb

By using a subproject, our own meson.build can use variables from
the subproject instead of hard-coded paths. This is also the first step
towards managing downloads with .wrap files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source file

meson: use subproject for internal libfdt

Recent dtc/libfdt can use either Make or meson as the build system.
By using a subproject, our own meson.build can remove the hard
coded list of source files.

This is also the first step towards managing downloads with .wrap
files instead of submodule.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

qemu.git: drop meson git submodule

Now that meson is installed from a vendored wheel, we don't need the git
submodule anymore. Drop it.

Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <2023

qemu.git: drop meson git submodule

Now that meson is installed from a vendored wheel, we don't need the git
submodule anymore. Drop it.

Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <20230511035435.734312-19-jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

qemu.git: drop meson git submodule

Now that meson is installed from a vendored wheel, we don't need the git
submodule anymore. Drop it.

Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <2023

qemu.git: drop meson git submodule

Now that meson is installed from a vendored wheel, we don't need the git
submodule anymore. Drop it.

Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <20230511035435.734312-19-jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

hw/misc/sga: Remove the deprecated "sga" device

It's been deprecated since QEMU v6.2, so it should be OK to
finally remove this now.

Message-Id: <20230209161540.1054669-1-thuth@redhat.com>
Reviewed

hw/misc/sga: Remove the deprecated "sga" device

It's been deprecated since QEMU v6.2, so it should be OK to
finally remove this now.

Message-Id: <20230209161540.1054669-1-thuth@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

hw/misc/sga: Remove the deprecated "sga" device

It's been deprecated since QEMU v6.2, so it should be OK to
finally remove this now.

Message-Id: <20230209161540.1054669-1-thuth@redhat.com>
Reviewed

hw/misc/sga: Remove the deprecated "sga" device

It's been deprecated since QEMU v6.2, so it should be OK to
finally remove this now.

Message-Id: <20230209161540.1054669-1-thuth@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged

Remove the slirp submodule (i.e. compile only with an external libslirp)

Since QEMU 7.1 we don't support Ubuntu 18.04 anymore, so the last big
important Linux distro that did not have a pre-packaged libslirp has
been dismissed. All other major distros seem to have a libslirp package
in their distribution already - according to repology.org:

Fedora 35: 4.6.1
CentOS 8 (RHEL-8): 4.4.0
Debian 11: 4.4.0
OpenSUSE Leap 15.3: 4.3.1
Ubuntu LTS 20.04: 4.1.0
FreeBSD Ports: 4.7.0
NetBSD pkgsrc: 4.7.0
Homebrew: 4.7.0
MSYS2 mingw: 4.7.0

The only one that was still missing a libslirp package is OpenBSD - but
the next version (OpenBSD 7.2 which will be shipped in October) is going
to include a libslirp package. Since QEMU 7.2 will be published after
OpenBSD 7.2, we should be fine there, too.

So there is no real urgent need for keeping the slirp submodule in
the QEMU tree anymore. Thus let's drop the slirp submodule now and
rely on the libslirp packages from the distributions instead.

Message-Id: <20220824151122.704946-7-thuth@redhat.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

vfio-user: build library

add the libvfio-user library as a submodule. build it as a meson
subproject.

libvfio-user is distributed with BSD 3-Clause license and
json-c with MIT (Expat) license

Sign

vfio-user: build library

add the libvfio-user library as a submodule. build it as a meson
subproject.

libvfio-user is distributed with BSD 3-Clause license and
json-c with MIT (Expat) license

Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: c2adec87958b081d1dc8775d4aa05c897912f025.1655151679.git.jag.raman@oracle.com

[Changed submodule URL to QEMU's libvfio-user mirror on GitLab. The QEMU
project mirrors its dependencies so that it can provide full source code
even in the event that its dependencies become unavailable. Note that
the mirror repo is manually updated, so please contact me to make newer
libvfio-user commits available. If I become a bottleneck we can set up a
cronjob.

Updated scripts/meson-buildoptions.sh to match the meson_options.txt
change. Failure to do so can result in scripts/meson-buildoptions.sh
being modified by the build system later on and you end up with a dirty
working tree.
--Stefan]

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

show more ...

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we do not need to ship this as a submodule anymore.

Message-Id: <20220516145823.148450-4-thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we do not need to ship this as a submodule anymore.

Message-Id: <20220516145823.148450-4-thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we

capstone: Remove the capstone submodule

Now that we allow compiling with Capstone v3.0.5 again, all our supported
build hosts should provide at least this version of the disassembler
library, so we do not need to ship this as a submodule anymore.

Message-Id: <20220516145823.148450-4-thuth@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

gitmodules: Correct libvirt-ci submodule URL

Correct the libvirt-ci repository URL to avoid this warning when
cloning / refreshing the submodule:

warning: redirecting to https://gitlab.com/libvir

gitmodules: Correct libvirt-ci submodule URL

Correct the libvirt-ci repository URL to avoid this warning when
cloning / refreshing the submodule:

warning: redirecting to https://gitlab.com/libvirt/libvirt-ci.git/

Fixes: 4ebb040f1fd ("tests: integrate lcitool for generating build env manifests")
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20220121154134.315047-3-f4bug@amsat.org>
Message-Id: <20220204204335.1689602-7-alex.bennee@linaro.org>

show more ...

tests: integrate lcitool for generating build env manifests

This introduces

https://gitlab.com/libvirt/libvirt-ci

as a git submodule at tests/lcitool/libvirt-ci

The 'lcitool' program within thi

tests: integrate lcitool for generating build env manifests

This introduces

https://gitlab.com/libvirt/libvirt-ci

as a git submodule at tests/lcitool/libvirt-ci

The 'lcitool' program within this submodule will be used to
automatically generate build environment manifests from a definition
of requirements in tests/lcitool/projects/qemu.yml

It will ultimately be capable of generating

- Dockerfiles
- Package lists for installation in VMs
- Variables for configuring Cirrus CI environments

When a new build pre-requisite is needed for QEMU, if this package
is not currently known to libvirt-ci, it must first be added to the
'mappings.yml' file in the above git repo.

Then the submodule can be updated and the build pre-requisite added
to the tests/lcitool/projects/qemu.yml file. Now all the build env
manifests can be re-generated using 'make lcitool-refresh'

This ensures that when a new build pre-requisite is introduced, it
is added to all the different OS containers, VMs and Cirrus CI
environments consistently.

It also facilitates the addition of containers targetting new distros
or updating existing containers to new versions of the same distro,
where packages might have been renamed.

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20211215141949.3512719-8-berrange@redhat.com>
Message-Id: <20220105135009.1584676-8-alex.bennee@linaro.org>

show more ...

gitmodules: use GitLab repos instead of qemu.org

qemu.org is running out of bandwidth and the QEMU project is moving
towards a gating CI on GitLab. Use the GitLab repos instead of qemu.org
(they wil

gitmodules: use GitLab repos instead of qemu.org

qemu.org is running out of bandwidth and the QEMU project is moving
towards a gating CI on GitLab. Use the GitLab repos instead of qemu.org
(they will become mirrors).

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20210111115017.156802-3-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

show more ...