Specifically:
1) remove +git${SRCPV} stuff from comparison and output; it's just
unnecessary clutter;
2) write the commit id of the latest version tag into the output;
this saves quite a bit of trouble of manually checking what that
commit id is when doing version updates;
3) when UPSTREAM_CHECK_COMMITS is set, ignore the tags altogether;
instead check if the latest commit is different to the one we use,
and if so, report that the recipe can be updated to said commit
(which is also written into the output, as in 2). Multiple
recipes are failing the upstream check because they never
issue tags, now we can fix them.
(From OE-Core rev: 591d57877d3d3e659d78c0ed33f4c515e3f6f8fb)
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 have seen a small number of issues with ROOTFS_SIZE not getting
computed correctly, resulting in a failure in the mke2fs processing
and populating the resulting new filesystem.
This information should help us to reproduce [YOCTO #12304]
(From OE-Core rev: 3a72f6783e142d53d19b37811a854d08d32485ab)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuconf files are currently written relative to TOPDIR. What
makes more sense is to write paths relative to the location of the
file. This makes moving them around and decoding the end paths in
runqemu much easier.
The effect of this should allow less use of bitbake to determine
variables and allow us to simplify runqemu.
(From OE-Core rev: 55a0028a961c0ad3c2e5729a9e3919cbbf256fe1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is particularly useful if you want to use gdb-cross as there
is no other good way to access it now with RSS.
(From OE-Core rev: e8648a022c93175d84baf3852d4d364b19d8d795)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
.txz is .tar.xz, so add it, as this can actually be found in the
wild.
(From OE-Core rev: 58af8c2e4bd17692274fc5a6ac8f8af84319fec6)
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>
Add mappings for the microblaze(eb/el) linux and linux-musl variants to
use architecture common linux site data.
(From OE-Core rev: 634d1ed2cd89b8ac28b918be3561b135f7418b25)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If PACKAGE_EXCLUDE is constructed using _append then it's possible
that the final value will contain only a space. Currently that
results in build failures due to an invalid opkg command line.
(From OE-Core rev: f832f57ba9f6babb946fbde580004acfd85667e1)
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>
Although it may not appeal so much to users to prefer 80x24 consoles,
the general trend is for screens to get bigger and the current output
has started to look a little cramped on a modern HD display.
Increasing from 17 to 20 is obviously arbitrary, but does give enough
space to cleanly display layers such as "meta-nodejs-contrib" and
"meta-virtualization" while still keeping the output fairly compact.
(From OE-Core rev: e556b85a452a4ebf34a0c9581608f135bbad2e2c)
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 you have a recipe that uses overrides to conditionally extend
SRC_URI to add additional patches, then you will often need to update
those patches if you're making other changes to the source tree (for
example if you're upgrading the underlying source). Make this possible
with devtool by creating devtool-override-* branches for each override
that conditionally appends/prepends SRC_URI, and have devtool
update-recipe / finish check each branch out in turn and update the
corresponding patches.
A current example of a recipe that does this is the quota recipe - it
applies an additional patch if musl is the selected C library (i.e.
libc-musl is in OVERRIDES).
Note that use of this functionality does require some care - in
particular, updates to patches that appear on the main branch (named
"devtool" by default) should be made there and not only on one of the
specific devtool-override-* branches that are created for each override.
The recommended procedure is to make the changes you want to make to the
main branch first, then check out and rebase each devtool-override-*
branch, testing each one by activating the corresponding configuration,
and then finally run devtool finish.
Fixes [YOCTO #11516].
(From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8)
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>
Currently, the fact an error message is shown means the rest of the
task logs are suppressed. In this case we don't want that as it hides
the real errors and useful information. Therefore override this behaviour.
(From OE-Core rev: 7058ac23c5ce32fbdc4be6c05f85550e1fd9fe77)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously it was working only if only one shared library was found, and
broke when there were several.
(From OE-Core rev: a4da3957f4577f9826c73e1d23bcffe9ee96a7d4)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I have no idea why we didn't do this but it means the code has nowhere
to log to unless we do this. This means we can then use the logger
to log data to the task logs.
(From OE-Core rev: e241fb128840889acff79dbf3fae7bfaafcb5357)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The licenses of EXTRA_IMAGEDEPENDS recipes are being referenced in
image postcommand write_deploy_manifest, but a dependency is missing
between do_image and do_populate_lic of EXTRA_IMAGEDEPENDS recipes,
this leads some license files not present when write_deploy_manifest
runs, hence will cause build errors.
Fixed by letting do_image depend on do_populate_lic of
EXTRA_IMAGEDEPENDS recipes.
(From OE-Core rev: 276ff1f22d00edd6c9728e44ed5d6692a6c9e04f)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The externalsrc class code assumes that the source directory
(EXTERNALSRC) exists before bitbake is called. Otherwise do_configure
will fail obviously since externalsrc does not fetch anything.
Commit 3ca6085729 ("externalsrc: Handle .git not being a directory")
changed this behaviour. Now on a missing EXTERNALSRC directory we get
a bb.data_smart.ExpansionError during _parsing_, way before
do_configure can be run.
This new behaviour creates two problems:
* First, there error message is very cryptic (and it's hard to
provide a better message since no task is ever run):
ERROR: ExpansionError during parsing /<...>/<...>.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception FileNotFoundError: [Errno 2] No such file or directory: '<...>'
* Second, this prevents creating a class based on externalsrc that
automatically fetches the code in EXTERNALSRC before do_compile
runs.
Fix both problems by simply calling git with '-C ${EXTERNALSRC}'
instead of calling git inside the non-existing directory. This changes
from a bb.data_smart.ExpansionError to a
subprocess.CalledProcessError, which is in line with what's actually
going on: git is telling us it can't find the git dir.
Also remove a comment that does not apply anymore.
(From OE-Core rev: 8e8251582e977d7c6ab525ac1b493fbbe3af38b2)
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Joshua Watt <jpewhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current mechanism doesn't allow to use any non-determenistic variable, except 'DATE' and 'DATETIME', inside IMAGE_CMD_${FSTYPE} prototype.
Passing 'vardepsexclude' values from IMAGE_CMD_${FSTYPE}, so users will be able to avoid taskhash mismatch problems.
(From OE-Core rev: cb19166c540969f56959e25c1068934bdc40b013)
Signed-off-by: Igor Romanov <i.romanov@inango-systems.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to the bitbake documentation, the "d" global datastore should be
used instead of "e.data" because the latter is deprecated.
(From OE-Core rev: 43820fe158cbc34c9fd67e84238931331153f127)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a distro uses useradd-staticids.bbclass and some developer
unfamiliar with the static ID mechanism tries to add a recipe which
needs new IDs, the resulting error or warning is typically not
something that the developer will understand.
Even experienced developers do not get enough information. They first
must find out whether the missing ID is for a system user or group,
then locate the file(s) in which the ID could be added. Both of this
is now part of the message:
ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie -
cronie: system groupname crontab does not have a static ID defined.
Add crontab to one of these files: /.../conf/distro/include/my-distro-group
The case that no file was found is also handled:
ERROR: .../meta/recipes-extended/cronie/cronie_1.5.1.bb: cronie -
cronie: system groupname crontab does not have a static ID defined.
USERADD_GID_TABLES file(s) not found in BBPATH: files/group
It would be nice if the error message could also list the range in
which a new ID needs to be allocated, but /etc/login.defs isn't
available at the time of creating the message, so that part is still
something that a developer needs to know.
(From OE-Core rev: 883bfc2bbb4d2120dbad6b0f2056503b012b1a2b)
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>
When enabling useradd-staticids.bbclass, one has to define static IDs
for all recipes in a world build, otherwise those without static IDs
generate parse errors or warnings, depending on USERADD_ERROR_DYNAMIC.
Defining unused IDs is a lot of work and clutters the passwd/group
file of a distro.
Distros which want to avoid this can now set USERADD_ERROR_DYNAMIC =
"skip" and recipes which would have triggered a message then silently
get disabled. Only trying to build them shows the error message:
$ bitbake apt
...
ERROR: Nothing PROVIDES 'apt'
ERROR: apt was skipped: apt - apt: username _apt does not have a static ID defined.
(From OE-Core rev: 9113928cea88c2187e8640ac489671cb81f58103)
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>
Exit quietly makes it very hard for debugging when user is not added as
expected, print a warning helps a lot.
(From OE-Core rev: 057885ed6f22781960bce4e082e3aa96e126764c)
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 most common usage for buildhistory is with commits enabled so that
you actually collect history, rather than just keeping a snapshot of the
most recent build state, therefore default BUILDHISTORY_COMMIT to "1".
This really ought to have been the default in the beginning, I can't
really explain why it wasn't.
(From OE-Core rev: 8018a2349b7ad5ab27731c93a49603adf5f72fc2)
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>
Defeat building for mipsarchn32 because there is no corresponding
GOARCH. Neither "mips" nor "mips64" allows go-runtime to compile.
Existing mips32 code assumes the o32 ABI.
(From OE-Core rev: fe72090a30d1fc810de3dd07350e5e6afba745de)
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>
These variables are used to control the floating-point instructions emitted by
the go compiler for x86 architectures.
The default is '387' which disables the use of sse/sse2 instructions and is safe
to use on all x86 processors from the i486 onwards.
If TUNE_FEATURES contains a feature set which is known to support sse/sse2
instructions then they are set to 'sse2' to enable the use of these
instructions. This is suitable for most processors from Pentium 4 onwards.
Only the 'core2' and 'corei7' TUNE_FEATURES are defined in the oe-core layer and
are known to support ss2 instructions. Other layers may introduce additional
tunings which support sse2 instructions and for these layers, TARGET_GO386
or go_map_386 should be overridden as needed.
(From OE-Core rev: 7e96cf3c9850dc34d53af73a9ac22b1624994484)
Signed-off-by: Paul Barker <pbarker@toganlabs.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we inherit own-mirrors.bbclass, other settings of PREMIRRORS in
our project would have no effect.
This patch modifies the setting in own-mirrors.bbclass to allow other
settings of PREMIRRORS to still have effect.
(From OE-Core rev: a3e9e7a38b3d9caed49380ebc05651a97f613c7c)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the following commit, the archiver expanded RECIPE_SYSROOT
to preserve sysroot paths in configured mode:
...
commit aa2240657b015d46e9ba4bcb6264709a82313d83
Author: Ross Burton <ross.burton@intel.com>
Date: Tue Jun 6 15:23:18 2017 +0100
archiver: preserve sysroot paths in configured mode
...
In meta/conf/multilib.conf, it overrides the variables
of STAGING_DIR_HOST, STAGING_DIR_TARGET and RECIPE_SYSROOT
with "${WORKDIR}/${MLPREFIX}recipe-sysroot".
So the archiver should also expand STAGING_DIR_HOST and
STAGING_DIR_TARGET to preserve sysroot paths in configured mode for
multilib.
[YOCTO #11584]
(From OE-Core rev: b129af957a9fd8f603d1aebb9fca3adcb4e6b341)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Packages, which depend on users/groups created from other packages,
needs "shadow-native" as a build time dependency. So, add an exception
to the "shadow-native" from otherwise discarded native/cross tools
dependency.
Fixes [YOCTO #11960]
(From OE-Core rev: 979699b55214933e0f11727a2fb9bfda8a3a3870)
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>
BUILD_* flags can't be used as TARGET_* flags even for "cross" packages.
gcc-cross buils leaks config.log's through "gcc-stashed-builddir" and
TARGET_* flags to libgcc cross-build through "gcc/libgcc.mvars" file
on "gcc-stashed-builddir". This means that if BUILD_CFLAGS contains
host-specific flags like "-isystem/usr/include" libgcc build will
fail "do_qa_configure" and "do_package_qa" checks.
Remove host-related flags from TARGET_* flags for gcc-cross build.
(From OE-Core rev: 4b936cde58ca0a6f34092ce82640a02859110411)
Signed-off-by: Nikolay Merinov <n.merinov@inango-systems.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
check_app_exist function must support cases when "app" variable defined
as "progname --args". For example BUILD_CC="gcc -march=x86-64" must
pass sanity check.
(From OE-Core rev: 5193ebca0ca8864404fc750def0e738417d104c7)
Signed-off-by: Nikolay Merinov <n.merinov@inango-systems.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After 02457ef7f600ce954874e2d11e74b1c6daaa3bfc, PSEUDO for
postinst-useradd-* scripts get to use only one PSEUDO_LOCALSTATEDIR
which is set under recipes ${WORKDIR}.
When the those scripts are run in a clean build environment that
is built from the sstate (populate_sysroot_setscene run for
postinst-useradd-* providers), pseudo fails to run because it cannot
access the PSEUDO_LOCALSTATEDIR (recipe ${WORKDIR}s do not exist).
This triggers a sysroot staging error.
Previously, the PSEUDO_LOCALSTATEDIR setting in useradd.bbclass
worked because the RSS sstate/staging logic automagically processed
${STAGING_DIR_TARGET} in postinst-useradd-* scripts to point under
the sysroot being built.
The fix uses the same fixme processing by adding PSEUDO_LOCALSTATEDIR
variable to it. Furthermore, LOGFIFO is added to be able to use
the logging fifo of the recipe that actually runs postinst-useradd-*.
(From OE-Core rev: b28374cfad37db161b5ac5953b4a4638912f3f27)
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With RSS we need to ensure that when making a bmap image that the
python3 that we created is found via /usr/bin/env rather than the host
python3. Otherwise we're relying on the build host to have bmaptool
support installed.
(From OE-Core rev: a93c5869cb716cba5e05bbe4fc2e1c11adb9e30f)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the TUNE_FEATURES references from go_map_arch,
to avoid an unwanted variable dependency. Direct
comparisons of the architecture name are sufficient
for covering what Go currently supports, and using
TUNE_CCARGS_remove adequately handles the conflict
with the cgo-supplied flags for mips.
(From OE-Core rev: 1bc4c1d880096083d1891a74024fb225a6340b9b)
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>
The following commit:
[
commit 578c8205fd14c48c6d30ef2889d86f1b4aee060a
Author: Mikko Rapeli <mikko.rapeli@bmw.de>
Date: Thu Jun 22 16:23:14 2017 +0300
meta: Fix return value checks from subprocess.call()'s
Python function subprocess.call() returns the return value of the
executed process. If return values are not checked, errors may
go unnoticed and bad things can happen.
Change all callers of subprocess.call() which do not check for
the return value to use subprocess.check_call() which raises
CalledProcessError if the subprocess returns with non-zero value.
https://docs.python.org/2/library/subprocess.html#using-the-subprocess-module
All users of the function were found with:
$ git grep "subprocess\.call" | \
egrep -v 'if.*subprocess\.call|=\
+subprocess\.call|return.*subprocess\.call'
Tested similar patch on top of yocto jethro. Only compile tested
core-image-minimal on poky master branch.
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
]
Added return code checking to do_diffconfig. Although the change is
well intentioned, it isn't correct in this instance since 'diff' returns
'1' to indicate that there are differences in the files .. and not as
an error code.
subprocess.check_call() flags this as an error and the routine aborts.
We are already checking the inputs, and in fact already know there's a
diff in the files before we even make the call, so there's no need to
look for an error in this case.
Putting back subprocess.call() restores the routine to working order.
[YOCTO #12132]
(From OE-Core rev: ec48b8fd79181978f90b4b0ab00fbe78ddbd416e)
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>
Currently systemd-boot actually incorporates libgcc, since the
systemd-boot needs to be built with 64bit instructions it can not
use the x32 based libgcc.
Use the new override to ensure it gets overriden, linux-gnux32 could
not be used because x86-64 has higher priority.
(From OE-Core rev: 6046b9a3d76738c459ad76f5296e7b0a54c0b2e0)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Newer versions of gpg (at least 2.1.5 and 2.2.1) have issues when signing occurs in parallel
so (unfortunately) the signing must be done serially. Once the upstream problem is fixed,
this patch must be reverted, otherwise we loose all the intrinsic parallelism from
bitbake.
[YOCTO #12022]
(From OE-Core rev: 5301712f9735fcf8d3dec756772668de930e53fe)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Search made with the following regex: getVar ?\((.*), True\).
(From OE-Core rev: dbc0eaf478feb3f752ae22fd184984494fc85d0a)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the security_flags.inc file is included, gcc
will do PIE builds by default. These flags need
to be disabled for go packages that use cgo.
(From OE-Core rev: 5d84042852380fc88b9be8df0e4eeac612c2a6da)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Fix the regular expression in the mips test
* Flag as incompatible any mips32 tunes for n32 ABI
or soft-float, as go does not support them.
* Replace mips32r2 tune with mips32r1. Go only supports
mips32r1, which is a strict subset of r2. Adjusting
this tune is not ideal, but is hopefully a temporary
measure until more complete mips32 ISA coverage
arrives upstream.
[YOCTO #12108]
(From OE-Core rev: bdd20c296048937737da0f10bd1a3b63843c5bf4)
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't need a dependency on this variable changing, and having one
causes locked signature warnings during eSDK installation if you have
INITRAMFS_IMAGE_* set (since TOPDIR will always be different between
the eSDK and the environment in which it was built).
Relates to [YOCTO #12102].
(From OE-Core rev: 073610af04be326f9245ca91714526b390fb72cd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding distcc to an image, and having staticids enabled,
doesn't work as it causes a a superfluous 'distcc' group
being added using a conflicting GID, thus failing the
build:
| ERROR: distcc-3.2-r0 do_prepare_recipe_sysroot: distcc: groupadd command did not succeed.
Compared to other recipes, the distcc recipe only
specifies --gid for the primary group, and doesn't specify
--no-user-group, but when --gid is given, it doesn't make
sense to create a matching username-group in addition,
even if --no-user-group was not specified, and 'useradd'
actually complains if --gid and --user-group are given
both.
If only --gid is given, the current code in here
effectively behaves as if --user-group was specified,
taking the group-id of the username-group from the
--gid parameter. This causes the error above, as we try
to add a new group (distcc) with an existing group-id
(nogroup).
This is contrary to the comment in this file just above,
contrary to what useradd can do, contrary to behaviour
without the useradd-staticids bbclass, and non-intuitive.
Change the code such that a username-group is only created
- if a primary group using --gid was not specified, or
- if --no-user-group was not specified
To be in line with useradd, if gid is not given, and
--no-user-group is given, we add the user to the group
'users', which mimics useradd's behaviour.
(From OE-Core rev: fc3a86ae68919cec72c1a8ae0f9ba1f98ae13f0d)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The staging changes were very verbose in their logging and whilst this is useful
when staging issues occur, those thankfully seem rare now and we can tune down
the logging to a sane level. This improves the readability of error messages from
functions that fail.
The code is still verbose when its replacing things in the sysroot.
(From OE-Core rev: a22d44c6bef7ea1be90aeb32ccd7502d3135a266)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alternative solution to original commit
60c90398580998b2379bb438f0f75b29285135a5 ("u-boot: fix extlinux
creation race")
(Untested)
(From OE-Core rev: e44b72ab45c757cc83c7856c118588f1af299790)
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>
The are use cases where the Device Tree appended to the kernel is
convinient, so we generate the bundle concatenating the kernel (and
potentionally the initramfs) and the Device Tree binaries.
To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
(From OE-Core rev: f044567326988e84e5d72040e9387c3240836ddb)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
MIPS generates vmlinuz.bin when compression in the kernel build is
enabled, including any necessary objcopy so we can leverage that
and skip our manual invocation of objcopy here. We just have to
put the file into the right place for the rest of the build to
find it.
(From OE-Core rev: 00bc7682473c2558d72ba42c182f8e3bd445f8af)
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>
This is the remaining local change to a fix similar to
commit e0b4f018d1c2 ("kernel-uimage.bbclass: Fix up
generation of uImage from vmlinux"):
Make awk exit on match to save a few CPU cycles so as
to make this similar to kernel-fitimage.bbclass
(From OE-Core rev: 614e8be7a89a2f2113fa40b11e7a05b9e8155f6a)
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>
- vmlinux is located in ${B}, not ${S}.
- parsing of nm output got broken completely in commit
b406a89935f148779569fa3770776e009dd51f13 ("kernel-fitimage: add
initramfs support"), commit ec755d2524
in yocto
While at it, make awk exit on match to save a few CPU cycles.
(From OE-Core rev: 9d2ec9c046c4a9c6a842d28133d40639f5a65297)
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>
We can't build fitImages for MIPS any more:
| Error: fit-image.its:21.27-28 syntax error
| FATAL ERROR: Unable to parse input tree
| uboot-mkimage: Can't read arch/mips/boot/fitImage.tmp: Invalid argument
Since commit cd2ed7f80b555add07795cc0cbaee866e6c193a3
("kernel-fitimage: dtb sections named by their filenames
and one config section for each dtb"), commit
1ec405ef5d in yocto, dtb
sections are named by the DTB filename, but the filename
can legally be in a subdirectory below
arch/$arch/boot/dts/, and on MIPS all DTBs are actually
in a subdirectory.
If so, mkimage fails with the above error message.
Unbreak this by replacing the offending character
(directory separator /)
(From OE-Core rev: 335fc50cf54e47db4e3d5c35a9846484faf0270f)
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>
