When g-i feature is disabled, the gobject-introspection package
dependency is not pulled in but pygobject has a hard dependency on it.
(From OE-Core rev: 7fae697c6889e17dd47415808a7173670b507047)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an option to enable/disable build of graphene-gobject. When
enabled, add glib dependency (not pulled in implicitly if
the gobject-introspection feature is disabled).
Default is to enable gobject-types so that graphene-gobject is built
(dependency of gtk4).
(From OE-Core rev: b82781498cda67f4797de5b8b7c2b90a275a72e1)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the report-error catch Nothing PROVIDES error and then
we can check it directly via error report web.
(From OE-Core rev: a57d8f82b83554c821a83eacc02f9c73b263ff02)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rebase patches; one of the vendored crossbeam versions
has been removed upstream, and so crossbeam_atomic.patch
is adjusted accordingly.
Replace getrandom-open64.patch with a backport.
(From OE-Core rev: f5accb4fae49342cbec21718ae7a427615bfcedd)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it triggers a rebuild of llvm-dependent rust pieces every time rust_runx is called,
lengthening the builds without need.
(From OE-Core rev: aca6b29b508175da9f213b1c6dba5d02a15b8287)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream does not actually use or test it this way; if the goal
is to install items, then install target should be executed directly.
In particular, in latest rust release building stage 2 items has regressed
altogether (incorrect dependencies between rust-analyze tool and the
libs it needs) and no one noticed.
(From OE-Core rev: 7d805f9a9f6b5048308a37a2757d08cca40b1ff3)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* when searching for qemuboot.conf
* don't assume that IMAGE_LINK_NAME is always
<rootfs>-<machine> (with <rootfs>-<machine>.qemuboot.conf)
* runqemu: use IMAGE_LINK_NAME set by testimage.bbclass or query with bitbake -e
* testimage.bbclass was setting DEPLOY_DIR which I don't see used
anywhere else, so I assume it was supposed to be DEPLOY_DIR_IMAGE as mentioned
in corresponding runqemu code, do the same with IMAGE_LINK_NAME variable
* add virtual/kernel as bitbake -e target in run_bitbake_env to make
sure IMAGE_LINK_NAME is defined (kernel-artifact-names.bbclass inherits
image-artifact-names.bbclass as well)
* improve .qemuboot.conf search
1st search for file matching the rootfs and only when not found
try again with .rootfs suffix removed
[YOCTO #12937]
(From OE-Core rev: 716eb55bb963db7b02d985849cb025898aabc855)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Remove note to section not carrying information about
special hosts tools for oe-selftest
- Add links to mentioned repositories
CC: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Measured by generating a "core-image-sato" image for a "qemux86-64"
machine from an Ubuntu 22.04 VM with 4 cores.
Less memory was not enough and caused Out of Memory failures.
(From yocto-docs rev: a05f87929eed43cef673a8c2581899a8c9ccf462)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tests made on Poky master on March 16, 2023.
Add a "Free Disk Space" section to the "System Requirements" document.
(From yocto-docs rev: 285ba689ce3ab7b7fdb4bb0d0284e2a52ad62c7f)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we do not enter password during login, it is expected to display message "Login timed out after 60 seconds". But it prints only first few bytes(like "Login t") when write is immediately followed by exit.
Fix - Calling exit from new handler provides enough time to display full message.
Upstream-Status: Accepted [670cae8348]
(From OE-Core rev: 644cfe9dcf351bfa6c67f4b4d1e7dec416a59021)
Signed-off-by: Soumya <soumya.sambu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native
and gobject-introspection package dependencies are not pulled in
but avahi has a hard dependency on them (do_configure fails due
to missing introspection.m4 file, do_compile fails due to missing
glib-mkenums).
(From OE-Core rev: fea90325b180ba8d2b19704dc8911a9175527c61)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but at-spi2-core has a hard dependency on it
(do_configure fails due to missing glib-genmarshal).
(From OE-Core rev: 954411393a50b8d09cc42f1098e54193d6b19e1d)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but libgudev has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 8fd140011f89ededdfd7feb1c0e3a2d67e06808a)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but json-glib has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 2d67634d778bce9efdad9df75b3fe3e224708d7f)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, glib-2.0-native package
dependency is not pulled in but harfbuzz has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 77e6edba704873d21c2cf946d1be18e13abb9f5e)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* It was showing whole log and that the runqemu command failed, but not
where the log file is, nor why it thinks the runqemu failed
[YOCTO #12937]
(From OE-Core rev: ad4b72e6524114a3bdee10cab71f194ea143cd24)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was searching for line like this:
ROOTFS: [/OE/build/poky/build/build-st-2023-03-20-esdk-runqemu-patch1/runqemu.RunqemuTests.test_boot_machine_ext4/build-st/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20230320081121.rootfs.ext4]
but with IMAGE_NAME_SUFFIX changed to something else than default ".rootfs"
or with my pending changes the line looks like this:
ROOTFS: [/OE/build/poky/build/build-st-2023-03-20-esdk-runqemu-patch2/runqemu.RunqemuTests.test_boot_machine_ext4/build-st/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-20230320085744.ext4]
and test was failing.
* Check for whole line starting with ROOTFS: and ending just with .ext4
[YOCTO #12937]
(From OE-Core rev: 7a0f622f23aff2c4eeca0606e7682931eb53287a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ultimately we'll remove this and use for better rust reproducibility
testing too.
(From OE-Core rev: 6c6536a41bfb8651fe94d90898207c5b53673e44)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A project can have multiple Cargo.lock (provides
multiple binaries for example) and each one can
depends on differenct version of the same crates.
Even within the same Cargo.lock file, it is possible
to have different version of same crates.
To avoid conflicts, override the name with the version
for all crates checksum
Moreover, when searching for Cargo.lock, we should ignore
specific dir like .git (no use to walk down there) and .pc
(because it can have a Cargo.lock if this file was patched)
(From OE-Core rev: 1795e98a04ad09b011afcc7cc3bf6dc49475b19a)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe is for showing a "real world" example of
a crate that depends on some git repositories.
Usually, this kind of crate is built within a global
workspace (here it is the zbus project) and so
doesn't need a Cargo.lock on its own.
For the sake of the demonstration, I had to tweak things
a little to be able to compile zvariant in standalone
(no relative path in dependency, no symlink to LICENSE
provide a Cargo.lock)
The use case where the crate had some git repository
in dependency is very common for "private" crate that
are not aimed to be published on crates.io.
When the project grow bigger, it is common to have
a bin and multiple lib developped in parallel, and these
libs are surely on a git repostitory.
A test case have been also added to check for:
- the previous patch about git subpath parameter and devtool
- the correctness of overriding dependencies (first patch of the
series)
(From OE-Core rev: 409e045f96f69877de6f36ed14c5c19a9cb74eaf)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is for a specific case where:
- A recipe use a subpath on a git repo (e.g. git://repo.git/projects;subpath=subproject)
- The recipe contains a patch to apply
- a devtool modify is used on this recipe
With these conditions, the patch cannot be applied at all.
GitApplyTree class is used for handling patch under devtool, but
when subpath is present in SRC_URI, the resulting git tree
is dirty (every files and directories which was not in subpath are suppressed)
and so "git am" refuse to apply patches.
That would not be an issue since the GitApplyTree have a fallback
to PatchTree in case of error, but during this error management,
there is a "git reset --hard HEAD" call which suppress the subpath
operation and finally prevents the patch to be applied even with PatchTree.
When devtool is not involved, only PatchTree class is used and the
above problem is irrelevant.
To support git patching during devtool, the presence of subpath and
the dirtyness of the repo are checked. If both conditions are
met, we directly call PatchTree like it was already done
in case of error during git apply.
(From OE-Core rev: d86cac2759cf7e91f4ff240833385e28e729ab79)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without that, the possible git urls that are in SRC_URI of a recipe
are removed from SRC_URI during devtool process and so the
cargo_common_do_patch_paths in cargo_common.bbclass cannot
patch these packages to fetch them locally.
I use a generic type name because I foresee this change will
be useful for recipe that used a package manager (cargo but also
npm) see https://bugzilla.yoctoproject.org/show_bug.cgi?id=11015
(From OE-Core rev: 474658a3681c343385c359a21c3693401217298d)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since disable network was added cargo configurations which reference git
repos fail as they attempt to fetch across the network as part of
do_compile, even if EXTRA_OECARGO_PATHS to add them as part of `paths`
is used, as this is documented as only working for packages which exist
in crates.io.
Add parsing of the SRC_URIs for git repos and include `[patch]` sections
to redirect to the checked out source repos which the bitbake fetcher
has already populated.
There are still cases which don't work - if you have multiple copies of
the same repo with different revisions, there's currently no way to
represent that and anything using a repo which has a virtual manifest
will fail to build (see https://github.com/rust-lang/cargo/issues/4934).
(From OE-Core rev: 684a8af41c5bb70db68e75f72bdc4c9b09630810)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
(From OE-Core rev: fb62c4c3dbca4e58f7ce6cf29d4b630a06411a97)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* There is no need to be that precise. It just irritates in the logs.
* There is also no point in printing plain time.time() value a single
time while only using formatted printout everywhere else, thus remove
it.
* Use %d for printing integer times
(From OE-Core rev: f0988cb8cf8d03708490cca4eba345492ef78d52)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since login user is configurable with boot_patterns['send_login_user'],
unconditionally using 'root' in the debug message can be confusing.
Also fix the debug message to say 'Logged in' instead of 'Logged'.
(From OE-Core rev: 900e3d42b918b5a33d8d952b3a8078fbe72ba98f)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is already set above, thus simply use the set value from there.
(From OE-Core rev: 2f6571ffb23b1a0b5bd6a1212fc108e536f04539)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'tempfile' and 'oeqa.utils.command.runCmd' are unused while 'os' is
actually used.
(From OE-Core rev: 50f766233e83528eebeca92877277374c7193530)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python modules aren't supposed to have uppercase characters in their names
according to python conventions. We have regexs in the code which work
on that assumption too. Rather than showing errors under some filtering
situations, make it clear and error if a problematic name is seen.
(From OE-Core rev: 7964a6ee54e881a6128707a7f2a42eec2ed63881)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the signature file into place only after it is successfully signed.
This to avoid race and corrupted .sig files in cases multiple onging
builds write to a shared sstate-cache dir.
(From OE-Core rev: b4ec08ea9efebac262d43f47d95a356fe2829de9)
Signed-off-by: Tobias Hagelborn <tobiasha@axis.com>
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cmake bbclass already sets the path to the correct Python for us,
and there appears to be no more scripts in the build which use 'python'
explicitly.
(From OE-Core rev: abbac1588163b63746928403d524a09532875d5a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LIB_INSTALL_DIR was removed in libgit2 1.0 when they moved to using
GNUInstallDirs.
BUILD_CLAR is now BUILD_TESTS as of libgit2 1.4.
(From OE-Core rev: 9d321a4abf2ee35647293f5ec7e4c354974b45c6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe uses the cmake class, so there's no need to set the Ninja
backend, or tell it where Python is, or that we're cross-compiling.
(From OE-Core rev: 2560665cc1e30a6ca969118ade8612393e1eef74)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
