hwclock.sh had default update-rc parameters which made it run after
other tasks that work with the clock such as connman. This causes a
time obtained by NTP to be clobbered by a potentially incorrect time
in the RTC.
Provide non-default INITSCRIPT_PARAMS to have hwclock.sh run during
the rc startup before runlevel initscripts start.
(From OE-Core rev: 3012bac35ada9a9f66d9e6e2fecaee09527b9d44)
Signed-off-by: Chris Elledge <celledge@siteworx.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since bitbake commit 81a58647b2f4fc0a2589b2978fc9d81b2bfe6aec
[bitbake: build: Make python output print to stdout when running with
-v (verbose)] we no longer need to comment out the python stdout
checks.
(From OE-Core rev: 67886a8473c511c8ab3db2e4587cc5a070979d11)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The qemu build system enables the 'log' trace backend by default, if no
explicit choice was made with '--enable-trace-backend=CHOICE'.
However, the qemu recipe uses the following PACKAGECONFIG line:
PACKAGECONFIG[ust] = "--enable-trace-backend=ust,--enable-trace-backend=nop,lttng-ust,"
which means that the 'nop' trace backend will be explicitly selected if the
'ust' feature is not enabled. The 'nop' backend removes almost all trace
points at compile time, and thus basically means 'disable tracing'.
To retain the default trace backend if 'ust' is not enabled, the above
PACKAGECONFIG line should either explicitly fall back to the 'log' backend,
or not provide any value for the 'disabled' case. This commit chooses the
latter to not make any assumption about the upstream default.
(From OE-Core rev: c31396a30dcf17ab23ff4dd5943eef5fba20cba6)
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'#line' directives written by qemu's tracetool makes the 'debug' package not
reproducible due to absolute paths. Apply a patch to use a relative path
instead.
(From OE-Core rev: 85e30c507b63fa9126887dc6435d1ee6e23bd887)
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple CVEs are patched in kernel but appear as active because the NVD
database is not up to date.
In common file cve-extra-exclusion.inc, CVEs are ignored if and only if
all versions of kernel used are patched.
In cve-exclusion_6.1.inc, only ignore CVEs that are patched in v6.1,
and not patched in v5.15.
Recipes of version 6.1 should include this file.
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
(From OE-Core rev: 5feb065f1b1aaf218f71cc9d31a9251b139b9442)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the previous commit I somehow mixed up and used an incorrect CVE number.
Use the correct one.
(From OE-Core rev: b3e2729f686ff6e16e11590bcd701c057ae5f1e2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Take a patch submitted upstream for the issue while upstream decide what
to do. We don't use thunderbird integration so this isn't an issue for us.
(From OE-Core rev: b85b7714a44caa70beb2f115483ee52745aa1b97)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've increased the minimum GCC version to 8.0[1] so update the
documentation to match.
[1] sanity.bbclass: Update minimum gcc version to 8.0
(From yocto-docs rev: c74254fa7406c76b26e47b968685115699f95c55)
Signed-off-by: Ross Burton <ross.burton@arm.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 vte has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 686e0cb93f9f6ef663243e62c7a8cc43ca1dcd3a)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of only display the first and stop.
For recipe (crago based) that can contains several artifacts
to fetch with their checksum, it will particularly handy
to display all of missing one.
An example of error message would be
NOTE: Executing Tasks
ERROR: zvariant-3.12.0-r0 do_fetch: Missing SRC_URI checksum, please add those to the recipe:
SRC_URI[anyhow-1.0.70.sha256sum] = "7de8ce5e0f9f8d88245311066a578d72b7af3e7088f32783804676302df237e4"
SRC_URI[chrono-0.4.24.sha256sum] = "4e3c5919066adf22df73762e50cffcde3a758f2a848b113b586d1f86728b673b"
SRC_URI[serde-1.0.158.sha256sum] = "771d4d9c4163ee138805e12c710dd365e4f44be8be0503cb1bb9eb989425d9c9"
SRC_URI[system-deps-1.3.2.sha256sum] = "0f3ecc17269a19353b3558b313bba738b25d82993e30d62a18406a24aba4649b"
ERROR: zvariant-3.12.0-r0 do_fetch: Bitbake Fetcher Error: BBFetchException('There was some missing checksums in the recipe')
ERROR: Logfile of failure stored in: /home/jenkins/yocto-poky-master/poky/build/tmp/work/core2-64-poky-linux/zvariant/3.12.0-r0/temp/log.do_fetch.1025
ERROR: Task (/home/jenkins/yocto-poky-master/poky/meta-selftest/recipes-extended/zvariant/zvariant_3.12.0.bb:do_fetch) failed with exit code '1'
(Bitbake rev: dafa07c080e05975b6319b5adf78a9691c6b6643)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An upcoming change will simplify the setuptools3-base FILES assignments,
which means this recipe needs to package a library explicitly.
(From OE-Core rev: bab2e8c76453cf9982af936f20c6b22cc2237ba7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If these files exist they should be packaged into PN-dev, and are with
the default FILES:${PN}-dev.
(From OE-Core rev: 738434bf567d25de692cd145156263eea1a5de13)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simply inheriting setuptools3-base should put everything in $libdir in
PN, and there's no need to replicate the pkgconfig packaging rules as
those are the defaults.
(From OE-Core rev: 56a32e31d4fdfb908f0edf513d21bc0f2b8c721e)
Signed-off-by: Ross Burton <ross.burton@arm.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 libnotify has a hard dependency on it
(do_configure fails due to missing glib-mkenums).
(From OE-Core rev: 63cc22caf4dfcde1d7a3a8410559bb227ed95c33)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When gobject-introspection feature is disabled, gettext-native and
glib-2.0-native dependencies are not pulled in, which causes failures
in do_compile due to missing xgettext and gdbus-codegen.
(From OE-Core rev: c9e4c3d437ba7cadb87bc30b85f602b8551a0e17)
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
and gobject-introspection package dependencies are not pulled in
but gconf has a hard dependency on them (do_configure fails due to
missing introspection.m4 file and glib-gettextize).
(From OE-Core rev: d87bc67fde3c8bc6068cb67708953ce88ac31e3f)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
