Don't hardcode the targets used in do_compile and do_install, instead build
"all" and "install" by default but respect OECMAKE_TARGET_COMPILE and
OECMAKE_TARGET_INSTALL variables.
(From OE-Core rev: 806765ec466597d38231d4be303cb48c26e21466)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In line with the other gettext cleanups, drop the nativesdk-gettext dependency
as it isn't needed (similarly to the previous target gettext dependencies).
This then means we can drop DEPENDS_GETTEXT as there are no other users.
(From OE-Core rev: c43c054cb778e0c5c082996cd6e6c45f5fc9e1bf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
possible bashism in run.do_install line 163 (should be 'b = a'):
if [ "kernel" == "kernel" ]; then
Fixes "[: kernel: unexpected operator" when not using bash by default,
which causes the default kernel image link to not be created.
(From OE-Core rev: 9d82fffd24742a5eb40bcb9b9ecea01a42be0be6)
Signed-off-by: Ricardo Salveti <ricardo@opensourcefoundries.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We usually forcibly delete any gettext macros we come across to ensure that the
latest versions we ship are used, but if we're building gettext then it's a bad
idea to delete the gettext macros.
Historically this hasn't been a problem as the top-level gettext configure
doesn't use AM_GNU_GETTEXT so the deletion was never done, but this may change.
(From OE-Core rev: f16657df977e54210774812d4e616403c76eb060)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using TARGET_CC_ARCH is inconsistent with CC, which uses HOST_CC_ARCH, and the
rest of meson.bbclass, which uses HOST_PREFIX, HOST_OS, etc.
(From OE-Core rev: 8a61e0c0c53275ebc623296f46676d920b11eb3b)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make 'wic' image creation tool/command available in eSDK
environment. This would allow eSDK users to manipulate
images within eSDK environment.
[YOCTO #12177]
(From OE-Core rev: 90df6758a9f8753c646b129aa912e3849bf4c987)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using host gpg has been problematic, and particularly this removes
the need to serialize package creation, as long as --auto-expand-secmem
is passed to gpg-agent, and gnupg >= 2.2.4 is in use
(https://dev.gnupg.org/T3530).
Sadly, gpg-agent itself is single-threaded, so in the longer run
we might want to seek alternatives:
https://lwn.net/Articles/742542/
(a smaller issue is that rpm itself runs the gpg fronted in a serial
fashion, which slows down the build in cases of recipes with very
large amount of packages, e.g. glibc-locale)
Note that sstate signing and verification continues to use host
gpg, as depending on native gpg would create circular dependencies.
[YOCTO #12022]
(From OE-Core rev: 08fef6198122fe79d4c1213f9a64b862162ed6cd)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PACKAGE_INSTALL is only used by image recipe, the previous code had
handled it in "if bb.data.inherits_class('image', d)", handle it again
doesn't make any sense (there is no PACKAGE_INSTALL for non-image
recipe), so remove it.
(From OE-Core rev: 6b25c76da51180da7c97308d5f8f5558c68cdca3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It only substituted staging_target for target recipe which didn't work
for multilib, for example, postinst-useradd-lib32-polkit:
* No multilib:
PATH=/path/to/tmp-glibc/work/core2-64-wrs-linux/polkit/0.113-r0/recipe-sysroot-native/bin
staging_target=/path/to/tmp-glibc/work/core2-64-wrs-linux/polkit/0.113-r0/recipe-sysroot
The PATH would be substituted to:
FIXMESTAGINGDIRTARGET-native/bin
Not the funny "-native/bin", this works well.
* When multilib:
PATH=/path/to/tmp-glibc/work/core2-32-wrsmllib32-linux/lib32-polkit/0.113-r0/recipe-sysroot-native/bin
staging_target=/path/to/tmp-glibc/work/core2-32-wrsmllib32-linux/lib32-polkit/0.113-r0/lib32-recipe-sysroot
Now staging_target endswith "/lib32-recipe-sysroot", so it can't
replace '/recipe-sysroot-native' in PATH , so PATH can't be fixed, and
there would be build errors when building multilib + rm_work, for
example:
chown: invalid user: ‘polkitd:root’
Substitute staging_host for target recipe can fix the problem, now all
of native, cross and target need substitute staging_host, so we can
simply the code a little.
(From OE-Core rev: 087510795331fa21ff52f103269087c06b1660fa)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we migrated rpm v5 -> v4, we lost the ability to drop "per file"
dependencies from the rpm backend for things like "/bin/bash" and
"/usr/bin/env" which meant the sdks were becomming 'bloated'.
This restores the functionality using a dummy package, similarly to
the way the buildtools perl issue was addressed. It also removes
the non-functional old code so as not to confuse people in future.
I ran into this problem trying to filter dependencies to only rpms
a build directly depends upon and it turns out we have some determinism issues
in this area so this is something key to fix.
(From OE-Core rev: 9d490dc01dcedb216129b22cbe17a6c99efc4f5c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can end up with / in dependency names from file dependencies but the
deb format doesn't allow this. Filter the names to allow such dependencies
to work. Names have to start with an alphanumeric digit so also handle this.
This allows for future handling of "per file" dependencies similarly to
the rpm backend, bring parity to the functionality of the backends.
(From OE-Core rev: fc08972688d784f561c8be88d3100d6baaf22070)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DEPENDS_GETTEXT defaults to gettext-native, so there's no need to set it again
in these classes.
(From OE-Core rev: 5e4b1915e7a5a94d410c5292b5ed2f447c82b18a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various recipes that inherit cmake contain FILES_${PN}-dev magic to add the
generated package files to their -dev packages. Since this is a standard
feature of cmake, we might as well teach cmake.bbclass to do this itself so
those recipes can be simpler.
(From OE-Core rev: d91dc4666683a96e9d03cbbd21b8a546f9069c93)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It had been dropped by:
commit 65581c68d130fa74d703f6c3c92560e053857ac7
Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Date: Mon Feb 13 16:44:48 2017 +0200
rootfs_rpm.bbclass: migrate image creation to dnf
(From OE-Core rev: 38df1653da65a8a4e5f84b369b699307d5b4fc4f)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous code:
os.rename(sdkbasepath, temp_sdkbasepath)
try:
foo
finally:
os.rename(temp_sdkbasepath, sdkbasepath)
always renamed the path, it made the debug harder when error happened.
drop the "try: finally" makes the debug easier.
(From OE-Core rev: 32126512349d65f0dbc31196c4ec6e1a1147cf5e)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise it would generate lines like the following when multilib:
INHERIT += "own-mirrors"SSTATE_MIRRORS += " \n file://.* file:///path/to/../share/sstate-cache/PATH"
(From OE-Core rev: 65b2a0e1ba7e176f3e405ed8968665660fc414d3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is very useful for debugging. The similar to testsdk.bbclass.
(From OE-Core rev: de30b61b87047f61de4629f8e5bd87598de7fd0c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To make it easier to debug problems with renaming caused by debian.bbclass,
explicitly log when packages are renamed.
(From OE-Core rev: 2c27df943035b4df7c5d0be1ab8d0f4f3a31f4d2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although the meson crossfile should take care of setting the right cross
environment for a target build, meson slurps any set CFLAGS, CXXFLAGS,
LDFLAGS, and CPPFLAGS from the environment and injects them into the
build (see mesonbuild/environment.py:get_args_from_envvars for details).
This means that we are seeing native CFLAGS, CXXFLAGS, LDFLAGS, and
CPPFLAGS in the target build, which is wrong and causes build failures
when target and native have libraries in common (the linker gets
confused and bails).
That said, we *do* need to set certain vars for all builds so that meson
can find the right build tools. Without this, meson will fail during its
sanity checking step because it will determine the build tools to be
unrunnable since they output target instead of native artifacts.
The solution to all of this is to set CC, CXX, LD, and AR globally to
the native tools while setting the other native vars *only* for the
native build. For target builds, these vars will get overridden by the
cross file as we expect.
(From OE-Core rev: de7ae028c65a978969b2e06fdc1a2d08bc141a5b)
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gnomebase.bbclass hardcodes the autotools inherit, so make it
configurable and allow meson to be specified instead.
(From OE-Core rev: 32c2faf394ba7bf75a7273fb9f5e58cc4ee3f3ad)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
[RP: patches tweaked to only need the one class]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve binary reproducibility of RPM packages.
Ensure timestamps in RPM packages are not later than the value
of SOURCE_DATE_EPOCH. If SOURCE_DATE_EPOCH is not set,
timestamps are not clamped.
(From OE-Core rev: 225a7156d1fb2fbffadf38e4f4e491f053358082)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If no ptest packages are installed in the image, the test does nothing;
if ptest packages are installed in the image, then they should be
run without user having to enable that manually.
(From OE-Core rev: f57feab2727dca916744deb64825f3beaf07961d)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently we can't access this function from lib/oe as its a class function.
Move it to allow such access.
(From OE-Core rev: b241a666f2867ffa425f6d43763d7c3c17941dcf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "ls -s sparse_file"'s result is 0, use stat to replace of it.
(From OE-Core rev: 1b2ec7a04069a0af2d4164c24109a5fa2fd0b1f6)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using kernel-fitimage class with microblaze, the image type has to be
linux.bin not zImage. This patch fixes the bad image type replacement
for microblaze
(From OE-Core rev: 4e0903e2f71658d595ccb1fa9dddf0f73b373f7e)
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add aarch64 32-bits (ILP32) ELF header into dictionary and
check binaries for 32-bitness.
(From OE-Core rev: 4b4a1295b8476d2820935eb5661b2d24a49b29b2)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 32bit core-image-minimal-initramfs should be built when build lib32-iso, e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
IMAGE_FSTYPES += "iso"
$ bitbake lib32-core-image-minimal
Exception: FileExistsError: [Errno 17] File exists: '/path/to/tmp/sysroots-components/core2-64/qemuwrapper-cross/usr/bin/crossscripts/qemuwrapper' -> '/path/to/tmp/work/qemux86_64-pokymllib32-linux/lib32-core-image-minimal/1.0-r0/lib32-recipe-sysroot/usr/bin/crossscripts/qemuwrapper'
This was because:
lib32-core-image-minimal -> core-image-minimal-initramfs
core-image-minimal-initramfs -> qemuwrapper-cross
lib32-core-image-minimal -> lib32-qemuwrapper-cross
So we got the error, build lib32-core-image-minimal-initramfs can fix the problem.
(From OE-Core rev: eee3ec805cf150f1c701427a2d182a537a67e8f5)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.
This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.
To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".
Testing:
1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"`
to local.conf so that linux-yocto-tiny may build alongside
the main kernel (linux-yocto).
2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-linux"`
to local.conf to install both kernel flavors in core-image-base.
6. `bitbake core-image-base` to build an image.
7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" (linux-yocto recipe) selected to boot via symlink.
Discussion threads:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130
[YOCTO #11363]
(From OE-Core rev: 6c8c899849d101fd1b86aad0b8eed05c7c785924)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Gratian Crisan <gratian.crisan@ni.com>
Coauthored-by: Haris Okanovic <haris.okanovic@ni.com>
Coauthored-by: Josh Hernstrom <josh.hernstrom@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On some build hosts distros (e.g. Fedora 26) waf tries to be
smart about libdir detection and defaults to [EXEC_PREFIX/lib64].
This obviously is not what we want for 32-bit targets and usually
fails in the do_package phase:
WARNING: gstreamer1.0-plugins-imx-0.13.0-r0 do_package: QA Issue: gstreamer1.0-plugins-imx: Files/directories were installed but not shipped in any package:
/usr/lib64/libgstimxcommon.so.0
...
Depending on version, waf knows prefix or prefix, bindir and
libdir as default options. Explicitly pass the right set of
arguments.
(From OE-Core rev: 923f91d8d8606141ce218927bc943f4f4f34bcdd)
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the introduction of support for multiple kernel image types in
849b67b2e4820564b5e5c9bd4bb293c44351c5f3, do_sizecheck was changed to only
warn if any kernel was bigger than ${KERNEL_IMAGE_MAXSIZE}. (Well, it tried
to warn - it turns out that there's no function called "warn", it should be
"bbwarn".) The previous behaviour had been to fail the build if the single
kernel image did not fit.
It seems possible that people might be generating both compressed and
uncompressed kernels and only really care whether the compressed one fits.
This means that we shouldn't just always fail if any of the images are too
large. So, let's warn (correctly this time) on every image that is too
large, but only ultimately fail if no image will fit. The build will also
fail if ${KERNEL_IMAGETYPES} is empty, but I hope that no-one needs to do
that.
While we're here correct a typo in the KERNEL_IMAGE_MAXSIZE validity check.
(From OE-Core rev: 59f1ee104d1a6c04b0690b7c8ce481449da174d6)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As warned in a proir commit, it's time to remove the elf image type,
it is not long used anywhere (that I am aware of) and the mkelfimage
tool has been removed from the upstream coreboot code base.
(From OE-Core rev: 2781e8d608c0fd2108aeab294f982e9249793852)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'wic' image may use files which has been deployed (e.g in
do_deploy) for some partitions that may need to be copied in a
specific partition or filesystem (e.g a bootloader).
When using 'bitbake <image> -c image_wic', from a clean build, the
contents of do_deploy must also be available so we need to ensure all
do_deploy of the image dependencies has been complete.
Reported-by: Fabio Berton <fabio.berton@ossystems.com.br>
(From OE-Core rev: f387c28640cbb209b8a8ed5734b21c754d9f7663)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a race with rm_work when tasks run deltask do_build since
do_rm_work becomes a floating task. Handle this by injecting
the populate_sysroot/lic dependencies manually if the tasks returned
are empty. This depends on a change to fix bb.build.preceedtask() in
bitbake too.
[YOCTO #12365]
(From OE-Core rev: 0f537d985b7b17af508a511fca8a4ec4b5804580)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We actually caught the ext4 size issue in the wild with the debug
output in the oe_mkext234fs() code, but it did not help. What that
showed was that the get_rootfs_size was returning a default size of
8192, where as the actual rootfs was more like 10572, thus too large
to fit in the created sparse file.
This additional temporary debug code should help us determine where
the failure might be.
More debug for
[YOCTO #12304]
(From OE-Core rev: 978472c58629d1448399207873bbead96b27102e)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will speed up file creation and still allow the btrfs tools to
create a full btrfs image. This is similar to what we do for ext234
FS types.
(From OE-Core rev: de2f2fc9e8e6d874a11e69adc2f438975a5c1359)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The pypi.bbclass has usefullness in many meta layers, not
just meta-python. Add it to oe-core for the benefit of
everyone.
Documentation strings for PYPI_PACKAGE, PYPI_PACKAGE_EXT and
PYPI_SRC_URI added to meta/conf/documentation.conf
(From OE-Core rev: c350812523017f113f63e0b863fd526b4d6331b9)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
