make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap,

make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap, as well as in CentOS. Therefore
there is no need anymore to ship the sources together with the QEMU
tarballs.

Keep the wrap file so that it can be used with --enable-download,
but do not ship the sources anymore with either archive-source.sh
or make-release.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap,

make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap, as well as in CentOS. Therefore
there is no need anymore to ship the sources together with the QEMU
tarballs.

Keep the wrap file so that it can be used with --enable-download,
but do not ship the sources anymore with either archive-source.sh
or make-release.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap,

make-release: do not ship dtc sources

A new enough libfdt is included in all of Debian 11, Ubuntu 20.04
and MSYS2. It has also been included for several minor releases
in Fedora and openSUSE Leap, as well as in CentOS. Therefore
there is no need anymore to ship the sources together with the QEMU
tarballs.

Keep the wrap file so that it can be used with --enable-download,
but do not ship the sources anymore with either archive-source.sh
or make-release.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...

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 ...

remove remaining traces of meson submodule

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

remove remaining traces of meson submodule

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

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 ...

build-sys: add meson submodule

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

archive-source: also create a stash for submodules

"git archive" fails when a submodule has a modification, because "git
stash create" doesn't handle submodules. Let's teach our
archive-source.sh to

archive-source: also create a stash for submodules

"git archive" fails when a submodule has a modification, because "git
stash create" doesn't handle submodules. Let's teach our
archive-source.sh to handle modifications in submodules the same way
as qemu tree, by creating a stash.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190708200250.12017-1-marcandre.lureau@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

show more ...

scripts: use git archive in archive-source

Use git archive to create tarballs of qemu and submodules instead of
cloning the repository and the submodules. This is a order of magnitude
faster becaus

scripts: use git archive in archive-source

Use git archive to create tarballs of qemu and submodules instead of
cloning the repository and the submodules. This is a order of magnitude
faster because it doesn't fetch the submodules from the internet each
time the script runs.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190520124716.30472-2-kraxel@redhat.com>
[AJB: fixed up tabs]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

show more ...

build-sys: move slirp as git submodule project

The slirp project is now hosted on freedesktop at:
https://gitlab.freedesktop.org/slirp.

The libslirp source was extracted from qemu/slirp filtered th

build-sys: move slirp as git submodule project

The slirp project is now hosted on freedesktop at:
https://gitlab.freedesktop.org/slirp.

The libslirp source was extracted from qemu/slirp filtered through
clang-format (available in project tree). The qemu slirp directory can
be swapped by a git submodule.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190424110041.8175-3-marcandre.lureau@redhat.com>
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

show more ...

archive-source.sh: Clone the submodules locally

We cloned the QEMU repository from the local storage. Since the
submodules are also available there, clone them too. This is
quicker and reduce networ

archive-source.sh: Clone the submodules locally

We cloned the QEMU repository from the local storage. Since the
submodules are also available there, clone them too. This is
quicker and reduce network use.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[AJB: incorporated review suggestions from danpb]
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

show more ...

scripts/archive-source: include softfloat tests

We need these if we want to run unit/softfloat tests in our docker
containers.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richa

scripts/archive-source: include softfloat tests

We need these if we want to run unit/softfloat tests in our docker
containers.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

show more ...