There is a bug in patch 2.7.3 and earlier where index lines
in patches can change file modes when they shouldn't:
http://git.savannah.gnu.org/cgit/patch.git/patch/?id=82b800c9552a088a241457948219d25ce0a407a4
This leaks into debug sources in particular (e.g. tcp-wrappers where
source files are read-only). Add the dependency to target recipes
to avoid this problem until we can rely on 2.7.4 or later.
We could try and remove all index lines from patch files but it will be a
losing battle. We could try and identify all the recipes which change
modes on files in patches but again, its a losing battle.
Instead, compromise and have patch-native as a dependency
for target recipes. We use patch-replacement-native since patch-native
is in ASSUME_PROVIDED.
Also add nativesdk-patch to buildtools-tarball.
[YOCTO #13777]
(From OE-Core rev: 5ed0840c93804488cd1c1aba6cb382b2434714a5)
(From OE-Core rev: fd3bd61a6fe5190c575dc968f3a0be9c1cbf21ed)
(From OE-Core rev: 148f1f8caf5d9a262c1f55e437326ce6139a743e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Defers the resolution of the SOURCE_DATE_EPOCH until the variable needs
to be actually realized with a value. The previous method of loading the
value in anonymous python had issues because it could occur before other
anonymous python functions that affect the location of the epoch file,
such as when a recipe uses AUTOINC/AUTOREV or allarch.bbclass.
Also adds more logging to help diagnose issues in the future.
[YOCTO #13763]
(From OE-Core rev: b3313a10a3eb93f0a3710a35de0404fb49cd6202)
(From OE-Core rev: 10515e5f7e38edbc4430e2599062a9ce6fdb42a8)
(From OE-Core rev: 81d3832728aeae0e02e775bab9fc13e159fb61d3)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the naming of the loader on armhf to match what glibc expects:
#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT SYSTEMLIBS_DIR "ld-linux.so.3"
#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT SYSTEMLIBS_DIR "ld-linux-armhf.so.3"
(From OE-Core rev: 70efe880589df1dfe7d71451d62d9d8e4afd7981)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7ad531093d620f18c04d487d79e9dad9f5a96232)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, there was SRC_DISTRIBUTE_LICENSES, an undocumented
variable that contained a static list of licenses. It was used by
expand_wildcard_licenses() to expand any wildcards used in, e.g.,
INCOMPATIBLE_LICENSE. However, since this static list of licenses has
not been kept up-to-date, many licenses were missing, with the result
that if one tried to use any of those licenses with a wildcard, no
licenses would be found, effectively ignoring that they should be
marked as incompatible.
This introduces a new (documented) variable, AVAILABLE_LICENSES, that
is automatically updated to contain all licenses found in any
directories specified by ${COMMON_LICENSE_DIR} and ${LICENSE_PATH},
and uses it instead of SRC_DISTRIBUTE_LICENSES when expanding
wildcards.
(From OE-Core rev: 5ed714139f91eb03871e01b68a4370784071234d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8c9ef587fe499c612a878a1ab42092eb79b334ef)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since this file is written during recipe parsing, having it in the
${BUILDDIR}/conf directory, which is covered by an inotify watcher,
will trigger a re-parse the next time bitbake is run and the resident
bitbake server is enabled. This causes the sanity_info file to be
updated again, which triggers a new parse the next time bitbake is run
ad infinitum. Moving it to ${BUILDDIR}/cache should avoid this.
(From OE-Core rev: f1a609e7176a37e7e5f86f0b786f7da915085f83)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f98103b548aa7dba6b1be6c8e02ef41858a8e85c)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the sanity_info file has moved from the conf directory to the
cache directory, there is no longer any need to clean it away
explicitly in clean_esdk_builddir() since the whole cache directory is
already cleaned away anyway.
(From OE-Core rev: f0ea8b49a183d9340aaf0c60ee959aa8ec3c041c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 40c30990e1be72130819c040fe471e2bdc0c6e7d)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In commit 692b2046 (package: Fix race between do_package and
do_packagedata), the path used for do_packagedata[sstate-inputdirs]
was changed from "${PKGDESTWORK}" to "${WORKDIR}/pkgdata-pdata-input".
This commit adapts the path used for pkgdatadir in
toaster_package_dumpdata() accordingly to avoid setscene errors like:
ERROR: libgcc-9.2.0-r0 do_packagedata_setscene: Error executing a
python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function:
<module>
0001:
*** 0002:toaster_package_dumpdata(d)
0003:
File: 'meta/classes/toaster.bbclass', lineno: 130, function:
toaster_package_dumpdata
0126: lpkgdata = {}
0127: datadir = os.path.join(pkgdatadir, 'runtime')
0128:
0129: # scan and send data for each generated package
*** 0130: for datafile in os.listdir(datadir):
0131: if not datafile.endswith('.packaged'):
0132: lpkgdata = _toaster_load_pkgdatafile(datadir,
0133: # Fire an event containing the pkg data
0134: bb.event.fire(bb.event.MetadataEvent(
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'tmp/work/mips32r2el-nf-poky-linux/libgcc/9.2.0-r0/pkgdata/runtime'
(From OE-Core rev: c1d881448fea0bc48aba0bc0e5b8748442572226)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5a0f6f631b86f7107aa72453b6d23f32ba39f713)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some mips 64 bit platforms use vmlinux.64 image name
Make a symbol link to vmlinux.64 in arch/mips/boot/
(From OE-Core rev: f9739e0f58f5d8a5dc01fdb0efaa778af4edd671)
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 70626b52e5e61c80018e9f1f85bc169d0434b986)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When doing reproducible builds inherit podfix to remove the possibility
of differing Perl versions causing manpages to change.
(From OE-Core rev: 3534f17752eccdd62eac8809d7842e9d25fa770a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5dc43edab4787906f2c9f51e51bf78d1dc966286)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Manpages generated by Pod::Man contain the version number, which isn't
reproducible if we're using the host Perl to generate manpage.
One option is to always depend on perl-native when generating manpages
but this is a heavy dependency, so instead strip out the versions in
do_install().
(From OE-Core rev: 88255abe6bb4d10d50a660022ab3f9a1c2954ec7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 18d8e5ac689d6eb6098f68ac785f43e9d5f5938a)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids a directory not present error.
Fix a comment typo whilst here.
(From OE-Core rev: c5f285f83ea1e322d5124847904adf488d3e790a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1360d8d7d99b70a80c8cdbc1fc6d9e6752483139)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous patches meant the mkdir might no longer match the final target
directory. Fix this.
(From OE-Core rev: 7ce42a30a7508e8fcb496ba05cf6967dc04a988e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0af4dae84099e8632a9ea6a4afdbea2f232bb170)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
STATE_PKG may have been changed by sstate_report_unihash so don't
cache the variable's value.
(From OE-Core rev: bfed8be91525478ecdf6b64e6308958b3271c8cc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit be29a25400c4ea285ab3f588c5831f00ba5d4f63)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its rather antisocial to overwrite SSTATE_PKG with an expanded form for the variable
and it stops the value of BB_UNIHASH being changed when the package is written out.
Instead of expanding the variable, append to it instead to avoid this rather
hard to figure out behaviour and allow the siggen code to behave as expected.
(From OE-Core rev: fe454e9c7837a903ffcff4c6f8a25070a0f0af82)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 62eca02024b4c44d618ab9bcf87a3166c886dadb)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its confusing to keep seeing sstate summary messages when hash equivalency is
active. This adds an option to control it. A default value is given which
maintains compatibility with different bitbake versions.
(From OE-Core rev: a67bd96de2b253c1d4c3bd82120f28dee06a4bf6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 038004866ff6650bcff7bb1bde36de6c0f451d29)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As Alex Kanavin found, dependencies aren't always populated, particularly
with the hash equivalence server enabled locally:
'bitbake core-image-minimal' with gtk+ disabled.
can confirm with: $ tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -display gtk
qemu-system-x86_64: Display 'gtk' is not available.
Enable gtk in local.conf with: PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"
'bitbake core-image-minimal', without deleting tmp/
$ tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-x86_64 -display gtk
qemu-system-x86_64: Display 'gtk' is not available.
This change ensures the dependencies are correctly handled as the full
sysroot is always depended upon even if things come from sstate.
(From OE-Core rev: d40853b10dd9f01d6a8dd4edcb941cfa8a544922)
(From OE-Core rev: 309424458c73b14a4a4020cd508c2bf37bf2bcbe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch to recently released version 1.1 of NVD CVE JSON feed, as in
https://nvd.nist.gov/General/News/JSON-1-1-Vulnerability-Feed-Release
it is mentioned that
Due to changes required to support CVSS v3.1 scoring, the JSON
vulnerability feeds must be modified. This will require the consumers
of this data to update their internal processes. We will be providing
the JSON 1.1 schema on the data feeds page and the information below
to prepare for this transition.
...
The JSON 1.1 data feeds will be available on September 9th, 2019. At
that time the current JSON 1.0 data feeds will no longer available.
This change was tested briefly by issuing 'bitbake core-image-minimal'
with 'cve-check.bbclass' inherited via local.conf, and then comparing
the content between the resulting two
'DEPLOY_DIR_IMAGE/core-image-minimal-qemux86.cve' files, which did not
seem to contain any other change, except total of 167 entries like
CVSS v3 BASE SCORE: 0.0
were replaced with similar 'CVSS v3 BASE SCORE:' entries which had
scores that were greater than '0.0' (up to '9.8').
(From OE-Core rev: cc20e4d8ff2f3aa52a2658404af9a0ff358cc323)
(From OE-Core rev: c92b8804d6e59b2707332859957f0e6a46db0a73)
Signed-off-by: Niko Mauno <niko.mauno@iki.fi>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Meson has support for downloading subprojects using something called
wraps. This interferes with bitbake's expectations of all downloads
being done by the fetch task. To avoid this, tell meson to not
download any wraps.
Suggested-by: Mattias Jernberg <mattias.jernberg@axis.com>
(From OE-Core rev: b547637ad84bad8f7fe27193bf636541f8588ae8)
(From OE-Core rev: 4170718196ca734e5dd7635fc98b55ea47a74e88)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_prepare_recipe_sysroot may perform groupadd, which requires pseudo.
However, do_prepare_recipe_sysroot does not depend on pseudo explicitly,
which sometimes causes a build error when building a recipe that adds
groups.
This issue only occurs when executing do_prepare_recipe_sysroot for a
recipe that adds groups before finishing a task that depends on pseudo
for a recipe that doesn't add groups.
(From OE-Core rev: e20a67fe9cc7de042f39f3c39b74de61dc5c6dfe)
Signed-off-by: Mattias Hansson <mattihn@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code used to construct a single SQL statement that fetched the NVD data for
every CVE requested. For recipes such as the kernel where there are over 2000
CVEs to report this can hit the variable count limit and the query fails with
"sqlite3.OperationalError: too many SQL variables". The default limit is 999
variables, but some distributions such as Debian set the default to 250000.
As the NVD table has an index on the ID column, whilst requesting the data
CVE-by-CVE is five times slower when working with 2000 CVEs the absolute time
different is insignificant: 0.05s verses 0.01s on my machine.
(From OE-Core rev: 53d0cc1e9b7190fa66d7ff1c59518f91b0128d99)
(From OE-Core rev: 3ded9a64c95ae02df7562fc69e2af08c150d2452)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A previous optimisation was premature and resulted in false-negatives in the report.
Rewrite the checking algorithm to first get the list of potential CVEs by
vendor:product, then iterate through every matching CPE for that CVE to
determine if the bounds match or not. By doing this in two stages we can know
if we've checked every CPE, instead of accidentally breaking out of the scan too
early.
(From OE-Core rev: d61aff9e22704ad69df1f7ab0f8784f4e7cc0c69)
(From OE-Core rev: 0f42a1d4dbb74ab39e81449cf222302bcc04f7db)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch scanner works with patch files in the layer, not in the workdir, so it
doesn't need to unpack.
(From OE-Core rev: 2cba6ada970deb5156e1ba0182f4f372851e3c17)
(From OE-Core rev: 02e6b727bf62858be7dba061879a6d57bd5a725d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Older versions break opkg-build when reproducible builds are enabled.
Rather than trying to be selective based on which features are enabled,
lets just make this a minimum version.
(From OE-Core rev: 96f5c7c2f8dda7d47af5398b3463aa25921f5301)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVEs that are whitelisted or were not vulnerable when there are version
comparisons were not included in the report, so alter the logic to ensure that
all relevant CVEs are in the report for completeness.
(From OE-Core rev: 29d926802e7f8b4614a2dafa0af4c923912e1811)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By exporting ICECC_CC, ICECC_CXX, and ICECC_VERSION in a wrapper-script,
and putting this wrapper-script in the PATH, the Makefiles generated by CMake or
the autotools are able to function correctly outside of bitbake.
This provides a convenient developer workflow in which the
modify-compile-unittest cycle can happen directly in the ${B} directory.
The `rm -f $ICE_PATH/$compiler` line is transitional,
and can go at some later date (October 2020 or later, perhaps).
(From OE-Core rev: 0f47d4ef50d6b0732ac40f7ede31f554a757864c)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 40d74cb1d0ddce930267e49764cacb263b244091)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case multiple builds share UNINATIVE_DLDIR's location, one build
might be in the process of downloading the tarball while another is
just checking whether the tarball exists. Check for the done file
instead and rely on the fetchers lockfile mechanism in case two
builds are running.
(From OE-Core rev: 956ae2c2a72914c7e9a1d59e5906c7fc75670a39)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a1c95580549cb4f77601e62c7f026b19c752d853)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SDK_VENDOR isn't formatted as -foosdk and is instead for example -foo-sdk
then the triple that are constructed are not in fact triples, which results in
mysterious compile errors.
Check in sanity.bbclass so this failure is detected early.
[ YOCTO #13573 ]
(From OE-Core rev: 95d3ca54453cdb0662fae2a2cf7e8173611c86f4)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b0efd8d4d0dbc30e6505b42f5603f18fa764d732)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk builds such as nativesdk-dnf are installing systemd
service files, leading bitbake to throw installed-vs-shipped
warnings, but these are not needed in nativesdk:
WARNING: nativesdk-dnf-4.2.2-r0 do_package: QA Issue: nativesdk-dnf: Files/directories were installed but not shipped in any package:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-makecache.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-makecache.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-notifyonly.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-download.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-download.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-notifyonly.service
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-install.timer
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/lib/systemd/system/dnf-automatic-install.service
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
nativesdk-dnf: 13 installed and not shipped files. [installed-vs-shipped]
Rather than have each recipe remove the files, an RMINITDIR case
for nativesdk builds should be added to systemd.bbclass.
(From OE-Core rev: 86092fdac2ed2935b25a6c05f16055df77a10575)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The readelf binary is prefixed, so export READELF in the SDKs so that the
correct readelf binary can be used.
This fixes problems with the symbol extractor in Meson with multilib SDKs where
readelf can't be found correctly.
(From OE-Core rev: 2795e3bfdefc9f48294802ea7301dae1910553dc)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
perlocal.pod is an index file of locally installed modules and so shouldn't be
installed by any distribution packages. cpan.bbclass already sets NO_PERLOCAL
to stop this file being generated by most Perl recipes, but if a recipe is using
MakeMaker directly (such as rrdtool) then they might not be doing this
correctly.
To avoid multiple packages shipping this file and then failing to install
together, add a QA test to check if this file exists and by default emit an
error if it does.
[ YOCTO #13491 ]
(From OE-Core rev: 5d16d265cc61c4e279fe3bf66016a00d9daa4068)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* in oe-core commit 1860d9d3c62e2e94cd68a809385873ffd8270b6d I've accidentally
removed the backshash here
Reported-By: "Hilsdorf, Jan (LAWO)" <Jan.Hilsdorf@lawo.com>
(From OE-Core rev: 44f0047c0268f3e9f9fdf78f93bdad9bfe491174)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Turn:
ERROR: Unable to parse Var <OE_IMPORTED[:=]>
Traceback (most recent call last):
File "Var <OE_IMPORTED[:=]>", line 1, in <module>
File "/media/build1/poky/meta/classes/base.bbclass", line 35, in oe_import(d=<bb.data_smart.DataSmart object at 0x7f1d941ad208>):
for toimport in oe.data.typed_value("OE_IMPORTS", d):
> imported = __import__(toimport)
inject(toimport.split(".", 1)[0], imported)
File "/media/build1/poky/meta/lib/oe/sstatesig.py", line 267, in <module>:
>class SignatureGeneratorOEEquivHash(SignatureGeneratorOEBasicHashMixIn, bb.siggen.SignatureGeneratorUniHashMixIn, bb.siggen.SignatureGeneratorBasicHash):
name = "OEEquivHash"
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception AttributeError: module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn'
into:
ERROR: Error importing OE modules: module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn'
which can then trigger a version mismatch error message.
(From OE-Core rev: 5b01726d1cf478aba8d1acc73e29f6cab0c9371e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
packagegroups whose dependencies are affected by MACHINE_FEATURES
need to be marked as MACHINE_ARCH *before* inheriting the
packagegroup class, not after.
This has changed in commit 9c826962ec8f
("packagegroup: Make allarch inherit conditional"),
commit 4f3f34deaf in poky but the comment here
wasn't updated at the time.
(From OE-Core rev: 7eae2502936aa36401491cd1e0e5975db96529ae)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create bash-completion-pkgs image feature to load *-bash-completion packages
into an image. The packages are created by the bash-completion
bbclass but are currently never loaded.
(From OE-Core rev: d47c5981877555a5a6b9aeb93ea6f3c1aa97fc44)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have a compiler, so no icecc.
Silences a spew of warnings of the form:
do_configure: Cannot use icecc: could not get ICECC_CC or ICECC_CXX
(From OE-Core rev: 0315aabeff8e6483b737d0e23d6841f1394ad3c8)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Creates the source data epoch file destination directory when restoring
from sstate
(From OE-Core rev: f5259a62d444dfc221a9ba592dbca35564f794ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Write out the hash equiv cache file into any eSDK so that it doesn't rely
on having to call the hash server for the basic data requests.
(From OE-Core rev: 05c6842e747261b3350d6325e238429cf8728ca0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
set in the ramdisk node the compression property
always to "none", as U-Boot nowadays since commit:
b1307f884a91 ("fit: Support compression for non-kernel components (e.g. FDT)")
decompress non kernel components. Setting compression
to the used comression algorithm now, will end in
fail of your kernel boot with the ramdisk.
This issue is fixed since commit:
bddd98573465 ("fit: Do not automatically decompress ramdisk images")
which now prints a warning in U-Boot, instead of decompressing
the ramdisk, but we should setup compression property correct.
(From OE-Core rev: f963a51544a9a7b1abbaa87c95b3c0279847d697)
Signed-off-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The deployment of the source date epoch file had a race condition where
any task attempting to read from the file would race with creation of
the sstate archive for the do_deploy_source_date_epoch task. The
creation of the sstate archive requires moving the directory to a
temporary location, then moving it back. This means that the file
disappears for a short period of time, which will cause a failure if any
other task is running and trying to open the file to get the current
source date epoch.
The solution is to copy the source date epoch file to a separate
directory when deploying so the file never disappears. When the file is
restored from sstate, it is moved to the correct location after being
extracted.
[YOCTO #13501]
(From OE-Core rev: ac27d12fe5480e9b8cc93de6a32bf9631c52d7f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's INITRAMFS_FSTYPES that can be set differently.
(From OE-Core rev: 141d02400696020e83df3edcf13021fde139d261)
Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the case where multiple packages provide the same file, we show an error.
Otherwise, python will generate a different build depending on which provider
appears first in the dictionary. On my system this order changes every time
I run bitbake causing intermittent build differences.
Add a sorted() to fix the determinism issue too.
(From OE-Core rev: 61c41369003444bfbf1c45e7cfd2752a4b7bc22f)
Signed-off-by: Jonathan Marler <johnnymarler@hp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It should have been removed in 3db9d865 (classes/package_rpm.bbclass:
Enhance diagnostic messages) when it was split in two new notes.
Also change the casing of two other notes to align them with the other
notes.
(From OE-Core rev: b40e245795cd19c7d36df096fa1f30c75490ce46)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
externalsrc do_configure task watches oe-devtool-tree-sha1 file and its
checksum. That file basically contains the result of `git add -A
${EXTERNALSRC} && git write-tree` which is the hash of temporary
"commit" of the non committed changes. This file is stored in the .git
directory of the git repo of the externalsrc recipe. do_configure then
depends on the checksum of oe-devtool-tree-sha1 file.
If 2+ recipes with different externalsrc paths but same git repo (e.g.
one recipe at /some/path and the other at /some/path/subdir) are parsed,
this oe-devtool-tree-sha1 will be overwritten by those recipes at
parsing time since .git is shared between those recipes.
If there is one non committed git change in /some/path but not in
/some/path/subdir, the oe-devtool-tree-sha1 of both recipes will be
different.
What will happen is that recipe1 will watch over the
oe-devtool-tree-sha1 with a specific checksum, fill in file-checksums
for do_configure correctly, then recipe2 will watch over the identically
named file with different content also fill in the file-checksums
varflag. When do_configure of recipe1 will be evaluated for
re-execution, oe-devtool-tree-sha1 will be of the value of what is
watched over by recipe2, thus triggering a rebuild of recipe1.
This behavior is not always reproducible which I'm guessing is due to a
small window between recipe1 putting info into oe-devtool-tree-sha1 and
calculating the checksum of that file and recipe2 putting its content
into oe-devtool-tree-sha1.
By appending the name of the recipe to oe-devtool-tree-sha1, we make
sure that a recipe won't have its oe-devtool-tree-sha1 overwritten by
another recipe sharing the same externalsrc git repo.
(From OE-Core rev: 1b727dd7295a7a7fe17800f8038242efbf7fe2b7)
Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
