[YOCTO #10389]
Use a glob (*) to match all mips (not previously matched). This will ensure
that the linuxloader is properly returned for mips, mipsel, mips64,
mips64el and their n32 variants.
See: https://sourceware.org/glibc/wiki/ABIList#mips for the official list
of loaders.
(From OE-Core rev: b90d68fda3d14b4d19b7ffcb5b80ed28563a616d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS Release 6 ISA
(From OE-Core rev: fcb67508be00cdd22181d6c9e4c3d29dfa578b45)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS Release 6 ISA. The loader is located at a
new place for multiarch.
For more details, check https://wiki.debian.org/Multiarch
and https://sourceware.org/glibc/wiki/ABIList#mips
(From OE-Core rev: 27537d146f3f143b06819102c348c8914287ec8e)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS Release 6 ISA
(From OE-Core rev: 8e098ddb656d39c56427ad45e0fa429b8f0153f5)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS Release 6 ISA
(From OE-Core rev: aecb57f2fd65a1bfbc2e9a23fba4984d44055c4c)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for MIPS release 6 of the ISA
(From OE-Core rev: 6613ee0155de1e0afd30cd8d8290eda3f7486337)
Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If attempting to patch a git repo without a proper git config setup,
an error will occur saying user.name/user.email are needed by git
am/apply. After some code was removed from kernel-yocto, it was
simple enough to reproduce this error by creating a kernel patch and
using a container to build.
This patch abstracts out functionality that existed in buildhistory
for use in other classes. It also adds a call to this functionality
to the kernel-yocto class.
Fixes [YOCTO #10346]
introduced in OE-core revision
0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3
(From OE-Core rev: 25b43cb05c645e43f96bc18906441b8fdc272228)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* otherwise there is a lot of warnings about missing close on file descriptor
(From OE-Core rev: 629ff6eb58ddad2d533cbcc8b1a4594d3c8fd441)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The checkstatus function fires an event to notify bitbake UI about
the progress of the task, this function is implemented using ThreadPool
and is causing event lose when multiple threads tries to fire an event
(writes over socket/fd).
[YOCTO #10330]
(From OE-Core rev: 6e0bb9d141438c0051c32b0d3a247915b71ccb82)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5f8eb6726a492d259bfe25b0bbce2333c9505504)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: de45a7e302fe5a2a08baf26c91e2c788d7285263)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8443b6f3f25181f5ac49bc25a1387cd05b814376)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5369bb7fa6238cc85f0b5263519974c1a2d9eea8)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 086240468265dc15c5b4cdb2594d5aa7c3114dda)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 20e669f56489b2c8a9bc6a0e6f3eac81ef35445a)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 33611b69c221cf875eba1c7cb599c256825ae470)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 21969c3d1397e0a11a8cb9dad8ce3469ee655f57)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 11a2f932073635f9680470cd69216cecf7ed0c37)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8e956d66087b9c41591b8e4e817ed6c9e42f5981)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8e9255763674703ea16651da64fe794e5359f16e)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: a77b4e543407eee133fbd38ac9b69e90bea541e0)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: f7c82acbac583c7838550175796a7aa697a5c7e0)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: c61d7a01c89f0d25d069191cc47d6768bee2ce48)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: cca772ecf0adafbd767974add27ada125aae5269)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 48c4faa1d7117732974e51428f7ed2f62ad7e7bf)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: f0561ba205723fd7f05c28d501c2c517034b326c)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 01e3ac73860a24710852383a15bb5d01db13de57)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 9635af9785509a39c1ac2509740d46276119a0ca)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, native.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
(From OE-Core rev: 2d0a1b029447842a6f97f72ae636c9020c4206a9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, cross.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
(From OE-Core rev: 5b61324fa76b27bb6ce13e78b17e767eed2f8f57)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When changing multilibs, allarch recipes should not be rebuilding. This
adds enough variable exclusions to make this work properly. Future
regressions will be prevented with new testing.
(From OE-Core rev: ce1e7fcc60276040477c1d5e3129e029bb9f204b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
package_write_rpm references the MULTILIBS variable and the checksums
of nativesdk recipes were changing as a result of this.
We don't need/want MULTILIBS values for nativesdk so disable this.
(From OE-Core rev: 738ff6bc72533bbdeb58425b20b0bfbeff280a04)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This begins moving away from the deprecated subprocess calls in an
effort to eventually move to some more global abstraction using the run
convenience method provided in python 3.5.
[ YOCTO #9342 ]
(From OE-Core rev: 0d6b7276003f1afabc6de683f663540327d52bdc)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a space between the root and append parameter, similar to
syslinux.bbclass, in creating the final grub.cfg.
Without this, the final kernel boot parameters will concatenate into
strings like root=/dev/ram0console=ttyS0...
(From OE-Core rev: a3b271ec8e1b2758e1e619e76646d22fd5777ce3)
Signed-off-by: Raymond Tan <raymond.tan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Much as with -native recipes, as addressed in commit
b15730caf0, arch specific variables
like MIPSPKGSFX_ABI were affecting -nativesdk sstate checksums for
recipes like nativesdk-glibc-initial.
Disable multilib_header for nativesdk as we don't use multilibs in
this scenario.
[YOCTO #10320]
(From OE-Core rev: f1c7b4f16dc9a7e5155108641fed8b3d98c931f3)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The last line in the generated /etc/build doesn't end
with a newline anymore, restore it.
(From OE-Core rev: afbd3917061212558ccacda129eff516b735e5b1)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Arm is unusual in that we force it to "linux-gnueabi" and "linux" doesn't
build. This was causing problems for multilib configurations which were assuming
"linux" was the default compiler rather than linux-gnueabi.
This change does two things, ensures symlinks are generated for linux-gnueabi
and also adapts the libgcc code to account for the difference on arm.
It still needs to immediately expand/save TARGET_VENDOR but we defer
deciding what TARGET_OS should be until we know TARGET_ARCH (which the
multilib code may change).
[YOCTO #8642]
Note that sanity tests of a 32 bit arm multilib still break due to issues
with the kernel headers on a mixed bit system. This looks to be a general
headers issue for the platform though and a different type of bug.
(From OE-Core rev: bcddc3e7eff138add031bc9c9728be5a42fa62ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* in some cases we might set QB_DEFAULT_KERNEL to the real filename
instead of symlink and then this whole readlink work around actually
breaks the build, because os.readlink fails on normal files:
>>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86-master-20160927084848.bin')
'bzImage-linux-yocto-qemux86.bin'
>>> os.readlink('deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument: '/jenkins/mjansa/build-starfish-master-mcf/BUILD/deploy/images/qemux86/bzImage-linux-yocto-qemux86.bin'
(From OE-Core rev: a11d0d8641b7dfb05c78645cf21f2c04a08c4822)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function never worked because the SDK_OUTPUT and SDKPATH vars are
written bash-style in a python function. The only reason it never failed
a build is because the function bails out the start because of the flag
CHECK_SDK_SYSROOTS.
And I guess nobody tested with CHECK_SDK_SYSROOTS enabled until now.
(From OE-Core rev: 9f60dfdaaa74b90ebcfcdd9f3817c62a56243e92)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed parted-native dependency from do_image_wic as it's
already mentioned in IMAGE_DEPENDS_wic variable.
Thanks to Christopher Larson for pointing out to this.
(From OE-Core rev: 82353471ccaae59967df7f14de0b4065cbc8169a)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When changing SDKMACHINE, we may encounter an error forcing us to wipe the TMP folder.
Since only SDK_ARCH is captured in the PN of the crosssdk recipes, changes to SDK_OS
result in conflicts. Eventually we hit the error:
ERROR: ...: The recipe <...> is trying to install files into a shared area when those files already exist.
The build has stopped as continuing in this scenario WILL break things
This patchset addresses the problem by SDK_SYS as the recipe name suffix instead
of SDK_ARCH.
[YOCTO #9281]
(From OE-Core rev: d2eccccb70e809d482c493922f23aef4409cfd82)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a recipe uses more than one source which isn't a plain file (for
example, multiple git repos), then do_ar_original created the source
archives using the same filename and thus only archived one source.
The "name" parameter is used as file suffix to create unique names for
each source, leading to archives following this pattern:
deploy/${TARGET_SYS}/${PF}/${PF}[-<name>].tar.gz.
The ${PF} part is a bit redundant, which may or may not be
desirable. The patch is more localized this way (no need to modify
create_tarball()).
For example, meta-oic's iotivity_1.1.1.bb uses:
url_iotivity = "git://github.com/iotivity/iotivity.git"
branch_iotivity = "1.1-rel"
SRC_URI = "${url_iotivity};destsuffix=${S};branch=${branch_iotivity};protocol=http;"
url_tinycbor = "git://github.com/01org/tinycbor.git"
SRC_URI += "${url_tinycbor};name=tinycbor;destsuffix=${S}/extlibs/tinycbor/tinycbor;protocol=http"
url_hippomocks = "git://github.com/dascandy/hippomocks.git"
SRC_URI += "${url_hippomocks};name=hippomocks;destsuffix=${S}/extlibs/hippomocks-master;protocol=http"
SRC_URI += "file://hippomocks_mips_patch"
url_gtest = "http://pkgs.fedoraproject.org/repo/pkgs/gtest/gtest-1.7.0.zip/2d6ec8ccdf5c46b05ba54a9fd1d130d7/gtest-1.7.0.zip"
SRC_URI += "${url_gtest};name=gtest;subdir=${BP}/extlibs/gtest"
url_sqlite = "http://www.sqlite.org/2015/sqlite-amalgamation-3081101.zip"
SRC_URI += "${url_sqlite};name=sqlite3;subdir=${BP}/extlibs/sqlite3;unpack=false"
These now get archived in deploy/sources/*/iotivity-1.1.1-r2/ as:
gtest-1.7.0.zip iotivity-1.1.1-r2-recipe.tar.gz sqlite-amalgamation-3081101.zip
hippomocks_mips_patch iotivity-1.1.1-r2.tar.gz
iotivity-1.1.1-r2-hippomocks.tar.gz iotivity-1.1.1-r2-tinycbor.tar.gz
(From OE-Core rev: 5c63ffc706c0fff8cfb797a238f4f0e73ee2813d)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support for absolute paths in the "subdir" parameter was recently
added (bitbake rev: c3873346c6fa). The git fetcher has supported
absolute paths in "destsuffix" already before.
When the path is absolute as in destsuffix=${S}/foobar, the tmpdir
used by do_ar_original gets ignored, which breaks:
- source code archiving (tmpdir is empty)
- compilation due to race conditions (for example, ${S} getting
modified by do_ar_original while do_compile runs)
To solve this, these parameters get removed from URLs before
instantiating the fetcher for them.
This is done unconditionally also for relative paths, because these
paths are not useful when archiving the original source (upstream
source does not have them, they only get used by the recipe during
compilation).
(From OE-Core rev: c27c464e267db3f4b08cbd966412d19b0e756d28)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its useful to be able to query a list of variables to obtain the values
in each multilib context. This adds such a function which works even
if called in the non-default recipe context.
(From OE-Core rev: 4202a09dece07c0d3f654c2b1ae504a031b4ee90)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are architectures which support running in 32 and 64 bit
flavours however the simulation is provided in a specific QEMU
setting, requiring us to use a different binary. This patch allow this
to be done using, for example:
QEMU_TARGET_BINARY_ppce5500 = "qemu-ppc64abi32"
(From OE-Core rev: 9b6d414fd27932ed1325de54e8e867c75b340e3d)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes:
* During install all files were recompiled -> redurced build time
* For some recipes we found lot of links to build host image path
(From OE-Core rev: 3d1d287785c388bebba2ba1f2d8f843a5c6a2417)
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The feature to install packages in the target requires to
build the package manager. It would fail, with very obtuse
errors, if a test requires to install something and the
package manager hasn't been build. This will add the package
manager as dependency for testimage.
[YOCTO #10260]
(From OE-Core rev: cf548fd85297585cc5688eda45ee332200bbd4b7)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We use toolchain_create_sdk_version() in buildtools-tarball but
don't want the extra classes toolchain-scripts pulls in, therefore
split out a separate base class for this function which both
toolchain-scripts and the buildtools-tarball can inherit.
(From OE-Core rev: a398dfa654dc035c404fc12279fac9edf6403e11)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
${D} is listed in cleandirs so no need to list it in dirs as well.
The default directory is ${B} so this is a cleanup which should have
no changes to the execution.
[YOCTO #10017]
(From OE-Core rev: 7e0f95bf359bc3b5bb1578024a993e184de155cd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As things stand there are multiple races in the CONFIG_SITE handling
where checksums can change depending on whether site directories
exist or not when parsing happens. This is bad.
Secondly, there is a build race that occurs if you build virtuals
in parallel with the "main" recipe, since the main recipe is parsed
when the virtual is (since it sets variables like BBCLASSEXTEND)
and with the current code, it may look for files and directories
which could be created/destroyed which the loop is executing. This
is also bad.
The aclocal-copy directory should only ever be accessed by the call
from autotools.bbclass. This changes the parameter name to make it
clear and ensures all callers have the right usage, neatly avoiding
all the problems above. Also added better comments.
(From OE-Core rev: 3207244004c612c1a0e13921251003e5e635d1b1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel being built should match what the recipe claims it is
building. This function ensures that happens by comparing the version
information in the kernel's Makefile to the PV the recipe is using.
v2 changes:
* Match against PV instead of LINUX_VERSION
* Match against EXTRAVERSION as well (e.g., -rc4)
* Cleaned up version string building
Fixes [YOCTO #6767].
(From OE-Core rev: ec467cfaea5c8cf22c61daa8845c2e4e96449512)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Include SDKMACHINE in the tasks stamp information and the name of
the sstate-inputdirs so that changing SDKMACHINE doesn't result in
valid output of the task being deleted when SDKMACHINE is changed.
Without this patch changing SDKMACHINE and building an SDK resulted
in toolchain installers for other SDKMACHINE's being deleted from
the deploy directoy.
[YOCTO #10275]
(From OE-Core rev: d7a06b53af0066bd12f5f42e10e82b307fd069ce)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As parted is always used by wic it makes sense to make do_image_wic
dependent on parted-native:do_populate_sysroot. This should help
to avoid adding it to all wic image recipes.
(From OE-Core rev: c687c9fcc010947f52e1cd153ea74ae5f6343ca4)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the very first build, the DEPLOY_DIR_IMAGE
directory might not have been created yet, causing
the creation of the qemuboot.conf config file to
fail.
This is because write_qemuboot_conf() runs at
rootfs creation time, i.e. before deploy.
So let's create the directory if necessary before
trying to write the config file.
(From OE-Core rev: ee4697350a553a36ca17b9376911e56eee43a465)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To make sure changes to any source files are detected when externalsrc
is used, it sets BB_DONT_CACHE to force the recipe to be reparsed
every time. Previously, this was done conditionally based on whether
EXTERNALSRC was set. This worked fine for building the base recipe.
But if one tried to build, e.g., a native version of it (provided via
BBCLASSEXTEND), the recipe would not be reparsed as expected.
To solve the above problem, BB_DONT_CACHE is now set for the base
recipe if EXTERNALSRC is set for it or any of it derivatives.
(From OE-Core rev: 449a0b21255d895e8620383ce76a9d7ea41b5cc6)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default values for KERNEL_IMAGE_BASE_NAME and MODULE_IMAGE_BASE_NAME
are already assigned using ?= and anyone wanting to over-ride one is
likely to want to over-ride them all. Make the three consistent with
each other.
(From OE-Core rev: e30c6c93bb70d17244c90c2be12229148f8f6314)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow runqemu to fall back to trying the link name when
a file matching the full name can't be found.
(From OE-Core rev: 3ccbaaad75f0a53d8bcf6a5c748ec80c96a383bd)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_IMAGETYPE gives the filename of a symlink to the kernel,
which may not be available i.e. if the user downloads some build
artefacts to run on a local machine. It's also possible that the
link will point to a newer kernel than was intended for use with
the rootfs in the qemuboot.conf.
It's much more reliable to read the name of the file
KERNEL_IMAGETYPE is linking to and assign the full filename to
QB_DEFAULT_KERNEL.
[YOCTO #10285]
(From OE-Core rev: d57bdacab13605ada4cd9e9159c18fdcd6eeacbc)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Split out the functionality doing configuration re-parse check into a
separate event handler that is hooked into ConfigParsed event. This will
make config re-parsing actually work. Re-parsing in bitbake is triggered
by setting BB_INVALIDCONF whose value is checked after configuration has
been parsed (after ConfigParsed event). However, previously
BB_INVALIDCONF was set in SanityCheck event handler which caused
re-parsing never to happen.
[YOCTO #10188]
(From OE-Core rev: 8fda70bb74f7c63d393d5424436d034d2cc6c05e)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, if the gshadow file did not exist in the sysroot when
perform_groupmems() was run, it would be temporarily created and
removed again afterwards. This was supposedly due to groupmems failing
if it does not exist.
However, based on empirical testing and examination of the source code
for groupmems, it should not fail if the gshadow file does not exist
when groupmems is started. But it WILL fail if the file is removed
sometime after its existence has been check at the beginning of the
execution, but before it needs to be modified. And this is exactly
what the previous code in perform_groupmems() could cause if multiple
tasks simultaneously modified users or groups. It could cause any of
the useradd, groupadd and groupmems commands to fail as long as at
least one other recipe invoked perform_groupmems().
(From OE-Core rev: 4fcaa484a2e8046cf3277b5d14933cdaa94a4c3f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class adds a new task for all the recipes to use
cve-check-tool in order to look for public CVEs affecting
the packages generated.
It is possible to use this class when building an image,
building a recipe, or using the "world" or "universe" cases.
In order to use this class it must be inherited and it will
add the task automatically to every recipe.
[YOCTO #7515]
Co-authored by Ross Burton & Mariano Lopez
(From OE-Core rev: d98338075ec3a66acb8828e74711550d53b4d91b)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previous work to clean up the license QA code (oe-core fbdf977) had the side
effect that failing the license sanity check (bad or missing LIC_FILES_CHKSUM)
would emit an error message but wouldn't actually abort the build.
Solve this by changing populate_lic_qa_checksum() so that it tracks if the
message class was in ERROR_QA and if so, aborts the function.
[ YOCTO #10280 ]
(From OE-Core rev: 5ba1a7505b904a4aa2118fa9614d76df97597af8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some issues in sstate which can't be handled by file removal
alone. Currently there is no way to execute a command against sstate and
doing so is potentially problematic for things like dependencies. This
patch adds a mechanism where any "postrm" script is executed if its present
allowing some openjade/sgml issues to be resolved.
[YOCTO #8273]
(From OE-Core rev: 2268efd0cd3ddb40870c4c424d10444ba86d2849)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_DEVICE_TABLE and IMAGE_DEVICE_TABLES are both referenced by
_create_devfs, therefore ensure that rootfs is rebuilt if changes
are made to either variable.
(From OE-Core rev: 06092cee0dc8c7cd2408ddfa9e9dc43fd9dfea2e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After we run the build system within the eSDK internally as part of the
sstate filtering that happens during do_populate_sdk_ext, we need to
ensure that the TMPDIR created during that process gets deleted. However
we were using the TMPDIR path for the build producing the eSDK which may
not be the same (since that value would typically be filtered out) thus
if the user had set TMPDIR to something other than the default, the
temporary TMPDIR would not be deleted which not only led to extraneous
junk entering the SDK but also failures during install because the
TMPDIR path was different. In order to fix this, force TMPDIR to a known
value during the sstate filtering run so we know what to delete
afterwards.
Fixes [YOCTO #10210].
(From OE-Core rev: 038d9db66e69c9de12eb8581acb28a8facd726b6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently when you run builds from sstate, you can see warnings like:
WARNING: systemd-1_230+gitAUTOINC+3a74d4fc90-r0 do_configure: /data/poky-master/tmp-glibc/sstate-control/manifest-intel-corei7-64-glibc-initial.populate_sysroot not found
WARNING: systemd-1_230+gitAUTOINC+3a74d4fc90-r0 do_configure: /data/poky-master/tmp-glibc/sstate-control/manifest-intel-corei7-64-libgcc-initial.populate_sysroot not found
This is due to co_configure wanting to copy a limited number of m4 macros,
only listed in a recipes DEPENDS but that set is still larger than the set of
recipes which get restored from sstate.
For build determinism and to avoid these warnings, we need to make this
function match what the sstate code does. We really don't want to duplicate
the functionality since keeping things in sync would be hard so we create
a data structure which can be passed into the same underlying function,
setscene_depvalid().
[YOCTO #10030]
(From OE-Core rev: 37ffb1f7d812e40d6fa23b44782eaa8436d9ab76)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various recipes depend on the kernel's do_shared_workdir
task, a quick grep suggests all external kernel modules
(via module.bbclass), but also perf, and potentially any
additional headers as outlined in linux-libc-headers.inc
are affected.
Having do_shared_workdir in SRCTREECOVEREDTASKS means this
task is removed when externalsrc is enabled, making all
those recipes fail as the task they depend on,
virtual/kernel:do_shared_workdir, doesn't exist.
Remove do_shared_workdir from SRCTREECOVEREDTASKS so that
all those recipes work even if externalsrc is activated.
According to the comment in here, the reason for
do_shared_workdir to be removed as a task is because it
modifies the source tree, but that doesn't seem to be
case.
(From OE-Core rev: 29e99d7a57803e450920600b5d35c5b4e58a0ede)
Signed-off-by: Andre Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When IMAGE_GEN_DEBUGFS is enabled, and IMAGE_FSTYPES_DEBUGFS is left
at its default (as suggested by local.conf.sample.extended),
recipe parsing fails:
bitbake kern-tools-native # or anything else for that matter
ERROR: <poky.git>/meta/recipes-core/images/build-appliance-image_15.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'debugfs_vmdk' - possibly invalid type name or missing support class
ERROR: Failed to parse recipe: <poky.git>/meta/recipes-core/images/build-appliance-image_15.0.0.bb
Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
i.e. bitbake doesn't even finish parsing...
Since IMAGE_FSTYPES_DEBUGFS is based on IMAGE_FSTYPES, and
since the build-appliance-image is setting IMAGE_FSTYPES
to vmdk, image.bbclass/image_types.bbclass will be trying
to build a debugfs_vmdk, causing the error, as this is not
implemented.
One solution to solving this problem could be as simple as
adding a line
IMAGE_FSTYPES_DEBUGFS_remove = "vmdk"
to the build-appliance-image recipe, but that is very
specific to the error encountered and carries the risk of
the error being reintroduced in another recipe.
Another solution could be to add 'debugfs_vmdk' to
IMAGE_TYPES_MASKED in image-vm.bbclass, but again, this
approach doesn't seem generic enough.
None of the live and vm type images have an implementation
for building a debugfs version, it doesn't seem to make
sense to build debugfs versions of any of them anyway, and
given IMAGE_TYPES_MASKED appears to be intended for those
image types exclusively, it seems the right approach is to
unconditionally also mask all debugfs_ flavours from
IMAGE_TYPES_MASKED to achieve a generic solution.
Do that so.
(From OE-Core rev: 9bd682c4f1c19d68c573c11822888ee799809272)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debugfs is supposed to be used in addition to the
normal image for debugging purposes, it doesn't make
sense to artificially limit its maximum size.
(From OE-Core rev: 7cdf3b2444df8cd322d9eff1bdbdc5adddcaf22a)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this a whitelisted path containing /../ breaks the test for a file
allowed to be provided by more than one recipe.
Noticed when local.conf contains:
DEPLOY_DIR = "${TOPDIR}/../deploy"
|ERROR: core-image-minimal-1.0-r0 do_image_complete: The recipe
| core-image-minimal is trying to install files into a shared area when those
| files already exist. Those files and their manifest location are:
| .../poky/deploy/images/qemux86/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
| Matched in b'manifest-qemux86-linux-yocto.deploy'
(From OE-Core rev: d82acf20541463b14a811788d28fb1db3539885b)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tasks for image recipes cannot be locked and should be excluded from eSDK
generated locked-sigs.inc. get_sdk_install_targets() was not returning right
image targets to be excluded incase of 'minimal' sdk. This change fixes the issue.
(From OE-Core rev: 46401034f017d234833997d2fb3122190f9029bf)
Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By letting a recipe assign GI_DATA_ENABLED trivially there is a simple and clear
way to disable gobject-introspection for specific build configurations.
(From OE-Core rev: 75a5297369c7b04cef098e2a76f7f8f4781764aa)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By letting a recipe assign GTKDOC_ENABLED trivially there is a simple and clear
way to disable gtk-doc for specific build configurations.
(From OE-Core rev: 201e069625e3623ff71864f969664c6d5d3b1801)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 33b0d940b09a5ce1462476614213a58d3d62e80d)
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>
(From OE-Core rev: 79fe476be233015c1c90e9c3fb4572267b5551d1)
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>
The smart tests need createrepo to be in the native sysroot. It needs
to be one of the depends for testimage.
(From OE-Core rev: 2f1a44d33d9ecceef69d11ef92c5369314cb3bf5)
Signed-off-by: bavery <brian.avery@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The KConfig infrastructure needs to build HOST binaries in order to
provide its infratstructure. Yocto needs to force the HOSTCC and HOSTCPP
variables to BUILD_CC and BUILD_CPP to make sure that the proper compiler
is used when compiling host binaries
(From OE-Core rev: c710401a2af6488b38565e8ef32b48ed1cd0aa69)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cross-compilers are native recipes that need to be compiled by the host's
compiler. However they do not use native.bbclass
As a consequence, the various CC, CXX etc environment variables are not
correctly set and they will not honor the host compiler name provided
by the BUILD_* variables.
(From OE-Core rev: 110cc22614f92e848bbba9ecaa5e6f089f9a2749)
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If two recipes both create the same users and groups, the
second recipe can delete items created by the first causing
things like "chown" to fail for the first recipe.
(From OE-Core rev: 936150306cb13022edcadf862947c357932e80ee)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that gtk-doc-native works correctly, the gtk-doc class doesn't need to
depend on target gtk-doc.
(From OE-Core rev: 8dc4a45cc06fda29618f9f2379ed743dc0c536e3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is done similarly to gobject-introspection, but with much
less delicate hacking around the upstream way of working.
(From OE-Core rev: 1b5b429f63c323fcd46b7419a531689717a73b91)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It saves vars in ${DEPLOY_DIR_IMAGE}/<image>.qemuboot.conf, and runqemu
will read it.
The bsp which can be boot by runqemu will inherit it.
(From OE-Core rev: 1675e9b89e00b875d0da13411a2a939aa4ba5298)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10146]
(From OE-Core rev: cd5d532bd2a3f409b9470591c8d6f6b21e5995dd)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 1868db95819b45961cd7e8499ecace403e6bc91d)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the recent changes, executing depmod is not needed
anymore.
This simplifies and removes a lot of unnecessary code.
(From OE-Core rev: 8296e258b36a6238605e068e13c1982b1d12fe53)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The information retrieved via depmod is incomplete with
regards to kernel modules that are dependencies, in
particular where two kernel modules are built from
different source trees / recipes, which leads to incomplete
dependency information for packages created.
So far, our packages created didn't contain dependencies on
packages created by other recipes, as we solely use depmod
for that, and depmod can only work well after *all* kernel
modules have been copied into one place - it doesn't work
well in a staged approach.
Now that all .ko have correct dependency information at packaging
time, we can use that information to properly track dependencies
across recipies, and can combine the information from the
.modinfo elf section with the information from depmod.
(From OE-Core rev: e4af1fa3aee7f1cf00ca27944b10b886f41f2fda)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling multiple external kernel modules, where one
depends on the other, there are two problems at the
moment:
1) we get compile time warnings from the kernel build
system due to missing symbols (from modpost).
2) Any modules generated are missing dependency
information (in the .modinfo elf section) for any
dependencies outside the current source tree and
outside the kernel itself.
This is expected, but the kernel build system has a way to
deal with this - the dependent module is expected to
specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
to point to any and all Module.symvers of kernel modules
that are dependencies.
While 1) by itself is not really a big issue, 2) prevents
the packaging process from generating cross-source tree
package dependencies.
As a first step to solve the missing dependencies in
packages created, we:
1) install Module.symvers of all external kernel module
builds (into a location that is automatically packaged
into the -dev package)
2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
of all Module.symvers of all kernel-module-* packages
we depend on
This solves both problems mentioned above.
(From OE-Core rev: 88f1bc77c22091fccb00e80839adfdf34534187f)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously merge_config.sh was wrapped by the configme script, configme
took the different KCONFIG_MODES as options, and used --allnoconfig
or --alldefconfig.
With the switch to merge_config.sh no longer being wrapped, the new
processing wasn't matching the existing values and only supported
allnoconfig or alldefconfig.
To avoid breaking existing layers, and also keep any working that
have already switched, we can make the case statement match both.
(From OE-Core rev: 614227f28a023fe148307e0d85a5e9b8d9b74372)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before the kernel tools were simplified and streamlined, there was code
which not only migrated a patch/cfg/scc to the kernel build tree, it
also migrated any subdirectories of those patches.
The effect of this data migration was that any other meta data in
a patch's directory structure would be available for processing.
While we don't want to do this migration anymore, it is possible to
check the path of any SRC_URI patches, and if they include a "kernel-meta"
subdirectory add it to the search path.
This restores the functionality without the old complexity.
(From OE-Core rev: 7ef7af5c03bad28faf380986f792f7f3d4d5944d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have your own node.js application you may not publish it (or at
least not immediately) in an npm registry - it might just be in a
repository on github or on your local machine. Add support to recipetool
create for creating recipes to build such applications - extract their
dependencies, fetch them, and add corresponding npm:// URLs to SRC_URI,
and ensure that LICENSE / LIC_FILES_CHKSUM are updated to match. For
example, you can now run:
recipetool create https://github.com/diversario/node-ssdp
(I had to borrow some code from bitbake/lib/bb/fetch2/npm.py to
implement this functionality; this should be refactored out but now
isn't the time to do that refactoring.)
Part of the fix for [YOCTO #9537].
(From OE-Core rev: 4fb8b399c05a1b66986fc76e13525f6c5e0d9b58)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake sets all imported headers as system headers. This causes trouble for c++
projects [1].
Thanks to Jack Mitchell for pointing to the setting [2]. Build tested upon
meta-qt5-extra-world which had lots of fallout before.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
[2] http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126067.html
(From OE-Core rev: a5bf690e27a32c5470a4e110ab58ed0a92b9d039)
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_kernel_configme calls merge_config.sh (installed in the sysroot by
the kern-tools-native recipe) which may invoke the compiler to complete
the configuration process.
Depending on the build (and dependencies), this may error due to sysroot poisoning [1].
The errors are similar to:
make[1]: Entering directory '4.1+gitAUTOINC+a7e53ecc27-r0/linux-x64-standard-build' HOSTCC scripts/basic/fixdep
work-shared/x64/kernel-source/scripts/basic/fixdep.c:106:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
make[2]: *** [work-shared/x64/kernel-source/scripts/basic/Makefile:22: scripts/basic/x86_64-nilrt-linux-fixdep] Error 1
Adding $TOOLCHAIN_OPTIONS to $CFLAGS before calling merge_configs.sh
fixes the error because $TOOLCHAIN_OPTIONS defines the sysroot and make
uses it to correctly compile & fill all missing kernel config options.
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014-October/098253.html
(From OE-Core rev: 4b770d62472d1b1a26366de0a1742db240aa5239)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the updated kernel tools, we generate a list of sccs, patches,
configs and BSP definitions as part of the meta data generation.
It is valid if there aren't any of these artifacts found (i.e. you
are just building a branch and a default config), but invoking the
tools with no inputs isn't a good idea.
To avoid this issue, we generate a string based on the artifacts
and skip calling the tools if there's nothing to do.
(From OE-Core rev: 58715183493de1deb90f2ab075048462b4bf6c73)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fire TaskArtifact MetaData event for deployment tasks when task
either completed or skipped. Event contains full task id
(recipe+task) and list of deployment artifacts from sstate
manifest.
This should allow Toaster to always get notified about deployment
artifacts produced by the build.
[YOCTO #9869]
(From OE-Core rev: 9b08503eabf78bc1b114416523b41dcce3449f58)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding populate_sdk task to SSTATE_TASKS should make sstate machinery
to generate manifest for deployed ext sdk artifacts and do final deployment
to SDK_DEPLOY.
This is done in a similar way to do_populate_sdk in a previous patch.
(From OE-Core rev: ea3587e626a184c53dc0f484d1a0299b2b00641d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding populate_sdk task to SSTATE_TASKS should make sstate machinery
to generate manifest for deployed sdk artifacts and do final deployment
to SDK_DEPLOY.
Set stamp-extra-info flag for do_populate_sdk task. This flag is used
in the name of sstate manifest. Setting it to predetermined value for
populate_sdk task should help to get correct manifest filenames when
processing runQueueTask events.
The do_populate_sdk function is also executed by do_populate_sdk_ext
so in order to avoid conflicts with the sstate postfuncs, split
the main code into a separate function.
We also need to set SDKDEPLOYDIR as do_populate_sdk_ext expects
it in order not to break ESDK generation.
(From OE-Core rev: 8361376b8ef0147276c9ee31349e904d86900593)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding image_complete task should make sstate machinery
to generate manifest for deployed images and do final
deployment to DEPLOY_DIR_IMAGE.
Made sure IMGDEPLOYDIR doesn't contain images from past deployments
to prevent them to be included into sstate manifests.
Set stamp-extra-info flag for do_image_complete task. This flag
is used in the name of sstate manifest. Setting it to predetermined
value for image_complete should help to get correct manifest
filenames when processing runQueueTask events.
(From OE-Core rev: d54339d4b1a7e884de636f6325ca60409ebd95ff)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed deployment directory from DEPLOY_DIR_IMAGE to
SDKDEPLOYDIR to make sstate machinery to do final deployment and
generate manifest.
(From OE-Core rev: 1c8c8d8a0e2c73b3bb8a9a222bf5e8aa9927e526)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed deployment directory from DEPLOY_DIR_IMAGE to
IMGDEPLOYDIR to make sstate machinery to do final deployment and
generate manifest.
Renamed variable deploy_dir to deploy_dir_image in selftest code
to avoid confusion with DEPLOYDIR variable.
Updated the code of rootfs.py:Rootfs class to use IMGDEPLOYDIR variable
as it's now used as a new deployment destination.
(From OE-Core rev: 6d969bacc718e21a5246d4da9bf9639dcae29b02)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a preparation for changing deployment directory for image
and populate_sdk targets.
Introduced new variables, IMGDEPLOYDIR and SDKDEPLOYDIR. Set it to current
image/sdk deployment locations.
(From OE-Core rev: 8969b885044eb46dba3dbf62a0243aef673443d3)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The absence of signing_key.* in $kerneldir made signing of
out-of-tree kernel modules fail (silently). Add copying of these
files during the shared_workdir task.
(From OE-Core rev: 7aadc91b5ef86a89a827d59bd19e7b8272a5dd66)
Signed-off-by: Mattias Waldo <mattias.waldo@saabgroup.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a similar manner to diffconfig, tell the bitbake user where the
defconfig will be saved to.
(From OE-Core rev: 8e4cefb093e0df9660e2a6215cfe21c6c779c23f)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SSTATE_SKIP_CREATION variable will be used to skip creation of
sstate .tgz files. It makes sense for image creation tasks as
tarring images and keeping them in sstate would consume a lot of
disk space.
(From OE-Core rev: 7e821ccd221916ae8482b9113df2de704f4a99a4)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using PATCHTOOL = "git", the user of the system is not really the
committer - it's the build system itself. Thus, specify "dummy" values
for username and email instead of using the user's configured values.
Various parts of the devtool code that need to make commits have also
been updated to use the same logic.
This allows PATCHTOOL = "git" and devtool to be used on systems where
git user.name / user.email has not been set (on versions of git where
it doesn't default a value under this circumstance).
If you want to return to the old behaviour where the externally
configured user name / email are used, set the following in your
local.conf:
PATCH_GIT_USER_NAME = ""
PATCH_GIT_USER_EMAIL = ""
Fixes [YOCTO #8703].
(From OE-Core rev: 765a9017eaf77ea3204fb10afb8181629680bd82)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default of EXTRA_OEMAKE is already empty since commit:
OE-Core rev: aeb653861a0ec39ea7a014c0622980edcbf653fa
bitbake.conf: Remove unhelpful default value for EXTRA_OEMAKE
(From OE-Core rev: de720a8b10de17e613a8fb20d8df2af0b84507d7)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default of EXTRA_OEMAKE is already empty since commit:
OE-Core rev: aeb653861a0ec39ea7a014c0622980edcbf653fa
bitbake.conf: Remove unhelpful default value for EXTRA_OEMAKE
(From OE-Core rev: 641ab36095eb72898ec808e655014bbc5900eb95)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default of EXTRA_OEMAKE is already empty since commit:
OE-Core rev: aeb653861a0ec39ea7a014c0622980edcbf653fa
bitbake.conf: Remove unhelpful default value for EXTRA_OEMAKE
(From OE-Core rev: 4fca6c95895d7d17cdfb637d383b28ee939fbd99)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipes which don't inherit autotools or cmake bbclass and want to
use the configure options from PACKAGECONFIG need to handle
PACKAGECONFIG_CONFARGS themselves.
(From OE-Core rev: c98fb5f5129e71829ffab4449b3d28082bc95ab4)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To complete the transition/renaming to chained image type CONVERSION
while maintaining bacwards compatibility to COMPRESS(ION), make sure also
COMPRESS_DEPENDS is checked. Without this, the dependencies for legacy
COMPRESSIONTYPES do not get built.
(From OE-Core rev: 12a8ee44f05e21d5814e31cb9e13c9eab236b836)
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current style might be a leftover from when _class-target did not
exist.
Also change the assignment to SSTATECLEANFUNCS to an append, which makes
more sense. useradd.bbclass is the only user of SSTATECLEANFUNCS as of
writing, so it won't make any functional difference.
(From OE-Core rev: 79dd6be736211a722538a1234337ca16fefd5540)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that the binary to be searched for contains whitespace which will
cause the search to fail, so strip any whitespace before looking.
(From OE-Core rev: 9e920abdb0f3dcfd1a94a90461ec1ddfb2729d83)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent renaming of COMPRESSIONTYPES variable can break recipes that
still use it. Including value of COMPRESSIONTYPES variable into
CONVERSIONTYPES should prevent this.
(From OE-Core rev: 5b00d9bf5ebf2350e4a4d09b436193efba80a85c)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE should be a superset of all LICENSE_<pkg> values. That is,
LICENSE should contain all licenses and LICENSE_<pkg> can be used to
"filter" this on a per-package basis. LICENSE_<pkg> shouldn't contain
anything that isn't specified in LICENSE.
This patch implements simple checking of LICENSE_<pkg> values. It does
do not do advanced parsing/matching of license expressions, but,
checks that all licenses mentioned in LICENSE_<pkg> are also specified in
LICENSE. A warning is printed if problems are found.
(From OE-Core rev: 0f4163a12ea431d0ba6265880ee1e557333d3211)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The loop iterating over LICENSE_pn variables has never worked. In
addition, the LICENSE variable is supposed to contain all licenses
defined in LICENSE_pn variables. Thus, it is simpler just to use LICENSE
as the data we get is essentially the same.
[YOCTO #9499]
(From OE-Core rev: d7229489c7dfd35164fd107d7944f3c273776118)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake wants a relative path for CMAKE_INSTALL_*DIR, an absolute path
breaks cross-compilation. This fact is documented in the following
ticket: https://cmake.org/Bug/view.php?id=14367
$sysconfdir and $localstatedir are not relative to $prefix, so they are
still set as absolute paths. With his change ${PROJECT}Targets.cmake
that are generated by cmakes "export" function will contain relative
paths instead of absolute ones.
(From OE-Core rev: c03b32bd71dbe04f2f239556fea0b53215e403d7)
Signed-off-by: Thomas Witt <Thomas.Witt@bmw.de>
Signed-off-by: Clemens Lang <clemens.lang@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now, useradd dollar sign requires three prepending backslash characters to
avoid unintended expansion. It used to be just one prepending backslash
character before Krogoth. Restore that behaviour.
[YOCTO #10062]
(From OE-Core rev: 9e43a73c7ad576666d53c8c9e0283bc6bb9087a8)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of just removing TMPDIR from the path for display, optionally allow a
package to be passed and remove PKGDEST/package too.
This means that messages that specify a package name can pass that name and the
resulting path will be absolute inside that package.
(From OE-Core rev: 55061a43926baf6ff0e17aed02efd299ebba3c24)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The path in startup.nsh for iso image is corrupted as follows:
fs0:\EFI\BOOT^Hootx64.efi
Using printf will emit correct path which is:
fs0:\EFI\BOOT\bootx64.efi
This happens because of echo command. Switching to printf
like the one used in efi_populate() function.
(From OE-Core rev: 7540b9e68d56e7779b478d2bc09fbbedcf28976b)
Signed-off-by: Pranav Tipnis <pranav.tipnis@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"bitbake recipe -ccleansstate" should remove binary pkgs from deploy dir
as normal cleansstate does without packagefeed-stability.bbclass.
(From OE-Core rev: 0865a5b8b8fbf478fb4b2310f808bcffff84a091)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #10164]
(From OE-Core rev: 3762b42233651832c5909d7a3e873365fc0a9756)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
build_syslinux_cfg function creates syslinux configuration file.
The code assumes that the output directory exists, which is not
always the case. For example rm_work task removes rootfs directory
structure and causes build_syslinux_cfg to fail with this error:
Unable to open ../<image>-<version>/syslinux_vm.cfg
Made build_syslinux_cfg depend on output directory to ensure that
directory is created before running the function.
[YOCTO #10159]
(From OE-Core rev: c39b072fa7e96f385da338a727c67e607308d637)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This likely used to work when we expanded python functions and broke when
we stopped. Since it defaults to "", it never caused an issue but
is incorrect usage so fix it.
(From OE-Core rev: bfb395fdea642b306f110b4b8f1046f1992c622c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the enhanced functionality, the term "compression" is no longer
accurate, because the mechanism also gets used for conversion
operations that do not actually compress data.
It is possible to remove this naming problem in a backward-compatible
manner by including COMPRESSIONTYPES in CONVERSIONTYPES and checking for
the old COMPRESS_CMD/DEPENDS as fallbacks.
[YOCTO #9346]
(From OE-Core rev: 9d68c024790850cab72ead1e3372a5fcec4ef7b0)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've been running with a set of kern-tools that were designed to work
with build systems that knew nothing about git, trees, commits, etc.
As such, there's been a set of shims/wrappers in place to work with
within bitbake/oe-core. These were the *me scripts: createme, updateme,
patchme and configme.
With this commit, we strip that legacy code and use the tools directly.
This means less complexity, fewer corner cases .. and no surprises
when the tools are arunning. As another benefit, the tools consume
much less time during a typical build and have no noticeable impact
on the overall build time.
Existing .scc files, features, and processing are not impacted as
these tools are compatible with existing feature descriptions and
kerne configuration fragments.
The audit of kernel configuration fragments is now detached
from the linux-yocto build structure and process. This means that
they can eventually be tweaked to offer kernel audit to any type of
kernel build and configuration process.
Additionally, the kernel symbol audit phase can now resolve symbol
dependencies and offer guidance when a symbol is missing:
WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:
---------- CONFIG_BT_6LOWPAN -----------------
Config: CONFIG_BT_6LOWPAN
From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
Requested value: CONFIG_BT_6LOWPAN=y
Actual value:
Config 'BT_6LOWPAN' has the following conditionals:
BT_LE && 6LOWPAN (value: "n")
Dependency values are:
BT_LE [y] 6LOWPAN [n]
(From OE-Core rev: 0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We expect that any package that uses the npm bbclass
will have a runtime dependency on node.js
(From OE-Core rev: 769fae0b74d7c7992aa593907f446fab98ef5128)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The preparation script itself prints out an error on failure, and we
aren't redirecting its output anymore, so we no longer need to print out
a message here when it fails. At the same time, make the message printed
out by the script a little clearer - we're just writing the log out to
the file, we shouldn't give the user an expectation that there will be
extra details in there (other than the output produced by
oe-init-build-env there won't be).
(From OE-Core rev: 80dfaf40e087b34d6360188df372c1c3805a00bd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check a number of things as early as possible in the eSDK installer
script so that the user gets an error up front rather than waiting for
the build system to be extracted and then have the error produced:
* Check for missing utilities specified in SANITY_REQUIRED_UTILITIES
(along with gcc and g++), taking into account that some of these are
satisfied by buildtools which ships as part of the SDK. We use the
newly added capability to list an SDK's contents to allow us to see
exactly which binaries are inside the buildtools installer.
* Check that Python is available (since the buildtools installer's
relocate script is written in Python).
* Check that locale value set by the script is actually available
* Check that the install path is not on NFS
This does duplicate some of the checks in sanity.bbclass but it's
difficult to avoid that given that here they have to be written in shell
and there they are written in Python, as well as the fact that we only
need to run some of the checks here and not all (i.e. the ones that
relate to the host system or install path, and not those that check the
configuration or metadata). Given those issues and the fact that the
amount of code is fairly small I elected to just re-implement the checks
here.
Fixes [YOCTO #8657].
(From OE-Core rev: 6e6999a920b913ad9fdd2751100219c07cd14e54)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Determine the name of the current buildtools installer ahead of time,
set it in a variable and use that variable rather than the wildcarded
version everywhere, since it's much tidier.
(From OE-Core rev: d5a601db41ba3c561aced7f5a38689f6b4c9a87c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the buildtools installation failed, we were using a subshell instead
of a compound command and thus the subshell exited but the script
continued on, which is really not what we want to happen. Additionally
log the buildtools installer output to a file and cat it if it fails so
that you can actually see what went wrong, as well as amending the
environment setup script to print a warning as we do when the
preparation fails.
(From OE-Core rev: 8fb8adf309823660c3943df973c216621a71850d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A couple of fixes for the recent sstate filtering implemented in OE-Core
revision 4b7b48fcb9b39fccf8222650c2608325df2a4507:
* We shouldn't be deleting the downloads directory here, since it
contains the uninative tarball that we will need
* TMPDIR might not be named "tmp" - in OE-Core the default is tmp-glibc
so use the actual name of TMPDIR here instead.
(From OE-Core rev: 71ecd3bea680ef8c589257844512a14b65e979d3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the build in which the eSDK is being built isn't using uninative,
this will have an effect on NATIVELSBSTRING, which will mean that the
eSDK installer won't be able to find any of the native sstate packages.
To keep things simple, under this scenario just disable uninative
temporarily while we run the SDK installer to help us check the presence
of the sstate artifacts we need. Ideally I'd rather not have things like
this that are artificial in this verification step, but on the other
hand this was the least ugly way to solve the problem.
(From OE-Core rev: 9f39deea7c4af5244dbfa824a52e11590a1d4df6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were relying on uninative being enabled in the build in which the
eSDK was being produced, which is not the case for example for OE-Core's
default configuration. Move the code that copies the uninative tarball
and writes the checksum to copy_buildsystem so that it happens early
enough for that part of the configuration to be set up when we do the
filtering (which requires running bitbake).
(From OE-Core rev: 7bc95253098aca2ff195b159b34d9ac041806c75)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removing the ccache directory as part of do_clean is unnecessarily
conservative and defeats many of the benefits of ccache.
The original justification for this behaviour was to avoid confusion
in the corner case that the ccache directory becomes corrupted.
However the standard approach for dealing with such highly unlikely
corner cases (ie manually removing tmp) would also recover from
corruption of the ccache directories, without the negative impact of
defeating ccache during normal development.
(From OE-Core rev: 6ae6680ad8d51eff756dcb6500fca2530e3e3e73)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /bin/sh is a regular file (and not a symlink), we assume it's a
reasonable shell and allow it.
(From OE-Core rev: eaa0dc21a5f058a39bd7867bd3cafdb3407abe36)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default the system will expand the extra os entries for uclibc and musl
even if they are not enabled in the build. There was no way to prevent this
behavior while still getting the expansion for things like x32 or spe.
The change adds a new setting which a distribution creator can override
easily, setting the base set of canadianextraos components. The other
expansions are then based on this setting.
(From OE-Core rev: ea24d69fdf7ebbd7f2d9811cff8a77bffc19a75c)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the code gives tracebacks if there are no recipes to be built in a
BuildStarted event. Parse the list into a string rather than just taking the
first item. There is nothing special about the first time.
(From OE-Core rev: 684a3d56ef393b56f38d3272f8865f6225a282ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Give each rootfs its own RPM channel to use. This puts the RPM metadata
in a private subdirectory of $WORKDIR, rather than living in DEPLOY_DIR
where other tasks may race with it.
This allows us to reduce the time that the rpm.lock is held to only the
time needed to hardlink the RPMs, allowing the majority of the rootfs
operation to run in parallel.
Also, this fixes the smart tests by generating an index for all packages
at the time of the test, rather than using the one provided by the
rootfs process.
Original credit for the enhancement should go to Steven Walter
stevenrwalter@gmail.com.
(From OE-Core rev: a92c196449c516fe51786d429078bbb1213bb029)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prior to running oe_runmake make sure $B is the cwd. This is required
due to bitbake commit 67a7b8b021badc17d8fdf447c250e79d291e75f7
"build: don't use $B as the default cwd for functions".
Without this change, do_concat_dtb fails with:
| ERROR: oe_runmake failed
| make: *** No targets specified and no makefile found. Stop.
(From OE-Core rev: 6dca3dee34b587157d0d49c590a177ff1dabb374)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handle u-boot.rom signing (U-Boot as x86 BIOS replacement) the same way
that u-boot.img signing is handled.
(From OE-Core rev: 94e3f427bbeb005d8443e9d822c3182f280df470)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For x86, bzImage must be built instead of zImage.
Include setup.bin (which is required to boot the kernel) in the fitimage
and always use a load/boot address of 0x00090000.
For details see:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/x86-fit-boot.txt
(From OE-Core rev: 1a65d11d4b8f056fdf22c31a92d1e58dec6d89f6)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If INITRAMFS_IMAGE is set, build an additional fitImage containing the
initramfs. Copy the additional fitImage and the source (*.its) file, used
to create it to DEPLOYDIR. The fitImage containing the initramfs must be
built before do_deploy and after do_install to avoid circular dependencies.
UBOOT_RD_LOADADDRESS - Specifies the load address used by u-boot for the
initramfs.
UBOOT_RD_ENTRYPOINT - Specifies the entry point used by u-boot for the
initramfs.
(From OE-Core rev: b406a89935f148779569fa3770776e009dd51f13)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prior to assembling the fitimage, ensure that $B is the cwd due to
bitbake commit 67a7b8b021badc17d8fdf447c250e79d291e75f7 "build: don't
use $B as the default cwd for functions".
Without this change, do_assemble_fitimage() fails like:
Log data follows:
| DEBUG: Executing shell function do_assemble_fitimage
| arm-ka-linux-gnueabi-objcopy: 'vmlinux': No such file
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_assemble_fitimage
(From OE-Core rev: 42d50e8f5f3a98e50a0f50473ebc83dc6347b634)
Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix multilib + rpm since its multilib package name is special.
* Update SSTATE_DUPWHITELIST to avoid shared location conflicted error.
* Fix message when "not copying", now the messages are:
Copying packages for recipe <foo>
Not copying packages for recipe <foo>
(From OE-Core rev: 647fc7913c3d1f98efe36f01fd4e0edf2366e1a6)
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>
This is a non-functional change, which intends to correct element
names of a tuple returned by Popen.communicate().
Both in python2 and python3 subprocess.Popen.communicate() method
returns a tuple (stdoutdata, stderrdata), thus old assignments and
collateral comments are incorrect from human's point of view, however
formally there is no error in the code.
The change is desired to have to avoid copy-paste errors in future.
(From OE-Core rev: cdd9bae381deb15ac84e11a39f9d72f2757c1583)
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a non-functional change, which intends to correct element
names of a tuple returned by Popen.communicate().
Both in python2 and python3 subprocess.Popen.communicate() method
returns a tuple (stdoutdata, stderrdata), thus old assignments and
collateral comments are incorrect from human's point of view, however
formally there is no error in the code.
The change is desired to have to avoid copy-paste errors in future.
(From OE-Core rev: f8c21df86bae5a85e221b69b91b347aeba6be4c3)
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, find_license_files() in license.bbclass just blindly assumed
that all different licenses specified in LIC_FILES_CHKSUM have unique
filenames. As a consequence, only the last one of these similarly named
license files was copied and the rest were "lost". This patch changes
the behavior so that all license files get copied. However, if multiple
identically named files are found, they are renamed to <file>.0,
<file>.1 etc.
The patch also changes the handling of NO_GENERIC_LICENSE slightly.
Previously, only basenames of NO_GENERIC_LICENSE and LIC_FILES_CHKSUM
were compared when searching for the correct license file. After this
patch NO_GENERIC_LICENSE must have the full path, matching what is
specified in LIC_FILES_CHKSUM. This is required in order to be able
to handle identical filenames (basenames) consistently. For example, if
you have:
LICENSE = "my-custom-license"
LIC_FILES_CHKSUM = "file://src/LICENCE;md5=d41d8cd98f00b204e9800998ecf8427e"
you must specify:
NO_GENERIC_LICENSE[my-custom-license] = "src/LICENCE"
[YOCTO #9663]
(From OE-Core rev: d5e1375884e509ec745bac43f1f7f7950f62f280)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code was outputting variables by iterating a dictionary. In Py2 this
always results in the same iteration order but with Py3 the order changes every
execution, which resulted in buildhistory having to store diffs where fields
were simply re-ordered.
(From OE-Core rev: f9faa8df85317d12743134a44576b4882a9fb22a)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For example in a directory structure like this
.
├── symlink -> foo/bar
└── foo
└── bar
└── file
'file' could be referenced by specifying e.g. 'foo/bar/file' or
'symlink/file'. In cases like this populate_packages() might crash if
the file was referenced (in FILES) via the symlinked directory. The
outcome depends on how the user defined FILES_pn. This patch should
make the function behave more consistently. It looks for files which are
referenced via symlinked directories and handles them separately,
failing if their parent directory is a non-existent path. For example,
defining FILES_{PN} = "symlink/file" causes a build failure because
symlinks target 'foo/bar' is not included at all.
[YOCTO #9827]
(From OE-Core rev: 29d1738329ddf4e63844a9ad1158a1d41e2ee343)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The mode and owner info are saved in inode, hardlink won't change them,
so remove unneeded chmod() and chown().
* This can avoid the problem that when do_package re-run, the file's mode
maybe different if it is 0444 (changed to 0644 when re-run), this is
caused by pseudo adds 'w' on real file, and doesn't track linked source
when hard link, Peter and Mark may fix pseudo, but the removed code is not
needed, which can avoid the problem.
* To reproduce the problem, for example, version.c from gzip's ${B}:
1) bitbake gzip
2) Edit rpm-native or package.bbclass to make do_package re-run.
3) bitbake gzip
After the first build, build/version.c in gzip-dbg is 0444, but after
the second build, it will be 0644, this because do_package does:
$ ln ${B}/version.c gzip-dbg/version.c,
$ chmod 0444 gzip-dbg/version.c (it runs chmod 0644 on the real filesystem)
And in the second build, the gzip-dbg/version.c will be removed and
created again, so that stat() can't get 0444 but 0644 since
${B}/version.c is not tracked by pseudo.
(From OE-Core rev: 26ab4b431da0c00010e8d399f890c5fbf0b03c94)
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>
If the initramfs image is type lzo, then a native lzop is needed.
(From OE-Core rev: ee0640cb0c32b959ffaaac6752d582ed1d76e313)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to ensure that builds use our intltool.m4 as there is a bug in
upstream's macros when the host doesn't have XML::Parser installed.
So generalise the m4 pruning logic that we already have from gettext and add
intltool.m4.
(From OE-Core rev: 342fa2b8407552a962e7c78d0e4de7b2d0b30041)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To save time move the temporary copy of the autoconf macros, aclocal-copy, from
${B} to ${WORKDIR}. This ensures that it can't conflict with anything in ${S}
and means the pruning code doesn't need to know about it.
(From OE-Core rev: d7249c5cce6fbc7875c46f2452ca8cd045773898)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 6a8b9599945f3f57bd86a205bc107b8490518d29)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure that we have a pristine source tree after do_unpack.
[YOCTO #9064]
(From OE-Core rev: eccae514b71394ffaed8fc45dea7942152a334a1)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently packages that contains symlinks can't be extracted
and exported. This allows to export extracted such packages.
A nice side effect is improved readability.
[YOCTO #9932]
(From OE-Core rev: 0338f66c0d246c3b8d94ac68d60fbc4c314e500b)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
newval is not defined in all cases. Set to None and check if it is set.
File
"/local/foo/builds/x86/layers/openembedded-core/meta/classes/multilib_global.bbclass",
line 90, in preferred_ml_updates(d=<bb.data_smart.DataSmart object at
0xf6fd528c>):
if not d.getVar(newname, False):
> d.setVar(newname, localdata.expand(newval))
# Avoid future variable key expansion
UnboundLocalError: local variable 'newval' referenced before assignment
(From OE-Core rev: 25ebd3bbc1f9f4b1b6147d98dd43690c3bf03ee7)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These tasks relied upon [dirs] being ${B} by default. As the functions are not
simple, add back [dirs] so they work again.
[ YOCTO #10027 ]
(From OE-Core rev: 614d976ee97d6386c37afb54add5b83741ca401e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CFLAGS/CXXFLAGS in the SDK environment script adds debug-prefix mappings
that include staging area/work directories. Remove them since the SDK
shouldn't be aware of them.
(From OE-Core rev: 7918e73e9c5fe8c8c1c1d341eaa42f2f7d3ddb69)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This addresses (among others) the following problem:
- USERADD_ERROR_DYNAMIC=error causes a recipe to get skipped
because a static ID entry is missing
- the entry gets added to the file
- using the recipe still fails with the same error as before
because the recipe gets loaded from the cache instead
of re-parsing it with the new table content
(From OE-Core rev: 799c93592a9aac571d6dc05529437c0eec7b08b8)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to get more information about systemd boot process to
be able to debug random failures due to high I/O.
[YOCTO #9299]
(From OE-Core rev: a0bb64973e767c3b8e0bae18ee84ed92693922f0)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently when a recipe adds more than one user/group, the
cleansstate task will delete only the first user/group. This
will solve this behavior and delete all users/groups.
[YOCTO #9943]
(From OE-Core rev: da191d5c139a6b400d1b8fe246912b081dd18176)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I got fed up with seeing items dance around in sstate-package-sizes.txt
in the buildhistory git repo simply because they have the same size.
Let's sort the list first by size and then also by name to ensure items
with the same size are deterministically sorted.
(From OE-Core rev: 7340c1ea677731d21351d47d935d9de7d7e2eda5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add SDK_INCLUDE_PKGDATA and SDK_INCLUDE_TOOLCHAIN to the variables that
we put into sdk-info.txt
(From OE-Core rev: 4bf5be6a1fc39f367bbb59e1787cb55e7b5835ae)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SDK_EXT_TYPE is set to "full" then we really ought to be shipping
everything that is expected to be in the SDK, and that includes gdb
(it's already referred to by the environment setup script if nothing
else). This is implemented by using the SDK_INCLUDE_TOOLCHAIN
functionality I just added, since the only material thing that adds on
top of a full SDK is gdb and we should always have the rest of it in a
full SDK anyway.
Fixes [YOCTO #9850].
(From OE-Core rev: 9872dcc25c5cdfb99bda197db08476085f8c7ecc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new oe-check-sstate to filter the sstate artifacts shipped with
the extensible SDK by effectively running bitbake within the produced
eSDK and and getting it to tell us which tasks it will restore from
sstate. This has several benefits:
1) We drop the *-initial artifacts from the minimal + toolchain eSDK.
This still leaves us with a reasonably large SDK for this
configuration, however it does pave the way for future reductions
since we are actually filtering by what will be expected to be there
on install rather than hoping that whatever cuts we make will match.
2) We verify bitbake's basic operation within the eSDK, i.e. that
we haven't messed up the configuration
3) We verify that the sstate artifacts we expect to be present are
present (at least in the sstate cache for the build producing the
eSDK). Outside deletion of sstate artifacts has been a problem up to
now, and this should at least catch that earlier i.e. during the
build rather than when someone tries to install the eSDK.
This does add a couple of minutes to the do_populate_sdk_ext time, but
it seems like the most appropriate way to handle this.
Should mostly address [YOCTO #9083] and [YOCTO #9626].
(From OE-Core rev: 4b7b48fcb9b39fccf8222650c2608325df2a4507)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're to completely replace the standard SDK with the extensible SDK,
we need to be able to provide the standard toolchain on install without
doing anything other than installing it, so that you can install the SDK
and then point your IDE at it. This is particularly applicable to the
minimal SDK which normally installs nothing by default.
NOTE: enabling this option currently adds ~280MB to the size of the
minimal eSDK installer. If we need to reduce this further we would have
to look at adjusting the dependencies and/or the sstate_depvalid()
function in sstate.bbclass which eliminates dependencies, or look at
reducing the size of the artifacts themselves.
Implements [YOCTO #9751].
(From OE-Core rev: ed0d8ed72370df694f720cc13897493478dc1de9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a meta-recipe to bring the toolchain into the extensible SDK. This
was modelled on meta-ide-support but some adjustments were needed to the
dependency validation function in sstate.bbclass to ensure that all of
the toolchain gets installed into the sysroot. With this, after
installing a minimal eSDK you only need to run the following after
sourcing the environment setup script to get the toolchain:
devtool sdk-install meta-extsdk-toolchain
Addresses [YOCTO #9257].
(From OE-Core rev: 8110806b1b5534ae830a4fdd1a5293c86a712d0b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't absolutely need this - it doesn't change the default
behaviour, but it seems to me we have a convention to set default values
so we should add one here.
(From OE-Core rev: 4c734df1df3c19b0dabb9da5b4dc86b966a0d71c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake rev 67a7b8b02 "build: don't use $B as the default cwd for
functions" (included in current bitbake master) breaks the assumption
that do_bundle_initramfs runs inside the build directory.
This causes kernel_do_compile() as called from within
do_bundle_initramfs() to fail, as the former is not being executed
from the correct directory anymore. (Note that kernel_do_compile()
as called from bitbake directly doesn't suffer from that problem,
as it inherits the workdir from base_do_compile() in that case.)
Set workdir explicitly.
(From OE-Core rev: 4455da22a151c2ac006af63cbd39779b21b12580)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The replace() method of the python string class doesn't replace
in-place, then the var KERNEL_IMAGETYPE_FOR_MAKE doesn't be updated as
design.
(From OE-Core rev: 392fc3cd276d5029314c7158245bc65dd82279cd)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only check that ${S} actually exists if there was something in ${SRC_URI} to
fetch, the argument being that if SRC_URI is empty the the recipe won't be using
${S} at all.
In general recipes that have no sources can remove the unpack task, but
expecting all recipes to do this relatively advanced operation isn't realistic.
(From OE-Core rev: 8cba511ab6ea557fab9f7838dfe1fc8284bbdd68)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipes can generate several rpms such as a.rpm, a-dev.rpm, a-dbg.rpm,
when update one of them in the repo, we'd better update all of them,
otherwise, there might be a-dev.r0.1.rpm and a-dbg.r0.3.rpm in the repo,
which looks strange.
(From OE-Core rev: 2a7f203dbe4fda5dba9137503e93669392719aba)
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>
* fix for python3
iteritems() -> items()
* Return immediately for native and cross.
* Remove the usage of __BBDELTASKS, there is no such var in bitbake.
(From OE-Core rev: ccfc13adedd97f57024420639053080e047529dc)
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>
When a dependency causes a recipe to effectively be rebuilt, its output
may in fact not change; but new packages (with an increased PR value, if
using the PR server) will be generated nonetheless. There's no practical
way for us to predict whether or not this is going to be the case based
solely on the inputs, but we can compare the package output and see if
that is materially different and based upon that decide to replace the
old package with the new one.
This class effectively intercepts packages as they are written out by
do_package_write_*, causing them to be written into a different
directory where we can compare them to whatever older packages might
be in the "real" package feed directory, and avoid copying the new
package to the feed if it has not materially changed. We use
build-compare to do the package comparison.
(From OE-Core rev: cc8b1a93912f830e605e6249c446b3764e550863)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dict.fromkeys() creates a dict without order, there might be a
problem when build the same recipe again, for example:
- First build of make:
Provides: es-translation, make-locale
- Second build of acl:
Provides: make-locale, es-translation
They are exactly the same Provides, but tools like "diff" doesn't think
so. Sort RPROVIDES will fix the problem.
(From OE-Core rev: 3506172d7d9f8d92362b6ebb75582b7c3e662dae)
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>
Don't modify an OrderedDict while walking its keys.
(From OE-Core rev: eb7f08c4c01313afc8350200eeb63daefde8a6f6)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the extensible SDK installation process the final step is to
prepare the internal copy of the build system. This can take some time,
especially if you have SDK_EXT_TYPE set to "minimal" (downloading
sstate artifacts) and SDK_INCLUDE_PKGDATA set to "1" (restoring
pkgdata for world). To make this a bit less painful, use BitBake's new
quiet mode to display status during this operation so you have some idea
of how it's progressing; instead of redirecting the output to
preparing_build_system.log we grab the last console log and append it
instead.
One result of this change is that you get the errors printed on the
console during normal output rather than this going to the
preparing_build_system.log file first. In OE-Core revision
227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the
contents of preparing_build_system.log on failure, but now at least the
error contents of that log is duplicated. Besides, I intentionally
didn't print out the contents of that log during normal usage because
it's quite verbose - the bug that we were attempting to fix was about
not getting this information when seeing failures in the automated
tests, thus I've moved printing the log to the test handling code
instead.
Part of the implementation for [YOCTO #9613].
(From OE-Core rev: 0f7cb880c934b7871f3b8432f4f02603300f6129)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to add a new architecture or sub-architecture to OE, you currently
need to tweak the table in siteinfo.bbclass. This adds a mechanism so this
can be done from a BSP layer. It needs a function definition which needs
a class file but can then be done with something like:
def rp_testfunc2(archinfo, osinfo, targetinfo, d):
archinfo['testarch'] = "little-endian bit-32"
osinfo['testos'] = "common-linux"
targetinfo['mymach-linux'] = "mymach-linux-common"
return archinfo, osinfo, targetinfo
SITEINFO_EXTRA_DATAFUNCS = "rp_testfunc2"
[YOCTO #8554]
(From OE-Core rev: 2718bb9f2eabc15e3ef7cb5d67f4331de4f751d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to add a new architecture or sub-architecture to OE, you currently
need to tweak the table in insane.bbclass. This adds a mechanism so this
can be done from a BSP layer. It needs a function definition which needs
a class file but can then be done with something like:
def my_testfunc(machdata, d):
machdata["testmachine"] = {
"test64": ( 8, 0, 0, False, 32),
"testel": ( 8, 0, 0, True, 32),
}
return machdata
PACKAGEQA_EXTRA_MACHDEFFUNCS = "my_testfunc"
[YOCTO #8554]
(From OE-Core rev: c57550c9cca598315ba4408e44b138cecc22b8a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the functionality checks for the "u" and "g" flags to create users and
groups, but not the "m" flag to add users to groups. This change first checks to
be sure that the users and groups are created, creates them if necessary, then
adds the user to the group.
(From OE-Core rev: f0a77bee3d092cf79b7e584b943a623eddd6e13d)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This task runs all functions in IMAGE_QA_COMMANDS after the image
construction has completed in order to validate the resulting image.
Image sanity checks should either be Python functions which raise
bb.build.FuncFailed on failure or shell functions with return a
non-zero exit code.
Python functions may instead raise an oe.utils.ImageQAFailed
Exception which takes an extra argument, a description of the
failure.
python image_check_python_ok () {
if True:
raise bb.build.FuncFailed('This check always fails')
else:
bb.note("Nothing to see here")
}
image_check_shell_ok () {
if true
exit 1
else
exit 0
fi
}
[YOCTO #9448]
(From OE-Core rev: c9bef2ecf1a30159d11781184829f41844a58c13)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to set these as the restore from sstate will create the
directories as required.
(From OE-Core rev: 3ab3ebc06d22f0776091e39237235ea50c4503b2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use IMAGE_CLASSES which is only seen by image recipe.
(From OE-Core rev: 7be8f1a9dad4512c3a979ad744e223edb38fccc6)
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>
To remove potentially personal information and reduce irrelevant noise when
searching for similar reports the error reporting class removes ${TOPDIR} from
the logs. Whilst this is valid intention, the replacement of ' ' results in
potentially confusing logs as it appears that builds are happening in /tmp, or
whitespace can appear in places where it isn't allowed which can look like a
bug.
Solve both of these by replacing the value of TOPDIR with the literal string
TOPDIR.
Also replace TMPDIR after TOPDIR, as it's not uncommon to have TMPDIR somewhere
other than directly under TOPDIR.
(From OE-Core rev: 95794e261628f83ddab0aa7b8bafb6409cc9deb5)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently PV is defined in meta/conf/bitbake.conf as a python
expression: "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE',
False),d)[1] or '1.0'}". As FILE is whitelisted it causes PV to
not depend on it. This causes sstate code to not detect that
PV changes when recipe filename changes.
Making PV to explicitly depend on PV variable value overrides default
behaviour. Instead of depending on python expression bitbake depends
on evaluated value of PV variable, which should fix the above
mentioned issue.
[YOCTO #9806]
(From OE-Core rev: 918646ca803d56004fb0ab7c21e86cc9cb14513d)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These files are treated as the contents of a bitbake variable, so usual
bitbake variable references are supported. I considered using another
templating mechanism, for example the one used by yocto-layer, but then we'd
end up largely mapping metadata variables to template fields anyway, which is
a pointless indirection. Let bitbake expand the variables directly instead.
This feature lets us, for example, reference ${APPEND} in --append, and avoid
hardcoding the serial console tty in the wks file, and let the user's changes
to APPEND affect wic the way they do the other image construction mechanisms.
The template is read in and set in a variable at parse time, so changes to the
variables referenced by the template will result in rebuilding the image.
(From OE-Core rev: 51cb21fe5f050874d52f5b05a8a1de79ea4ebf2f)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a bit nicer to work with, and easier to override.
(From OE-Core rev: 44f1d3cc613563b8d5be61a2648d0cd336fea728)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Also delete the removal of suduko for qemumips, as galculator builds fine on
that hardware now.
(From OE-Core rev: 4a81b3f669073455c9b2ee1514c43b96df9f7faa)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can reach the method in toaster.bbclass which tries to read from
the files-in-image.txt file via a build which doesn't create that
file (e.g. "bitbake core-image-minimal -c rootfs"). This causes
the build to fail with an exception.
Check that this file exists before trying to read from it.
[YOCTO #9784]
(From OE-Core rev: 8b369cdd73ab17cdf834a591b97b25840caeb740)
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: bavery <brian.avery@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
toaster.bbclass does a scan of the image deploy and SDK directories
when a build finishes. However, this brings no benefit and could be
better managed and made easier to modify if moved to toasterui and
carried out when the BuildCompleted event occurs.
Remove the image scan code from toaster.bbclass, prior to moving it
to toasterui and buildinfohelper.
Also remove the license manifest update code, as this can also be
done from toasterui.
The postfuncs for do_populate_sdk are retained, but no longer
do the directory scan for SDK artifacts. Instead, they fire
an event with the value of the TOOLCHAIN_OUTPUTNAME variable,
as this is only accessible at the point when the do_populate_sdk
and do_populate_sdk_ext tasks are run. The value of this can then
be used by buildinfohelper to find the SDK artifacts produced by a
target.
[YOCTO #9002]
(From OE-Core rev: 67ebb5406c0fcdd1b28bf446249aa6fe34a741a8)
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: bavery <brian.avery@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Python3 the itertools module's imap function has been migrated to the
globalname space as map(). Calling itertools.imap() will fail because it
no longer exists.
(From OE-Core rev: da7a2c7b00b40a8759dbe9f4ab6df3e337e3d6b6)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was rounded in python 2, but python 3 changed the default behavior of /.
We could switch to the same behavior as previous by switching to // rather
than /, but there's value in keeping at least one decimal point, to avoid the
misleading case where it says 0% but the reuse is non-zero.
(From OE-Core rev: 35d36a4d097ce8a0fd0be2f795e3d5052d4f753c)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- libc-package.bbclass: Do not use --old-style
This option has been dropped from latest glibc
(From OE-Core rev: 78ab1e7cdedc6a73395af5d053b49cf081416732)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
localedef handles attempts to read/write the archive in parallel correctly by
creating the file atomically, gracefully handling racing to create, and has
exclusive locks when writing. Therefore I can't see any purpose to copying the
archive to /tmp and back again when manipulating it.
(From OE-Core rev: 016e4a53e3251ffcdb3c260dd2837507b520ffa6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fragment dates from when this class was used for more than just glibc
locale packaging, and as glibc-locale disables do_configure it can't have been
executed.
(From OE-Core rev: 6483fbe70e52ec9a53c918fe81162fd0c566f80f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tasks for image recipes cannot be locked - there's nothing to restore
from shared state to cover them and as a result, if you had "live" in
IMAGE_FSTYPES the build would fail with "taskhash mismatch" errors for
do_rootfs and do_image_complete for the initramfs image recipe, since it
had to try to run those. We should probably catch that issue earlier in
the build and produce a proper error, but for now at least exclude these
signatures from the locked-sigs.inc file so that extensible SDK
installers built when IMAGE_FSTYPES includes "live". (It turned out we
already had code to find other image tasks in the task list in order to
generate the list of install targets.)
Follow-up fix for [YOCTO #9826].
(From OE-Core rev: a7133bf6bb650b944d29d01129f36a56282acd2b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you build an extensible SDK for an image and IMAGE_FSTYPES includes
"live" then the extensible SDK will fail to install with a bunch of
unexpected task execution errors, matching the missing items required to
build the live image. The issue was we were still depending on do_rootfs
rather than do_image_complete. The fix was slightly more complicated
than just changing the task name as do_image_complete's dependencies are
in the form of dependencies on tasks within the same recipe (represented
in the "deps" varflag rather than the "depends" varflag).
Fixes [YOCTO #9826].
(From OE-Core rev: 2b9c092e89b421bf7fd6a7c9604a83ae420d85ba)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Opening text stream in unbuffered mode raises the following
exception In Python 3:
ValueError: can't have unbuffered text I/O
Fixed by leaving std* streams in text mode and flushing
stdout explicitly.
(From OE-Core rev: 732001cb268683f5b56e251e2964ec5b694a2147)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
stdout is already unbuffered in bitbake code. Attempt to
do it again in devshell.bbclass causes this crash when
running devpyshell:
File "scripts/oepydevshell-internal.py", line 29, in <module>
pty = open(sys.argv[1], "w+b", 0)
IOError: [Errno 13] Permission denied: '/dev/pts/6'
(From OE-Core rev: 875910451e1ce97d0c42b41b1140c8160ed1f40a)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cmake outputs percentage complete as part of its compilation process, so
we can enable BitBake's new progress scanning for do_compile here.
(From OE-Core rev: f77ea95ba5cd337f01f2a1b4fe9466feb6af9440)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new BB_SETSCENE_ENFORCE functionality to avoid having to run
bitbake twice on installing the extensible SDK - we can now do it all in
one invocation which not only takes less time, but we should also get
more meaningful errors for some types of failure, in particular where
downloading from an sstate mirror fails.
One result of this change is that you get the errors printed on the
console during normal output rather than this going to the
preparing_build_system.log file first. In OE-Core revision
227d2cbf9e0b8c35fa6644e3d72e0699db9607fa, we changed to always print the
contents of preparing_build_system.log on failure, but now at least the
error contents of that log is duplicated. Besides, I intentionally
didn't print out the contents of that log during normal usage because
it's quite verbose - the bug that we were attempting to fix was about
not getting this information when seeing failures in the automated
tests, thus I've moved printing the log to the test handling code
instead.
Part of the implementation of [YOCTO #9367].
(From OE-Core rev: e1390c1ef85862b91b067ab24f3c06ca506155ad)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Python 3 we get a bytes object from the command output and not a
string, which gives some ugly formatting for error messages unless you
decode it first.
(From OE-Core rev: 798bec6fe43116b51247284eb4e415337b2e8e04)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If BB_SETSCENE_ENFORCE is set to "1" and an sstate package fails to
download outside of the whitelist specified by
BB_SETSCENE_ENFORCE_WHITELIST, then fail immediately so you can tell
that the problem was caused by failing to restore the task from sstate.
Part of the implementation of [YOCTO #9367].
(From OE-Core rev: 9e711b54487c3141d7264b8cf0d74f9465020190)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Show progress through bitbake's standard terminal UI when checking for
shared state object availability, since this can take some time if there
are a large number of tasks to be executed and/or the network connection
is slow.
Part of the implementation for [YOCTO #5853].
(From OE-Core rev: 1a064385d6921ec90b33c9064dafaab11a36267c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new task progress functionality to report progress during
do_rootfs. This is a little coarse and ideally we would have some
progress within the installation section, but it's better than
nothing.
(From OE-Core rev: 370f08d434480c1790950e40db8f7687da78cb14)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise architecture-independent pkg-config files such as wayland-protocols
won't be found in the SDK.
(From OE-Core rev: 1bea760f3f462fdcc3eefc0d8597688d61447ddd)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When splitting kernel modules into individual packages, such packages take
their names from the module name. This is OK under most of the circumstances.
However, it may lead to package naming collisions if there exists two
modules with the same name.
Situations like this can occur when building testing modules. For instance,
there exists testing versions of the modules for non-volatile memory that
are built with different linker options but bear the same module name. If
one wants to package such modules, it is be good to be able to name
packages differently. This can be done by prefixing the package name with
a KERNEL_MODULE_PACKAGE_PREFIX that can be set by the recipes that inherit
from module.bbclass.
Cc: Megha Dey <megha.dey@intel.com>
(From OE-Core rev: 4f941e8c5ee8e95291c3beff0a2798aa13f8dfc8)
Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If linkpath points to the a file in KERNEL_OUTPUT_DIR, rather than
outside, then symlink creation for the bundled initramfs image files
fails.
This is because in that case $linkpath.initramfs and $realpath.initramfs
are in the same directory, KERNEL_OUTPUT_DIR, and hence are the same.
Since we just created $realpath.initramfs, creating a symlink with the
same name will fail.
Given that $linkpath is not necessarily the same as the kernel image type,
just removing this symlink creation is not the right thing to do, as
in that case kernel_do_deploy() wouldn't find the bundled file.
What we really want is a symlink from the name of the initramfs-bundled
kernel image type to the real initramfs-bundled kernel image, as that is
what is actually used later in do_deploy().
This brings the code path for when $KERNEL_OUTPUT_DIR/$type is a symlink
in line with when it is not.
(From OE-Core rev: 7585ebbbe4e95870ab7475737ed5b94255351c72)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If multiple kernel image types have been specified, only the very first
one would receive a symlink in DEPLOYDIR.
The reason is that we're looping over the list of image types and check
if a bundled initramfs images exists using a relative path. As part of
the loop we're changing the current directory, hence all additional
iterations fail to see the files we're looking for, and hence no symlinks
are being created.
Fix by not changing the directory and adjusting the ln invocation instead.
(From OE-Core rev: 2a6ac8ca71b669b8653eb19417faf58575385a21)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise -native variants of recipes that use these classes don't get a proper python[3]-native
dependency for some reason.
(From OE-Core rev: 834514198f9e39ce323270567e3ce744f763b637)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We patch Python's distutils modules to access STAGING_INCDIR/LIBDIR, so when
they are not set, scripts that utilize distutils (e.g. python-config) fail.
Several recipes need to export those manually to prevent such failures,
so let's do that in the class instead.
PYTHON variable is exported because otherwise autotools' python.m4
macro will pick up its own internal default, which may not be the version
that we want.
glib recipe in particular was previously using Python 2.x during build due to python.m4
defaulting to it - now it's using Python 3.x, and so needs a small fix in
deletion of *.pyc files.
(From OE-Core rev: c1e0eb62f2d89b10b187016200018830b1c77945)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using UBOOT_CONFIG format, the final u-boot binary for each config
may have different names. Extend UBOOT_CONFIG format to support different
binary to be copied.
The new format is supposed to be compatible with old one as ${UBOOT_BINARY}
is copied by default, and images,binary can be empty.
An example format to specify it, in the machine, is:
UBOOT_CONFIG ??= "sdcard-ifc sdcard-qspi lpuart qspi secure-boot nor"
UBOOT_CONFIG[nor] = "ls1021atwr_nor_config,,u-boot-dtb.bin"
UBOOT_CONFIG[sdcard-ifc] = "ls1021atwr_sdcard_ifc_config,,u-boot-with-spl-pbl.bin"
UBOOT_CONFIG[sdcard-qspi] = "ls1021atwr_sdcard_qspi_config,,u-boot-with-spl-pbl.bin"
UBOOT_CONFIG[lpuart] = "ls1021atwr_nor_lpuart_config,,u-boot-dtb.bin"
UBOOT_CONFIG[qspi] = "ls1021atwr_qspi_config,,u-boot-dtb.bin"
UBOOT_CONFIG[secure-boot] = "ls1021atwr_nor_SECURE_BOOT_config"
(From OE-Core rev: 2a5c484f314ddc75cab5f0d01b0215d7fc405b6b)
Signed-off-by: Ting Liu <ting.liu@nxp.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe is using the autotools class then presumably it is using Makefiles.
However the default do_compile() is forgiving and silently handles a missing
makefile, which means that if a recipe is using a hand-coded static Makefile
(e.g. git) but doesn't use brokensep the recipe will fail in do_install.
To make debugging this easier, override do_compile in autotools so that it fails
if a Makefile isn't present.
(From OE-Core rev: 14839515301754e0b512fe3054d95dabc77ad829)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This doubles the amount of extra space that is provided for SMART and
RPM, as they consume more disk space during qa testing via testimage
[YOCTO #9800]
(From OE-Core rev: 2d636068d9d3a1ea2db3ace49462be13ba9ef125)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CMake recipes contain a mismatch between the environmental variable
which defines where the Modules are installed and the location where they
actually are. This patch fixes the environmental variable to point to the
proper folder defined according to the cmake version.
(From OE-Core rev: 642bd49964690259328f506df41a1764c5ac6226)
Signed-off-by: Jose Pardeiro <jpardeiro@rapyuta-robotics.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously when USERADD_ERROR_DYNAMIC was set to "1", an exception was
raised if no numeric UID/GID could be determined for a user/group. Now
it is possible to set it to either "error", which results in the old
behavior, or "warn" in which case a warning is issued instead.
For backwards compatibility reasons, it is still possible to set
USERADD_ERROR_DYNAMIC to "1" and get an exception in case of failure.
(From OE-Core rev: 58c82f79efee8e68fa63b96a32f54660afb15769)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A regression was introduced with commit 3149319a whereby setting
USERADD_ERROR_DYNAMIC no longer resulted in an error for users and
groups that were missing numeric UIDs and GIDs but were not mentioned
at all in any passwd or groups file.
[YOCTO #9777]
(From OE-Core rev: adc0f830a695c417b4d282fa580c5231e1f0afbe)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable the perforce fetcher to call bb.fetch2.get_srcrev() as it can use
'SRCREV = "${AUTOREV}"'.
(From OE-Core rev: 9d6ac71e4d954d857ecb1708ab4fe4bc552244aa)
Signed-off-by: Andrew Bradford <andrew.bradford@kodakalaris.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
dpkg-build needs to be executed in the root of the package, so save and restore
the current directory so this task doesn't modify the state.
(From OE-Core rev: c294f4ed5a02b055916cfc26a2fca672edee1208)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
opkg-build needs to be executed in the root of the package, so save and restore
the current directory so this task doesn't modify the state.
(From OE-Core rev: 43dac97f397143abf61fc1c105ea0e4f2fffb90b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function uses chdir() heavily, so save and restore the cwd so that it
doesn't affect the system state.
(From OE-Core rev: d3059e5d35dcb01641e828c5182615b8fbf1f2e5)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_compile_kernelmodules was assuming that the current directory was ${B} but
didn't make that explicit, so use an absolute path to ensure this always works.
(From OE-Core rev: a26ec548aabda74acfdd1e2893b98b47bc513b15)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to chdir() when creating image symlinks, and using chdir()
changes the state for future tasks.
(From OE-Core rev: 2fdf06fbe986d742f6bb13e9348b50e9aab03139)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hard links can still fail even if st_dev is the same for source
and destination. In case of EXDEV error, fall back to copying.
(From OE-Core rev: c00423d6bab9849e331beadf4d3cee90e04fe295)
Signed-off-by: Manuel Huber <manuel.h87@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As rm_work is just cleanup it shouldn't starve more important tasks such as
do_compile of I/O, so use BB_TASK_IONICE_LEVEL to run the task in the idle
scheduler class.
(From OE-Core rev: 6025a14dbbd09b2805fe2e17ddc24f2a515cb832)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class exists purely to add a number of SDL dependencies, which should be
done directly in the recipe.
(From OE-Core rev: b2a75aad679fd97ff2b51a7a8ee03bd22be8d7a7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When sysvinit is not in use, update-rd.d class adds build dependencies
that won't be needed, this patch removes the build dependecies and
won't add the task to PACKAGESPLITFUNCS.
[YOCTO #9515]
(From OE-Core rev: 5b2139a79cd8c280e755923016b3a6e84413184e)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Do exact match for rootfs type, instead of pattern match, to avoid
unexpected build error due to redundant rootfs type build.
E.g. when building ext2.gz.u-boot, both .gz.u-boot and .u-boot are matched,
the following build error will appear, actually .u-boot is not needed.
| mkimage: Can't open .../core-image-minimal-<machine>-<yyyymmddhhmmss>.rootfs.ext2.gz: No such file or directory
(From OE-Core rev: 46bc438374de74af76d288520c6252c9b7840767)
Signed-off-by: Zhenhua Luo <zhenhua.luo@nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If all locales are being generated then the list used is the keys from a
dictionary. In Python 3.4 onwards the ordering of a dictionary changes for
every instance, so sort the key list.
(From OE-Core rev: 7f6d7f729df37747be0d2cd2503cddca0184fd1f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're about to rewrite the data structures in taskdata/runqueue in bitbake
and we 'leaked' knowledge about those structures to this single function.
Add a 'v2' function definition for use with the newer bitbake, the older
one can remain for compatibility for a while, then be removed. The function
is comparatively simple and rarely changes.
(From OE-Core rev: 2a6f88d51414993d18096f7f0dc27c0b862240bc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the following warning with Python 3.5:
/usr/lib64/python3.5/re.py:203: FutureWarning: split() requires a
non-empty pattern
(From OE-Core rev: a7a783c30cc58008f0e070dad39d40038e0a5eb5)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids warnings about unclosed files with Python 3.
(From OE-Core rev: 77adf8341694b76cf58b7a31dda18b85b3eb87a2)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If /init is just a symlink to /sbin/init, debugfs creation
fails with the following error:
ERROR: Error: The image creation script '<...>/debugfs.create_image.cpio' returned 1:
touch: cannot touch '<...>/cpio_append/init': Permission denied
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_rootfs
The reason is that IMAGE_CMD_cpio() is run twice on the same
WORKDIR. The first run creates a symlink in WORKDIR/cpio_append/init
to point to /sbin/init, while the 2nd run then tries to 'touch'
that link, which will fail, of course since /sbin/init is not
usually writable by non-root users.
Fix this by providing knowledge to the IMAGE_CMD_xxx() scripts
with regards to the fact that they are being executed in the
context of debugfs creation. The IMAGE_CMD_cpio() can now be
intelligent in the sense that it can avoid all additional symlink
handling during the debugfs run. The symlinks do not need to
be part of the debugfs, so we can skip that part altogether
in that case.
(From OE-Core rev: 659ae1d7df28115429f6f31450fad6d1f86e3031)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Python3, str.encode() returns byte strings, which later are not
converted back to strings automatically, leading to "TypeError: Can't
convert 'bytes' object to str implicitly" in code which reads PKGV and
SUMMARY and expects to find strings there.
The npm.bbclass must use values for d.setVar() that meet that
expectation, and thus the redundant (and in Python3, harmful)
.encode() gets removed.
(From OE-Core rev: 241e094bcd9212204350f9855257474908f82a3c)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This create tarballs in the testexport directory in order
to make easier to distribute the test in another systems.
There are three tarballs, one for the metadata that is not
arch dependant, another for packages needed by the DUT
(this depends of target MACHINE), and the last one for the
SDK needed by the systems that perform the tests.
This also create only the tarballs that are needed.
[YOCTO #8481]
(From OE-Core rev: f8a0456e100b07a966cc24a78f197400c5a2ccab)
(From OE-Core rev: a91a603676b088abcb648cc558c33da6292b9be6)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support to export the SDK tarball needed when a test
system doesn't have the required software to perform runtime
tests.
The support is when exporting the test and when running
the test on a remote system. The user of this feature just
need to set TEST_EXPORT_SDK_ENABLED to "1" and declare
the sdk packages in TEST_EXPORT_SDK_PACKAGES.
[YOCTO #7850]
(From OE-Core rev: a6041f81b81baa7564e4c712fc88de2b997e52e4)
(From OE-Core rev: 05e6c89f0f71311f8bd32cdb86a2deb789c58035)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Exctraction of RPMs needs cpio, not all distros include cpio by
default, so we need to build it.
[YOCTO #8694]
(From OE-Core rev: 95cd427b3887b087533fba11c67ef9bc173f9aa5)
(From OE-Core rev: 5a4c73bd3f2bbba2ad5413367fa7ca2f625ffdd7)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the functionality to install/unistall packages in the
DUTs without the use of the package manager. This is possible
with the extraction introduced in package manager class.
testimage and testexport bbclasses has been modified in order
to support this new feature.
[YOCTO #8694]
(From OE-Core rev: b7111d9e9d64d21f57729d1ac1865aea6e54cc8b)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In python3 the functionality to import modules has been changed and
this broke the capability to add runtime tests from other layers.
This commit returns this capability to testimage and testexport.
[YOCTO #9705]
(From OE-Core rev: a26f23d3ce8f7e9f59dbc9bf27516377fd7a0a6d)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* otherwise kernel is rebuilt every single time and often it fails when
building external modules
[YOCTO #9352]
(From OE-Core rev: 9d23daf03ece06185224f869e9b7f73789689c2d)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
swabber hasn't been used in years and never did work well in the first
place. Remove its recipes, class and configuration.
(From OE-Core rev: e18657df0b7e45a224fae17e68c447eae94258ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove deprecated attributes in order to use python3.
runexported was changed to use python3.
[YOCTO #9702]
(From OE-Core rev: 9129af6dc421455c0253be313bf5781b913dc5fd)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since mtools has been patched to live with filesystems with sizes
not divisible by sectors-per-track, we no longer need to try to
set the size based on our guess of the sectors-per-track dosfstools is
going to use.
(From OE-Core rev: 334e32af88b310ff1ed950d127a6dedeb460f8d0)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "systemd-boot" is gummiboot now included into systemd project.
The old gummiboot project supported in OE is dead.
Our intention is to get a gummiboot-like EFI bootloader without
much dependency on systemd and its features.
This work is largely derived from the existing bbclass and recipes
of gummiboot and systemd.
(commit tip: ee25d0e398)
Please refer to the history up to the tip for authorship and
credit information for the original works.
To enable the systemd-boot in build, add this line
EFI_PROVIDER = "systemd-boot" in your machine conf file.
(From OE-Core rev: e9add1cd01e498d2aa52528ec52342cae48a387a)
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new variable allows for images to be created without an
editable boot line in syslinux. Default behavior remains unchanged.
(From OE-Core rev: 935578c139a260c18e437419be82d7fd7e8be81a)
Signed-off-by: Michael Davis <michael.davis@essvote.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch contains all the other misc pieces of the transition to
python3 which didn't make sense to be broken into individual patches.
(From OE-Core rev: fcd6b38bab8517d83e1ed48eef1bca9a9a190f57)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
urlparse is replaced with urllib.parse functionality in python3
(From OE-Core rev: ecfcc5dad20943b762a741546732a6c447265251)
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xrange() no longer exists in python 3, use range()
(From OE-Core rev: d022b4335100612d6596cc4c4956cb98ed5873cc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Iterators now return views, not lists in python3. Where we need
lists, handle this explicitly.
(From OE-Core rev: caebd862bac7eed725e0f0321bf50793671b5312)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3 standardises its use of iteration operations. Update
the code to match the for python3 requires.
(From OE-Core rev: 2476bdcbef591e951d11d57d53f1315848758571)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In python3, strings are unicode by default. We need to encode/decode
from command pipelines and other places where we interface with the
real world using the correct locales. This patch updates various
call sites to use the correct encoding/decodings.
(From OE-Core rev: bb4685af1bffe17b3aa92a6d21398f38a44ea874)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The syntax for octal values changed in python3, adapt to it.
(From OE-Core rev: 737a095fcde773a36e0fee1f27b74aaa88062386)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We really want the en_US locale as per the configuration and
previous patches. Don't set it back to C as things will break
under python3.
(From OE-Core rev: 42af63f326b03b32019c8b808b7ba07027f209b8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding all the users / groups to systemd is only available for readonly
file systems. This change allows users to add them to read / write file
systems as well by specifying:
ROOTFS_POSTPROCESS_COMMAND += "systemd_create_users"
Also, add "--shell /sbin/nologin" to each user's add params.
[ YOCTO #9497 ]
(From OE-Core rev: 98a4c642444a524f547f5d978a28814d20c12354)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order for strip and split to work together, we need to populate the
data structors if either split OR strip are not inhibited.
Original behaviour:
INHIBIT_PACKAGE_STRIP: no strip, no debug split
INHIBIT_PACKAGE_DEBUG_SPLIT: strip, no split
Behaviour after this patch:
INHIBIT_PACKAGE_STRIP: no strip, debug split
INHIBIT_PACKAGE_DEBUG_SPLIT: strip, no split
BOTH: no strip, no split, DNP data structures
(From OE-Core rev: 0df6dabdf0a61ae7b99c6a792f1eec754a7b23bd)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nothing is requiring it in oe-core or meta-oe.
(From OE-Core rev: 79a98af63c0101fb49c16b762401950cf30c492a)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is much cleaner than sharing python-dir.bbclass between python 2
and 3 classes, and doing confusing overrides in them.
(From OE-Core rev: 3891fcec863602a0ae6d0f3d305ea50a79a205d9)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These classes do not seem to be used by anything.
(From OE-Core rev: 5a149a051f91404b736a7c93b4b864f206cc7b1b)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code that utilized them was superseded by the code (in the same patch!)
that is utilizing STAGING_LIBDIR/STAGING_INCDIR, and wasn't correct in the
first place as HOST_SYS is not necessarily the same as the sysroot directory
name.
(From OE-Core rev: 8834e81a38c24a066bb4fefa93da61011d0db244)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
u-boot-nodtb.img doesn't exist so if UBOOT_SUFFIX = "img" is used
u-boot.img must be rebuilt by running make with
EXT_DTB=${DEPLOYDIR}/${UBOOT_DTB_IMAGE} then the resulting .img file must
be install to the deploy directories.
(From OE-Core rev: 4afee787e455ce1d4c002cd5c003182f1fc50028)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is not necessary for those targets, adds to the build time, and pulls
in the unneeded qemu-native dependency.
(From OE-Core rev: be18364edd5cd2c664f68120063a1e147563faab)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
https version seems more reliable and in an informal test fetching
all gnupg recipes now takes <20% of the time it used to.
Define GNUPG_MIRROR in bitbake.conf so future tweaks to this are
easier. Replace some slower mirrors with the official ftp site
and another from gnupg.org mirror list.
Set UPSTREAM_CHECK_URI in all recipes that need it to
"https://gnupg.org/download/index.html" as the directory listings
are not up-to-date.
(From OE-Core rev: dfc9178e2f2b6873ca497d981e308e00d15280b5)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic will be needing this for its bootimg-efi plugin.
[YOCTO #9556]
(From OE-Core rev: 43ca968c5af129a990625923bc28131b8701386d)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic will be needing this for its bootimg-efi plugin.
[YOCTO #9556]
(From OE-Core rev: ec8dc34f974ddda420bddbd195fb344e3db46cab)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename do_kernel_link_vmlinux to do_kernel_link_images and make a
symbol link to vmlinuz(if exists) for reference in arch/$arch/boot
directory.
Signen-off-by: He Zhe <zhe.he@windriver.com>
(From OE-Core rev: 6e58f54be103814b6b8a85b236510633c49e6832)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add KERNEL_IMAGETYPES to support building packaging and installing
multi types of kernel images, such as zImage uImage, at one time.
KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.
(From OE-Core rev: 849b67b2e4820564b5e5c9bd4bb293c44351c5f3)
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Because runexported.py instance an ExportTestContext
object, there is no need to export the data in
to reconstruct the object based in a dummy class.
[YOCTO #8478]
(From OE-Core rev: f4da3832a908f79e2d0d0a886adab0aeb5e37908)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When deltask foo, also deltask foo_setscene.
(From OE-Core rev: 04a2ae65d3d98b9f33ab4bd8372676ad1e1de6d2)
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>
npm takes a target_arch flag which needs to be set to do some gyp compilations
correctly. It also doesn't use the same mapping as OE for target arch so a
small function is required to make the mapping work. Function is taken from
meta-nodejs
(From OE-Core rev: f402225311e4bbb62ba9781ab274420abaac0fb4)
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the sstate was all downloaded to the same directory and then
symlinks were added in the directories that pointed to the siginfo and
sstate in the parent directory.
This change makes it so that now the files are just downloaded to the
correct location without the need for symlinks.
(From OE-Core rev: 55d25ed6b30ed7105d3b6421fbf2a03cea009a59)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a symlink does not get created, it is useful for debugging to log
what would have been created and why it was skipped.
(From OE-Core rev: d2b4da7d21ce5295442bd2d5c760e64cf843aabb)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a derived distro adds a certain type, say zip, to
COMPRESSIONTYPES and later OE-core does the same, we end up with the
type being listed twice, and that would have undesired effects
(commands generated twice).
So to support such loosely coupled extension, we de-duplicated the
list of types first.
Alternatively, such a situation could also be treated as error. But that
seems unnecessary because typically commands for the same type will also
do the same thing.
(From OE-Core rev: 85855af359c2c3bfc1eaa942c95f1f7d7cc6698e)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update older exception syntax to modern one required by python 3.
Compatible with python 2.7.
(From OE-Core rev: d13f0ac614f1d1e2ef2c8ddc71cbfcf76a8dc3f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use spaces, not tabs for python functions.
(From OE-Core rev: 96ed92aded49fc47c7e407d36ba4f03dafee28cd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
file() API doesn't exist in python 3, convert to open(). Also handle
some cases where files aren't closed. Compatible with python 2.7.
[Contributions from Ed and Richard]
(From OE-Core rev: 0f4ec13e11bb8abe21aba2a28547dfb9372bc377)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel being built is older than OLDEST_KERNEL and we're building
with glibc, then the C library we're building is probably not going to
be compatible with the kernel and we should warn the user. (This is
easier to do here rather than when building glibc, because we don't
necessarily have the information we need to determine the kernel version
there, whereas we do here.)
Fixes [YOCTO #8653].
(From OE-Core rev: 2e66f57febe85a63ce2ab98eaf6318d47eb60939)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_VERISON -> KERNEL_VERSION (in a comment)
(From OE-Core rev: 3f1d813e7183750b5189ae1ee99fd2f0bdeacac7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Blacklist SSTATE_DIR, DL_DIR and TMPDIR by default to avoid problems
such as the one mentioned in [YOCTO #9605].
* Blacklist BB_NUMBER_PARSE_THREADS since we already blacklist
BB_NUMBER_THREADS and they may be set separately.
Fixes [YOCTO #9605].
(From OE-Core rev: 3f2dcaaab0f5bc169086a8b6fd57c5606742cc4d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel fitImage must be amended with signature if and only if
UBOOT_SIGN_ENABLE = 1 . In the current case, the UBOOT_SIGN_ENABLE
could be either 0 (default) or 1 , which test -n always correctly
interprets as non-empty string, thus always true. This does not
match the logic above though, so replace the test with check which
passes only for UBOOT_SIGN_ENABLE = 1 .
(From OE-Core rev: 158cbd737f9f6c2de756506caf919a0a3d0a05b9)
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Yannick Gicquel <yannick.gicquel@iot.bzh>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"/usr/src/kernel" is being hard-coded in multiple recipes so far, move its
definition to bitbake.conf.
(From OE-Core rev: eb9f900527e02ca08a1de14b4ac773f513bb1ee4)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove this file as it has been deprecated in the previous release.
New entries should be added to recipes itself.
(From OE-Core rev: a3075bf29f0fa80489e3dd2ade65cc3a3b3d0332)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When there are more than 1 packages in a recipe requiring useradd
services, they are concatnated and a ';' is inserted just after
each of the users being added by the packages. A situation arises
in cases where this is controlled by PACKAGECONFIG then we add a
';' separator in the USERADD_PARAM value itself for each packagecofig
since we do not know which one will be picked, we end up in situation
where the final string returned from get_all_cmd_params() appears to be
a; ; b; c;
and then the logic which uses these cmds triggers with ';' as separator
but in this case it will fail after executing useradd 'a' because the next
cmd it will call will be just a whitespace
This is highlighted by the systemd patch to add more users as needed
by systemd 229 components.
(From OE-Core rev: e8d4356c38e3c2aacd6dc49231c73bcb7d597308)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* useradd/userdel functions will fail for recipes which override their target prefix
(e.g. to /opt/foo), because it will try to use pseudo from native-sysroot/opt/foo/bin/pseudo
(From OE-Core rev: 96189e71a86c0f4833e8e51d678208fd908bfe30)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mark Hatle
Zubair Lutfullah Kakakhel
Stephano Cetola
Martin Jansa
Peter Kjellerstedt
Aníbal Limón
Ulf Magnusson
Ross Burton
Richard Purdie
Raymond Tan
Joshua Lock
André Draszik
Ioan-Adrian Ratiu
Ed Bartosh
Juro Bystricky
Patrick Ohly
Markus Lehtonen
Otavio Salvador
Andreas Müller
Mariano Lopez
California Sullivan
Andre McCurdy
Paul Eggleton
Max Krummenacher
Amarnath Valluri
Robert Yang
bavery
Jérémy Rosen
Joe Slater
Alexander Kanavin
Henry Bruce
Bruce Ashfield
Mattias Waldo
Stefan Müller-Klieser
Mikko Ylinen
Thomas Witt
Maxin B. John
Pranav Tipnis
Jonathan Liu
Olof Johansson
George McCollister
Andrew Bradford
Vladimir Zapolskiy
Trevor Woerner
Jeremy Puhlman
Jacob Kroon
Kai Kang
Matt Madison
Christopher Larson
Elliot Smith
Khem Raj
Ricardo Neri
André Draszik
Ting Liu
Saul Wold
Jose Pardeiro
Manuel Huber
Zhenhua Luo
Jussi Kukkonen
Jianxun Zhang
Davis, Michael
He Zhe
Brendan Le Foll
Randy Witt
Marek Vasut
Ming Liu