u-boot.bin with dtb & signature should be placed in ${B} so that
it can be deployed by u-boot as expected. Otherwise, the version
without signature is installed.
(From OE-Core rev: bfc8c964a9760a2c4a1d1902918908a1e7361c17)
Signed-off-by: Jun Nie <jun.nie@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when INITRAMFS_IMAGE_BUNDLE and INITRAMFS_IMAGE are set, wic should
look for kernel with initramfs image bundled.
Include required variable MACHINE, INITRAMFS_IMAGE_BUNDLE,
INITRAMFS_IMAGE, INITRAMFS_LINK_NAME and KERNEL_IMAGETYPE in WICVARS.
No longer require default value for variable kernel as KERNEL_IMAGETYPE
is not optional variable and included in WICVARS.
image_types_wic to inherit kernel-artifact-names to obtain default
INITRAMFS_LINK_NAME when INITRAMFS_IMAGE_BUNDLE are set.
update wic.Wic2.test_image_env test case to filter optional
variable INITRAMFS_LINK_NAME, INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE.
(From OE-Core rev: bac984fbb2d5ad5d13ba3275c8a3e878d8753c58)
Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distributions for various reasons (like for example mounting a
tmpfs over /var at runtime) can't use /var/lib to store the opkg
metadata, so a different path is required to have a functioning
package manager.
${localstatedir} can't be modified to something other than the
hardcoded value in bitbake.conf because other recipes depending on it
will fail to install.
So the only recourse, which is also the least invasive, is to allow
distros to overwrite the OPKGLIBDIR variable just like they are also
allowed to overwrite OPKGBUILDCMD.
(From OE-Core rev: 81eae383c287ad2e74321345c5eba862d5704cc4)
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As glibc will be scanned for CVEs, we don't need to scan glibc-locale,
glibc-mtrace, and glibc-scripts which are all separate recipes for technical
reasons.
Exclude the recipes by setting CVE_PRODUCT in the recipe, instead of using the
global whitelist.
(From OE-Core rev: 1f9a963b9ff7ebe052ba54b9fcbdf7d09478dd17)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CVE-2014-2524 is a readline CVE that was fixed in 6.3patch3 onwards, but the
tooling wasn't able to detect this version. As we now ship readline 8 we don't
need to manually whitelist it, and if we did then the whitelisting should be in
the readline recipe.
(From OE-Core rev: 07bb8b25e172aa5c8ae96b6e8eb4ac901b835219)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure that we don't create an image test data symlink named
".testdata.json" when IMAGE_LINK_NAME is empty.
(From OE-Core rev: 97e1af51814c63963dc6eee003e0cf0e4dead024)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure that we don't create a symlink named ".manifest" if IMAGE_LINK_NAME
is empty.
(From OE-Core rev: 267697f5e1c931e39fd81dd1b14691e364be64f3)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The options in ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} are already passed
via ${CC}/${CXX} and there is no reason to pass them a second time. Thus
we can remove MESON_TOOLCHAIN_ARGS. And when it is removed, the other
MESON_*_ARGS variables revert to the standard CFLAGS, CXXFLAGS and
LDFLAGS, so just use them directly instead.
Apart from the obvious improvement with not passing a lot of options
twice, this also solves a problem where -pie would be passed on the
command line in a way that it would prevent building any dynamic
libraries using meson if using a toolchain that is not built with
--enable-default-pie and if security_flags.inc is used.
(From OE-Core rev: 300f4ac59d4b96fc25a40565b22441b51ab08ede)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bluez4 was removed from meta-oe 2 years ago.
Simplfy the setup of the two level bluetooth and bluez4/bluez5
distro features by removing the bluez4/bluez5 distro features.
This also removes the no longer required bluetooth class.
(From OE-Core rev: dcf889e93401f7c4de0055d53271eacc3882eccc)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the recent changes in bitbake to runqueue, we need to recheck sstate validity,
particularly in multiconfig builds where tasks have the same checksum.
Avoid printing summary messages in this case. Also avoid multiple events to toaster
which may not be expecting that at later points in the code.
(From OE-Core rev: 227125b96ad6fb0cf6e259e787d83415993db847)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package uses PKG_ variables to map package names to version specific
variants, on target postinstall functionality will be broken.
i.e. something like the following casuses rootfs assembly errors:
d.setVar('pkg_postinst_ontarget_linux-source', 'cd /usr/src/; ln -sf %s linux-source' % source_pkg)
This breakage is due to the fact that the original package name (as specified by
the PACKAGES variable) is logged by the intercept scripts, but the mapped /
specific version is actually installed to the rootfs (and hence logged by the
package manager).
When the runtime listing of on-target scripts is performed, we get a package
manager error due to a missing package, since it checks the generic version
logged by the intercept scripts.
We can fix this by ensuring that the PKG_ variable mapped package name
is logged by the intercept phase, and hence the package manager can locate
and execute the on target postinst script.
This variable check is consistent with other places in the code, and has
no impact if PKG_ variables are not used.
(From OE-Core rev: a6af0886d1be584974086c0ddb4a5bc566eb7984)
Signed-off-by: Bruce Ashfield <bruce.ashfield@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Put libxml2-native dependency in this class and remove
it from recipes inheriting this class.
In fact, if a recipe inherits this class and does not have
libxml2-native, the xmlcatalog_sstate_postinst would fail.
(From OE-Core rev: 5a72c6d5cc1c9896c7425ac20eaf82d3d489e5c7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
create_symlinks does not create any links if IMAGE_LINK_NAME is empty.
Unfortunately, setup_debugfs_variables unconditionally appends '-dbg' which
results in a previously-empty IMAGE_LINK_NAME containing just '-dbg'. Let's
check that it's not empty before appending.
(From OE-Core rev: e529c45f29bd9a1de21f31fef7acb23eb6e8ebdd)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For various technical reasons, native and cross builds have a prefix that
includes the full path to the sysroot. As these are stripped away before the
files are used in the sysroot, we should also filter them out of the
buildhistory report. This both removes noise when sharing a buildhistory
repository between different build directories, and improves the accuracy of the
reports.
(From OE-Core rev: 8bf53fbb62749b5d77c246fab6e1246b93f8c50f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As the sysroot isn't ran inside pseudo the ownership is whoever is running the
builds. In a setup where multiple builders all contribute to a shared
buildhistory writing the ownership data isn't useful, so just replace it with "-
-".
(From OE-Core rev: fadb7ae78876a7cf25c48481ff4ed3131e53415f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current go class includes ptest logic by default
and will make the recipe which inherits go class
to support ptest automatically though maybe the
recipe which inherits go class doesn't plan to
support the ptest.
So separate the ptest logic to another specified
class go-ptest to make the recipe which needs to
inherit go class more flexible with regards to
ptest support.
(From OE-Core rev: 099a2a212fed61a24643da63c74c09cef3ba4030)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that cve-update-db added CPE information to NVD database. We can
check for unpatched versions with operators '<', '<=', '>', and '>='.
(From OE-Core rev: bc0195be1b15bcffe60127bc5e8b7011a853c2ed)
Signed-off-by: Pierre Le Magourou <pierre.lemagourou@softbankrobotics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the NVD url is not accessible, print a warning on top of the CVE
report, and continue. The database will not be fully updated, but
cve_check can still run on the previous database.
(From OE-Core rev: 0325dd72714f0b447558084f481b77f0ec850eed)
Signed-off-by: Pierre Le Magourou <pierre.lemagourou@softbankrobotics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When enabling multilib and building lib32-IMAGE which
uses grub-efi, the build fails with the following error.
install: cannot stat '/PROJ_DIR/build/tmp-glibc/deploy/images/intel-x86-64/grub-efi-bootia32.efi': No such file or directory
The grub-efi is in NON_MULTILIB_SCRIPTS. That means we
will use 64bit grub-efi for lib32-IMAGE.
So take into consideration of multilib to fix this problem.
(From OE-Core rev: 3c7b6dfecd22eae369bba54437cdff91fa8542df)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've a nice function to clean up absolute build paths for display, so use it.
(From OE-Core rev: c2f2ea87592d14e7020eff19c11aae2fb644358a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The blocks were intended with 3 spaces instead of 4.
(From OE-Core rev: 98fbf61287971319547cc462b7c81f54950df619)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check the existence of systemd before using systemctl to preset units.
This is because even if 'systemd' is in DISTRO_FEATURES, it's possible
that systemd is not even installed. e.g. container-test-image in
meta-selftest layer.
As systemd DEPENDS on systemd-systemctl-native, the existence of systemd
also ensures the existence of systemd-systemctl-native.
This would fix the following test case when using systemd as the init
manager.
containerimage.ContainerImageTests.test_expected_files
Also remove the IMAGE_EXTRADEPENDS setting, as nothing references this
variable.
(From OE-Core rev: c9854a4ab6af9e60b1a588a87b9a062624af6fae)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This switches the code to build pkgdata specific to the current recipe
which means that its filtered to the recipes dependencies and can perform
better as we can drop the lockfile.
It uses a similar method to the staging code to do this, using BB_TASKDEPDATA
to construct a list of packagedata task output which this recipe should "see".
The original pkgdata store is left unaltered so existing code works.
The lock file was there to prevent files disappearing as they were read or as
directories were listed. Since we have a copy of the data and only access output
from completed tasks (as per their manifests), we can remove the lock.
The lock was causing starvation issues on systems with parallelism.
There was also a potential determinism problem as the current code could "see"
data from recipes which it doesn't depend upon.
[YOCTO #13412]
(From OE-Core rev: 1951132576bfb95675b4879287f8b3b7c47524fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
multiconfig dependencies no longer appear in BB_TASKDEPDATA so we can drop
this code.
(From OE-Core rev: 288b04c8a31fcf257219a57e23663b74178c75f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes to the sysroot are just as interesting during development, so write the
file listing for the sysroot to buildhistory too.
(From OE-Core rev: b3ac82a27ab70ed6996fe3087a578ac637820329)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
populate_packages relies on ``mkdir`` to both create a directory and set
its permissions. However, ``mkdir`` honors the ``umask`` value.
Therefore, some bits may be lost in the operation. In our case, the
setgid bit on the directories were lost.
This commit fixes this by having a distinct call to create the directory
and to set the permissions.
(From OE-Core rev: 0f82b53a650e76e0129fae6ce7581a41d042315b)
Signed-off-by: Jean-Tiare Le Bigot <jean-tiare.le-bigot@easymile.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake core-image-minimal
update-alternatives: libtool has multiple providers with the same priority,
please check
/path/to/rootfs/usr/lib/opkg/alternatives/libtool for details
Both libtool and lib32-libtool have the same priority (as they're the same
recipe), so update-alternatives won't deterministically pick a provider. This
means you could end up with an image using a 32-bit pkgconfig and 64-bit
libtool, for example.
Make extended recipes reduce priority by 1 (or 2, 3 ... when there are multiple
variants in MULTILIB_VARIANTS) to fix the problem.
[YOCTO #13418]
(From OE-Core rev: a2f53255ed7fb3657c470cd6a4452d883edd11cc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes like postfix run command newaliases in postinst, but newaliases is
installed as newaliases.postfix, it needs run update-alternatives to update it
to newaliases, so there was an error when installed postinst on target.
Fixed:
$ opkg install postfix
Configuring postfix.
///var/lib/opkg/info/postfix.postinst: line 4: newaliases: command not found
Run update-alternatives firstly will fix the problem.
(From OE-Core rev: 52c36dd869c605c0065c17f9ed502a319ce3dd84)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_VERSION gets expanded at runtime to contain the real kernel
version. There is code to ensure the signatures are determinisic but
the multilib expansion code breaks this.
Exclude the variable from the datastore used for expansion to avoid this.
(From OE-Core rev: c068f907fee16477f59b6e5b168208aa4f677544)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building lttng-modules for a "lib32" multilib, then changing to a "lib64"
multilib with "lib32" removed doesn't rebuild lttng-modules.
This is due to the multilib pieces in RPROVIDES being added after RecipeParsed
which is after the signatures are generated.
Changing this to RecipeTaskPreProcess allows the multilib components to be
accounted for correctly in the task hashes.
This addresses failures on the autobuilder seen in lib64-core-image-sato-sdk
builds where lttng-modules was being reused from qemux86 world build's lib32
version.
(From OE-Core rev: a8dc13d4e4e34b061be5c2dd71f26cc0ad92a72e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The intercept is called update_icon_cache which is vague: rename to
update_gtk_icon_cache to make it clearer what it is for, and add a comment
explaining what class caused it to be used.
(From OE-Core rev: 3158adbe684890adc56af11e19af872e90e09d41)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of generating a series of indexes via range(len(list)), just iterate the
list.
(From OE-Core rev: 27eb839ee651c2d584db42d23bcf5dd764eb33f1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default GOCACHE is set to $HOME/.cache.
Fixes:
ERROR: go-cross-dbfp4-1.12.1-r0 do_compile: Function failed: do_compile (log file is located at /workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120)
ERROR: Logfile of failure stored in: /workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120
Log data follows:
| DEBUG: Executing shell function do_compile
| Building Go cmd/dist using /workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/recipe-sysroot-native/usr/lib/go.
| failed to initialize build cache at /home/pokyuser/.cache/go-build: mkdir /home/pokyuser/.cache: permission denied
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120)
ERROR: Task (/workdir/repo/poky/meta/recipes-devtools/go/go-cross_1.12.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 23 tasks of which 16 didn't need to be rerun and 1 failed.
(From OE-Core rev: 9a6d208b9979035bbfc1def80fb6558db4bddb12)
Signed-off-by: Ricardo Ribalda Delgado <ricardo@ribalda.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* update-rc.d has added support of enable/disable options, which are
expected to keep the previous configuration even after upgrade the packages.
With support for these options, it will only create start/stop link
when there are none, or it will keep the previous configuration.
Our preinst uses "-f remove" to remove any links under the /etc/rcrunlevel.d
which is conflicting behavior with disable/enable options, so remove it.
For example, if a user disabled one service before upgrade,
then after upgrade the service could be started. This happens because during preinst,
all links have been deleted, then postinst may create the link to start service.
With this change, we remove preinst and therefore keep the previous links
so that after upgrade, if a link existed for the package, then the postinst
will not create new start/stop links.
* remove '-f' for postinst. Previously, the keepalived recipe used 'remove'
during postinst, so we needed the -f, but now the keepalived recipe has fixed
this problem, so it's safe to remove '-f'.
[Yocto #12955]
(From OE-Core rev: 7981d5261429cfb06030280460086f9af91876d9)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The comment is misleading and there was confusion in a bug report. In the native
case STAGING_DATADIR would be equal to the native value so there isn't any issue
but tweak the comment.
[YOCTO #12761]
(From OE-Core rev: 0fdf76305a3cb543c23d6122c523ce5c2af04a0c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the NVD json CVE feed, affected versions can be strictly matched to a
version, but they can also be matched with the operator '<='.
Add a new condition in the sqlite query to match affected versions that
are defined with the operator '<='. Then use LooseVersion to discard all
versions that are not relevant.
(From OE-Core rev: 3bf63bc60848d91e90c23f6d854d22b78832aa2d)
Signed-off-by: Pierre Le Magourou <pierre.lemagourou@softbankrobotics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* just to make sure it's expaned by bitbake before it gets
executed in shell
* e.g. with cmake.bbclass and cmake recipe (any recipe without
PACKAGECONFIG options have this issue) it looks like this:
bitbake -e cmake | grep EXTRA_OECMAKE=
EXTRA_OECMAKE=" -DCMAKE_DOC_DIR=share/doc/cmake-3.14
-DCMAKE_USE_SYSTEM_LIBRARIES=1 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 -DKWSYS_CHAR_IS_SIGNED=1
-DBUILD_CursesDialog=0 -DKWSYS_LFS_WORKS=1
\${PACKAGECONFIG_CONFARGS}"
(From OE-Core rev: 745b63f4e11a6536cabd97013973562631a0e080)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're going to clean buildpaths from installed .la files then we should do it
globally, not in a class that only six recipes in oe-core use.
(From OE-Core rev: bd4e2cd3f70243f52215f8c92bcd7eb088a9b9f6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of reporting large chunks of the work directory and not the package
name:
"File /work/corei7-64-poky-linux/libidn2/2.2.0-r0/packages-split/libidn2-dev/usr/lib/pkgconfig/libidn2.pc in package contained reference to tmpdir"
We can clean up the paths and be more useful:
"File /usr/lib/pkgconfig/libidn2.pc in package libidn2-dev contains reference to TMPDIR"
(From OE-Core rev: 156329247b40e9ee97e6249468ac3b9af4dffb68)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* especially when pushing longer history to slow remote git server or when
it timeouts during the push, it's useful to see where the time was actually
spent
(From OE-Core rev: 96f1225d47985d94d9ed91eb5e7affdd70671c79)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
AArch64 images are not self-decompressing, thus usually much larger.
Boot times can be reduced by compressing them in FIT and uImages.
(From OE-Core rev: a725d188b5d6b5d3c5cf21cc2f3070a0fe711e18)
Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
