As of meson 0.56.0, `<lang>_args` and `<lang>_link_args` in the
`[properties]` section are deprecated and should be placed in the
`[built-in options]` section instead.
Source: https://mesonbuild.com/Machine-files.html#properties
Fixes the following deprecation warnings:
> DEPRECATION: c_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
> DEPRECATION: c_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
> DEPRECATION: cpp_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
> DEPRECATION: cpp_link_args in the [properties] section of the machine file is deprecated, use the [built-in options] section.
Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add missing space for the cross-compilation.conf.in cpu_family
entry.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Meson expects known cpu families to be in a normalized format based on
https://mesonbuild.com/Reference-tables.html#cpu-families
Add support for m68k, microblaze and sh4 cpu families.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Drop fix rpath match pattern patch which is now upstream.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The version of this patch merged by upstream has some changes to rpath
syntax matching and handling for additional syntax edge cases.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The upstream change in d7235c5905fa98207d90f3ad34bf590493498d5b is not
sufficient to prevent rpaths from being stripped in some cases due to
a bug in how it matches rpaths in LDFLAGS.
Add a patch fixing the LDFLAGS rpath match pattern.
Fixes:
http://autobuild.buildroot.net/results/f2f/f2f912416ab11d454479ef3d22ed6b757207f84f/
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Drop fix rpath patch which is no longer needed.
Drop g-ir-scanner/g-ir-compiler override patch which is now upstream.
Rebase remaining patches.
Meson now requires single quotes for cross-compilation.conf, replace
double quotes with single quotes.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since cf75d7da98 we have a build failures when
building libgbm.so when valgrind package is selected because --static is always
passed to pkg-config even for shared build.
Even if -Dvalgrind=false on meson command line to build mesa, the valgrind
libraries come from pkg-config libdrm...
output/host/bin/pkg-config libdrm --libs --static
-L[...]/sysroot/usr/lib -ldrm -lm -L[...]/sysroot/usr/lib/valgrind
-lcoregrind-arm64-linux -lvex-arm64-linux -lgcc
... and break the build.
See initial discussions:
http://lists.busybox.net/pipermail/buildroot/2020-June/284543.html
This is due to a wrong condition test added by the patch
0004-mesonbuild-dependencies-base.py-add-pkg_config_stati.patch.
Indeed, pkg_config_static is a string, not a boolean; it is set to
either 'true' or 'aflse' by our meson package infra. Since the returned
object is a string, do not pass a boolean, but pas None (we only want to
test against the 'true' string, so we don't care what we get back when
it is not set, which never happens in Buildroot).
Before this patch, the issue can be reproduced using the following defconfig:
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_PACKAGE_VALGRIND=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_SWRAST=y
Fixes:
http://autobuild.buildroot.net/results/1b5/1b58d73ecbbe1af2c3e140563d696cf32d1c4a5a/build-end.log
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: slightly reword the commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We need to backport a commit to allow us to override the g-ir-scanner
and g-ir-compiler binaries in the gnome module.
By default since meson looks for these binaries as native: true
dependencies it would use the host versions instead of the wrappers
which are not useable for target package builds. Override this behavior
by specifying the correct wrapper binaries in cross-compilation.conf.
Fixes:
http://autobuild.buildroot.net/results/f49/f49bb57a6ec2890f489fbd55ced9c9249d066334/build-end.log
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- expand on why the backported patch does not closely match upstream
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Our pkg-config wrapper is not used since commit
4e0bc29993, this raise static build
failures with libglib2 because --static is not passed anymore to
pkg-config so add a patch to get back the old behaviour.
The patch was proposed upstream
https://github.com/mesonbuild/meson/pull/6629, and the feedback was
not very positive. However, we need a solution that works for
Buildroot now, and this proposal is simple enough.
Fixes:
http://autobuild.buildroot.org/results/0d36952def63cb69628697fa6408aeb6ce10cb5b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Remove patches that are now upstream.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, meson hard codes the paths of these binaries which results in
cross-compiled environments to run the host versions of these tools.
However, GObject-introspection provides the appropriate paths to these
utilities via pkg-config
find_program is needed in the case g-i is built as a subproject. If
g-ir-scanner or g-ir-compiler are in the build or source directory use those.
If they aren't found in the source directory, use the results from pkg-config.
Backport two upstream commits to fix the issue.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The values in the cross-compilation file are expected to be quoted with
single quotes, which we have in our template.
However, the endian value we are injecting comes from Kconfig, so it is
double-quoted, and those quotes end up in the cross-compilation files we
generate (the internal one, and the SDK one):
endian = '"little"'
So qstrip the value before we inject it.
Propagate the fix to the two generated files by using the same variable
HOST_MESON_TARGET_ENDIAN in both cases, rather than replicating the
(flawed) logic.
While at it, also use the common GCC_TARGET_CPU variable for the SDK
file too.
Signed-off-by: Gleb Mazovetskiy <glex.spb@gmail.com>
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
meson is able to distinguish between host (= native) and target (=
cross) compilation. It will explicitly pass different options to
pkg-config to distinguish them. Therefore, we don't need to use the
pkg-config wrapper when using meson, and can instead pass the pkg-config
settings through the cross-compilation.conf.
This is important because in some situations (e.g. for the Python
configuration), meson sets the PKG_CONFIG_LIBDIR variable to a different
value before calling pkg-config. Relying on our wrapper script doesn't
work in that case (except if the script would unconditionally set
PKG_CONFIG_LIBDIR, which it doesn't do at the moment).
Add the sys_root and pkg_config_lib settings to cross-compilation.conf
and use pkgconf directly instead of the wrapper.
Note that this requires us to substitute STAGING_DIR as well, with an
absolute path. This is not a big deal since cross-compilation.conf is
regenerated for every package.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
To allow meson to distinguish between pkg-config for host (= native)
and pkg-config for target (= cross), we want to be able to give a
different pkg_config_libdir for host and for target. meson already has a
'sys_root' option that sets the sysroot that is used by pkg-config, but
we also need explicit search directories for pkg-config.
Therefore, back-port an upstream patch (will be included in 0.54) that
adds this feature.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
pkg-meson defines variables _MESON_SED_CFLAGS, _MESON_SED_LDFLAGS and
_MESON_SED_CXXFLAGS that reformat the make-style flags (space-separated
and unquoted) as meson-style flags (comma-separated and double-quoted).
Similar variables are also defined in meson.mk. A future patch will add
even more similar cases.
However, we already have a macro that does something similar for
generating JSON output: make-comma-list. So let's use that. However,
make-comma-list doesn't add all the shell-expanded magic like
_MESON_SED_CFLAGS, which results in the double quotes being removed by
the shell. Therefore, we also need to change the quoting around it to
single quotes instead of double quotes. For consistency, the quotes of
the other sed expressions are changed as well. Except for the
_MESON_EXTRA_BINARIES: the values set by packages (e.g. mesa3d) already
contain single quotes, so changing the surrounding double quotes to
single quotes would break them.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[yann.morin.1998@free.fr: slight fix in commit log]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The meson script includes the full path to the python interpreter. In
deep build trees, this path can be more than 128 characters long, which
is the limit for how long a shebang may be.
Notice that this has been bumped to 256 since kerel 5.1, but the issue still
persists:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eb3c3d0a52dca337e327ae8868ca1f44a712e02
In older kernels, this limit was silently ignored, leading to potential
bugs, but newer kernels enforce that limit, and refuse to execve() the
script, returning with NOEXEC. Since the script is +x, the shell (any
bourne shell, as well as the C shell) will conclude from that situation that
they should interpret it as a shell script, which it obviously is not.
Fix the problem by replacing the shebang with a call to /usr/bin/env
which will redirect to the correct python3 interpreter found in the
PATH.
Note however that this means our meson installation can no longer be
called from outside of the meson-package infrastructure anymore (not
that we ever supported it before, but who knows what people may have
done in their br2-external), unless one does set the PATH to include
$(HOST_DIR)/bin/ earlier than a system-provided python3 would be found.
Fixes: #12331#12461
Reported-by: Jean-pierre Cartal <jpcartal@free.fr>
Reported-by: Matthias Weißer <m.weisser.m@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Removed patch that is now upstream.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
package/meson installs a cross-compilation.conf file in
$(HOST_DIR)/etc/meson, via TARGET_FINALIZE_HOOKS.
package/pkg-cmake.mk installs a toolchainfile.cmake in
$(HOST_DIR)/share/buildroot, via TOOLCHAIN_POST_INSTALL_STAGING_HOOKS.
Both files have a similar concept, they describe some flags/paths needed for
compilation using respective build systems. One difference is that the meson
file is added for external compilation, from the SDK, while the cmake file
is used internally in Buildroot.
The 'problem' of using TARGET_FINALIZE_HOOKS for the meson file, is that it
installs a 'host' file from target-finalize, which is conceptually incorrect
since not just TARGET_DIR but also HOST_DIR is "regenerated" on a subsequent
'make' when everything was already built (i.e. only target-finalize is run).
This can easily be fixed, by using the same hook as cmake uses, i.e.
TOOLCHAIN_POST_INSTALL_STAGING_HOOKS.
Note that actually even for cmake, TOOLCHAIN_POST_INSTALL_STAGING_HOOKS is
not the best hook to install a host file. A better hook would have been
TOOLCHAIN_POST_INSTALL_HOOKS, but this triggers only for 'host' packages,
and 'toolchain' is treated as a 'target' package.
Also, the hook (and therefore also the definition of
PKG_MESON_INSTALL_CROSS_CONF) is moved to pkg-meson.mk, again to make it
more similar to how it's done for cmake. Otherwise check-package
complains that the meson package is setting variables that don't start
with MESON_.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This patch adds a case in the library pattern logic to prefer static
libraries when the Meson Core option for "default_library" is set to
solely static.
The existing library search order makes sense for cases of shared and
shared / static mixed. However if using a prebuilt cross-toolchain,
they usually provide both a static and shared version of sysroot
libraries. This presents a problem in a complete static build where
there won't be shared libraries at runtime and during build time there
are failures like "ld: attempted static link of dynamic object".
Bug:
https://github.com/mesonbuild/meson/issues/6108
Fixes:
http://autobuild.buildroot.net/results/db1740b4777f436324218c52bc7b08e5c21b667d/http://autobuild.buildroot.net/results/c17/c17bbb12d9deadd64a441b36e324cfbbe8aba5be/
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Meson does not allow to pass CFLAGS/LDFLAGS/CXXFLAGS via the environment
or via command-line arguments or options (instead, those flags from the
environment are passed to the host compiler, which is seldom what we
need). The only way to pas those flags is via the cross-compilation.conf
file.
Add LIBFOO_CFLAGS, LIBFOO_LDFLAGS and LIBFOO_CXXFLAGS variables to allow
packages to provide their own flags, possibly overriding the generic
ones entirely, as we allow for other infras. Those per-package flags will
then be used to generate the per-package cross-compilation.conf.
This means that the meson infra is the first and only infra for which
FOO_CFLAGS, FOO_LDFLAGS, and FOO_CXXFLAGS are meaningful, while for the
other infras, they are just variables private to the package itself.
Instead of naming those variables after the meson infra (e.g.
FOO_MESON_CFLAGS), we name them with a generic name, as maybe, just
maybe, we could also change the other infras to also recognise those
variables.
Just like for the HOST_MESON_SED_CFLAGS etc., we need to add auxiliary
variables to do convert the shell-formatted argument list into the
JSON-formatted list that meson expects. We can't use a pure-make
construct because the CFLAGS can contain quoting that needs to be
expanded by the shell. Similarly, we need a condition on the strip'ed
variable to avoid passing empty arguments.
To mimic this feature for packages that are built from the SDK, we also
install a templatised version of cross-compilation.conf, with three new
placeholders for custom flags. If a user wants to build a package that
needs custom flags, they can use that template to generate a per-package
cross-compilation.conf.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When TARGET_CFLAGS (or _LDFLAGS or _CXXFLAGS) are empty, but were
constructed by appending other variables, like:
TARGET_CFLAGS = $(SOMETHING) $(SOMETHING_ELSE)
and both variables are empty, then $(TARGET_CFLAGS) is _not_ the
null-string; it's value is a string made of a single space.
This means that the construct:
$(if $(TARGET_CFLAGS),true,false)
will in fact return 'true'.
In our case, it means that we will call:
`printf '"%s", ' `
which expands to just:
"",
which we are then happy to insert as-is in the generated
cross-compilation.conf.
Then meson, will happily call the compiler with an empty argument.
The compiler is less happy, though:
arm-none-linux-gnueabi-gcc: error: : No such file or directory
And this is not even trivial to debug either... The only clue being that
there seems to be something missing between ': :'
We fix that testing the $(strip)ed value. We can still pass the
non-$(strip) expansion, because the shell will just do it for us, and we
are then sure there is at least one non-blank word in there.
Thanks a lot to Adam for his invaluable help debugging this!
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Cc: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested against systemd and glib-networking.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas: use the upstream-uploaded tarball and not the github macro,
which allows to have the tarball that really matches upstream's GPG
signature]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Currently, package/meson/meson.mk generates a single global
cross-compilation.conf file, with the path to the compiler, cflags,
ldflags, and various other details. This file is then used when
building all meson-based packages.
This causes two problems:
- It is not compatible with per-package directories, because with
per-package folders, we need to use a different compiler, and
possibly CFLAGS/LDFLAGS for each package.
- It is not possible to define per package CFLAGS. Indeed, when
cross-compiling, meson doesn't support passing CFLAGS through the
environment, only the CFLAGS from cross-compilation.conf are taken
into account.
For this reason, this commit:
- Introduces a per-package cross-compilation.conf, which is generated
by the pkg-meson infrastructure in the "configure" step right
before calling meson. The file is generated in $(@D)/build/, and
because it is generated within a given package "configure" step,
the compiler path is the one of this package.
- Keeps the global cross-compilation.conf in $(HOST_DIR)/etc/meson/,
for the SDK use-case of Buildroot. Since we want the final and
global values of the compiler path, CFLAGS and LDFLAGS, generating
this global cross-compilation.conf is moved to a
TARGET_FINALIZE_HOOKS. If we were keeping this as a
HOST_MESON_POST_INSTALL_HOOKS, it would contain values specific to
the host-meson package.
For now, we don't yet support per-package CFLAGS/LDFLAGS, but having
such per-package cross-compilation.conf is a necessary preparation to
achieve this goal.
This commit has been tested by building all Buildroot packages that
use meson: json-glib, systemd, enlightenment, at-spi2-core, ncmpc,
libmpdclient and ncmpc.
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
[Thomas:
- add extended commit log
- in pkg-meson.mk, re-use variables defined in meson.mk to do the
replacement of CFLAGS/LDFLAGS/CXXFLAGS
- move the generation of the global cross-compilation.conf to a
TARGET_FINALIZE_HOOKS
- testing with per-package folders]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This version requires host-python3-setuptools, because meson no longer
falls back to distutils for its installation if setuptools cannot be
found: setuptools *must* be available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As explained in [0], meson recognises a certain set of CPU famillies,
whose names slightly differ from those we know them as.
If we don't pass the proper cpu_familly, meson whines:
WARNING: Unknown CPU family 'i686', please report this at [...]
Subsequently, packages that use that to decide on what they should build
and how they should build it, fail to build. That is the case for the
upcoming systemd-boot, for example.
Fix that by using the list propvided by the meson documentation [0].
[0] https://mesonbuild.com/Reference-tables.html#cpu-families
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- split in its own patch
- imnprove commit log
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As explained in [0], meson will try on its own to decide whether it can
run what it builds. If it happens that the host and target CPUs are
"compatible", that test may fail and meson may believe it can run what
it builds.
Override that test by using needs_exe_wrapper=true, and not defining an
actual exe_wrapper.
[0] https://mesonbuild.com/Cross-compilation.html
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- split in its own patch
- improve commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Note, that there is already a patch [1] to bump the version to 0.48.1.
However, the bump to version 0.48.x has some unresolved issues.
In the meantime, until the issue with 0.48 is resolved, bump to latest
version of the 0.47 branch.
[1] http://patchwork.ozlabs.org/patch/986260/
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The patch to skip RPATH fixing performed by Meson was removed in commit
a03f46ca6e, as the script
support/scripts/check-host-rpath was not complaining anymore.
But without it, the problem still occurs for host packages [1].
So, restore this patch to fix build of host packages with Meson.
[1] http://lists.busybox.net/pipermail/buildroot/2018-October/232956.html
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The BR2_GCC_TARGET_* configuration variables are copied to
corresponding GCC_TARGET_* variables which may then be optionally
modified or overwritten by architecture specific makefiles.
All makefiles must use the new GCC_TARGET_* variables instead
of the BR2_GCC_TARGET_* versions.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas: simplify include of arch/arch.mk]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- delete legacy patch 0001-Only-fix-RPATH-if-install_rpath-is-not-empty.patch
(no complains from support/scripts/check-host-rpath even without the patch)
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Acked-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Tested-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
By default, Meson strips RPATH from the executable it builds [1,2],
unless explicitly set via install_rpath.
This will make support/scripts/check-host-rpath fail when building the
host variant of a Meson-based package.
So add a patch to prevent RPATH from being stripped if install_rpath is
not set and notify user about it.
[1] https://github.com/mesonbuild/meson/issues/2567
[2] https://github.com/mesonbuild/meson/issues/314#issuecomment-157658562
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Bump version and drop obsolete patch.
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
