If we're building a SDK and we're using glibc so may be installing locales,
add a build-dependency on natiesdk-glibc-locale so the locales we need will
exist.
(From OE-Core rev: 8d6869a0a89d8cf3c6e57723fab2750ba2c885db)
(From OE-Core rev: 19fce2a6f76227de88e267f65f0e124645ea280e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts
using glibc earlier than 2.27 won't be able to find any locales, so bitbake
won't start and Python can't use UTF-8.
So by default install all locales into the SDK. Special-case Extensible SDKs by
installing no locales as they ship glibc in a buildtools, and that will have the
locales.
Locale installation requires cross-localedef, so add that to DEPENDS.
Also remove the explicit en_US addition in buildtools-tarball as it is now
redundant.
(From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1)
(From OE-Core rev: af9eb2ef36cb5bfd87ea61ff3390949810097c9b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If glibc is newer on the host than in uninative, the failure mode is
pretty nasty for clusters where the sstate is shared, including the Yocto
Project autobuilder.
This check aborts the use of uninative in such scenarios where a newer
glibc version appears and avoids corruption of sstate caches.
We use ldd to check the glibc version since that is included in libc-bin
(or equivalent) which locales use so it should always be present.
(From OE-Core rev: 8147911a951c7b0508f9c2aef93480d65b4362c0)
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: 1054965a2d44df2617127c0c47e34adc62c1bf4d)
(From OE-Core rev: 93aaa0cf4f792f76d76f9f79be7fbbe59d01e910)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-Core changes the architecture independent RPM packages to use
"noarch" instead of "all". This change has been included in the commit
below:
,----
| commit 341810aff923ace6b1cc1e15e19383c4f8773b51
| Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
| Date: Mon Jan 9 16:37:28 2017 +0200
|
| package_rpm.bbclass: make architecture-independent .rpm packages
| "noarch" instead of "all"
|
| Too many places in dnf/rpm4 stack make that assumption; let's not
| fight against it.
|
| Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
`----
This is causing problems with machines that has "all" inside the
machine name.
Reported-by: Alexandru Palalau <ioan-alexandru.palalau@nxp.com>
(From OE-Core rev: 445ac7b3198885c67622b4303b010a85c3e3e61e)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 3e4ddeab65d4d2e4aaf03d442c2a1a8c7a2ce8a2)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'wic' image may use files which has been deployed (e.g in
do_deploy) for some partitions that may need to be copied in a
specific partition or filesystem (e.g a bootloader).
When using 'bitbake <image> -c image_wic', from a clean build, the
contents of do_deploy must also be available so we need to ensure all
do_deploy of the image dependencies has been complete.
Reported-by: Fabio Berton <fabio.berton@ossystems.com.br>
(From OE-Core rev: 5e2a541f80e0f69ae00dfd96e50d2792750730cd)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f387c28640cbb209b8a8ed5734b21c754d9f7663)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix build when PIE is turned on. It tries to build
.so file using -pie and -shared flags together because
its doing compile and link in same step CFLAGS and LDFLAGS
are combined and does not work, ending in errors e.g.
| /mnt/a/oe/build/tmp/work/cortexa7t2hf-neon-vfpv4-bec-linux-musleabi/python-pygpgme/0.3-r0/recipe-sysroot/usr/l
ib/Scrt1.o: In function `_start_c':
| /usr/src/debug/musl/1.1.16+gitAUTOINC+179766aa2e-r0/git/crt/crt1.c:17: undefined reference to `main'
| collect2: error: ld returned 1 exit status
This error while cryptic is due to the fact that we are
building a shared library but also pass -pie flag to the link
step after specify LDHSARED ( which is -shared linker flags )
we can not use -pie when doing shared libs. This is true for all the python
modules inheriting setup tools
Disable the pie flags thusly for all modules using setuptools since
this setting is done in setuptools makefiles which are then used
during module compiles
Backport notes:
In master, this commit is reverted in master in favor of using GCCPIE =
"--enable-default-pie" in security_flags.inc. However, backporting that change
introduces many merge conflicts and will be a serious maintenance issue, so I
think it's safest to just backport this small change, which fixes build failures
in python-cffi and likely other recipes.
For completeness, this is the list of commits in OE-core master that will
supersede this change:
- 1c7e195c94764d680a12a49b870f04cd58860f81
"gcc: Introduce a knob to configure gcc to default to PIE"
- e93765ffb5718b0fce84f0b8123963176dea95e4
"security_flags.inc: Delete pinnings for SECURITY_NO_PIE_CFLAGS"
- fcfe6d4ab4460f8358e13023022a5e909941ca93
distutils,setuptools: Delete use of SECURITY_NO_PIE_CFLAGS
(From OE-Core rev: 739c69e8eb464d184ef652e7e7a4d4b234a5b5f9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current conflicting use of SDKDEPLOYDIR causes a race between do_populate_sdk
and do_populate_sdk_ext potentially causing the SDK to either go missing or the
build to fail.
(From OE-Core rev: 2c61e60cc5fe635774e88c1e34646a32a9ad918b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
this is needed for the updated linux-firmware as it needs this INSANE_SKIP support
(From OE-Core rev: 618093c6b7c919f25094f56b82610bee7c97f99f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 604939186cc08ab0429ebe00f3e32661847f0cf0)
Adjusted for pyro context
Signed-off-by: Armin Kuster <akuster808@gmail.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: 764b93cac374a55c31c86627f13270db874cdbdb)
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 6c52b2db3a7c07a7bf448ba2c9db89a7734e4b4b)
(From OE-Core rev: 39fcca60f64bc6afc57943881bec5641820d3d7d)
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>
do_ar_configured alters WORKDIR but also expects to be able to run do_configure,
so forcibly expand the paths to the sysroots as otherwise they'll point to a
non-existant directory in the temporary WORKDIR.
[ YOCTO #11584 ]
(From OE-Core rev: aa2240657b015d46e9ba4bcb6264709a82313d83)
(From OE-Core rev: cd5e6172525c7618e93d8255a1d6102a24496f53)
(From OE-Core rev: 60f2c790d5e83c1a55d7a40b32a7cef6a5a5eab6)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Avoid archiving source for glibc-locale as its tasks
do_fetch do_unpack and do_patch have already been deleted.
(From OE-Core rev: 50ed224ebc8d88a900febdc78013fa0c791d71cf)
(From OE-Core rev: 32a332a54e8b857668eb60e36152b8d2ecec15bf)
(From OE-Core rev: 23d55b31272568ce7d8b4549381c31512ff93b6a)
Signed-off-by: Zhenbo Gao <zhenbo.gao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_unpack_and_patch was not correctly run until recently
("archiver.bbclass: various fixes for original+diff mode") but
with the fix applied, the errors we get indicate the function
is not adapted to work with recipe specific sysroots.
do_unpack_and_patch sets WORKDIR to ARCHIVER_WORKDIR which
affects all path settings relative to WORKDIR, inluding the paths
to recipes' sysroots. IOW, when do_unpack and do_patch are run, they
cannot find the necessary native tools and files located in the
sysroot (e.g., quiltrc) because the paths point to ARCHIVER_WORKDIR.
Adapt do_unpack_and_patch to RSS by restoring the original
STAGING_DIR_NATIVE after WORKDIR is changed to ARCHIVER_WORKDIR.
(From OE-Core rev: db7d2cc5a4df3c2077ba874c7ae395c73fd9ed13)
(From OE-Core rev: 7c0e3c5fa39e7ed3eedee8bac206476f70d1f422)
(From OE-Core rev: adb5234ac9c96f29336397552176ab5086772069)
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>
Error:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR: matchbox-desktop-2.1-r0 do_ar_original: Can not determine archive names
for original source because 'name' URL parameter is unset in more than one URL.
Add it to at least one of these: git://git.yoctoproject.org/matchbox-desktop-2
file://vfolders/%2A
ERROR: matchbox-desktop-2.1-r0 do_ar_original: Function failed: do_ar_original
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function do_ar_original, when recipes have more than one source, it added the
"name" URL parameter as suffix to identify the created tarball.
But the URL type "file://" that we always used to represent a series of patches,
it didn't have "name" parameter, so it failed.
So set "name" to the folder name to identify the created tarball, for example:
In matchbox-desktop bb file, the SRC_URI contains:
file://vfloders/*
We set "name" to "vfolders" to identify the created tarball.
In connman-gnome bb file, the SRC_URI contains:
file://images/*
We set "name" to "images" to identify the created tarball.
(From OE-Core rev: 0af636c635391b30c987dedeffe597ef4f8a1ed8)
(From OE-Core rev: 9dd945d083ee742dcb75d24d4be40468121008a6)
(From OE-Core rev: 113de7ab1e61997147b4b292b7de162d44296d59)
Signed-off-by: Dengke Du <dengke.du@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding or removing archiver.bbclass from a build configuration causes
rebuilds of linux-yocto-based kernels because of the
do_kernel_configme->do_unpack_and_patch task dependency.
This particular dependency can be ignored for the do_kernel_configme
sstate signature calculcation. Idea for the fix from Richard Purdie.
Note that building the kernel and adding archiver.bbclass later to
archive sources leads to do_unpack_and_patch running after
do_kernel_configme (because that already ran in the first build),
which might be problematic. This is independent of the change here.
The use case in YOCTO #11441 is to removed archiver.bbclass between a
production build with archiving enabled and builds via oe-selftests
without archiving. That direction is fine.
Fixes: YOCTO #11441
(From OE-Core rev: fed0ed82928e6a7846fbad233ac657bd17bcefc7)
(From OE-Core rev: 201c634946d07c8d0ab6d486e5031b4479eb6707)
(From OE-Core rev: 81a6623592c3c496b16f0dc2c0ad04c16b0baf29)
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>
The diff.gz gets created in do_unpack_and_patch, but
do_deploy_archives did not depend on it, so there was a race
condition. For example, "bitbake linux-intel:do_deploy_archives"
without a prior "bitbake linux-intel:do_kernel_configme" did not
deploy the diff.gz.
When do_unpack_and_patch ran first, it failed because the output
directory didn't exist yet and the error was not detected because the
result of the diff command wasn't checked.
Changing the current working directory in create_diff_gz() without
returning to the original directory caused warnings like this:
WARNING: linux-intel-... do_unpack_and_patch: Task do_unpack_and_patch changed cwd to .../tmp-glibc/work-shared/intel-corei7-64
(From OE-Core rev: 18aac553ca35049c80b6cc82ff0e69ce8a7a03a9)
(From OE-Core rev: 58ae2be68c2eb4153c09386eebefe9b57400c777)
(From OE-Core rev: 497795c5a9db8ddb29302780a94eabf6f9b05c9d)
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>
Previously, do_ar_recipe ran again unnecessarily when adding or
removing classes like buildhistory.bbclass, because that changes the
BBINCLUDED variable which do_ar_recipe uses to find .bbappend files.
This is both extra work and also sometimes triggered "basehash
changed" errors (seen under oe-selftest, which adds machine.inc and
bblayers.inc) because BBINCLUDED is special and does not cause
the basehash to be recalculated.
The file *content* already was not considered in the task signature,
instead relying indirectly on PF (which includes the revision assigned
by a PR server) to ensure that a new versioned source archive gets
created each time there is a rebuild.
Therefore it makes sense to use the same mechanism and also ignore the
file *list*, i.e. exclude BBINCLUDED from the task signature.
(From OE-Core rev: 9666f0e0b02efc14226c77497fd38f79fc372f98)
(From OE-Core rev: f560bfe15d283c59094a0f7987fad10baad053b4)
(From OE-Core rev: 62fbbf99de7b427d95f51d63039ab5a803209904)
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>
The recipe name needs to be escaped when using it in a regular expression so
that and special characters are treated literally
(From OE-Core rev: 53c8cceb744adda1bf899d62071d11b20a5dea98)
(From OE-Core rev: 5818fa4ddb1473b7d951ccb24f9953a011082312)
(From OE-Core rev: ed2d0781d3e991a7e0eb4bf7a04a9e91cd8793be)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.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 master rev: 073610af04be326f9245ca91714526b390fb72cd)
(From OE-Core rev: 94a9f9a7dc5a736b7986b889895c736f02110715)
(From OE-Core rev: 8bf158857d7c597c58efc4023bdd9c2785d43ad3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original purpose of this code snippet was to repackage initramfs
bundled kernel images before do_image_complete, to be able to be
included by rootfs, but it's not going to achieve that since the
initramfs bundled kernel images are not even installed to ${D}/boot
after commit a49569e3a7534779bbe3f01a0647fd076c95798d:
[ kernel.bbclass: do not copy bundled initramfs to /boot ]
So there is not a initramfs bundled kernel package at all, we should
drop the code, because it is leading kernel do_initramfs_bundle
unnecessarily rerun and it's very time consuming and hence is impacting
the performance a lot.
(From OE-Core master rev: eca501aeb4f2cc9255fabab14c68f6910367aaf9)
(From OE-Core rev: 22fd010b71b6ce79f3ede31e4e7da9dbc72de70e)
(From OE-Core rev: f549338b0ed4d53dedac84c86e70ea9ffd12a17e)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible for non-CPAN recipes to contain perl modules. These perl
modules must reside in the versioned perl library directory in order to
work in normal circumstances.. Export this logic to a separate class so
that it can be reused without the rest of the cpan logic.
Without this, dpkg will not export its perl code to the correct location
and will not be found by utilities that expect to use it.
(From OE-Core rev: 6907280335dd47f2fd3a3f4cf809357c3caff65d)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For uninative to work, it relies on it being updated to new versions as
newer glibcs are built. This means the uninative generated by the current
build may not be as recent as the uninative that is being downloaded by
uninative.bbclass.
If this occurs, we can get symbol mismatch errors.
Ultimately, the sstate and the uninative versions need to match so we
should use the same tarball as uninative.bbclass is using, not the one
we built.
[YOCTO #12405]
(From OE-Core rev: 1bde969058f7e832db0e7eb9c6f7ef00f027628c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the introduction of chaining compression/conversion support we can
convert the old image_types_uboot.bbclass code that did a hand-chaining
of a set of ${filesystem}.${compression} into generic and arbitrary
support to sign whatever the user wants to sign for their image.
This, for the record, does remove setting a valid compression type in
the record in favour of just saying none. This is not a generally
useful feature in U-Boot and I believe being versatile in terms of being
able to pass in arbitrary compressions is more important.
(From OE-Core rev: 979ff606d8c4c6f66c6dc533a92212f18708089e)
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>
Signed-off-by: Armin Kuster <akuster808@gmail.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: b1843e60ebe534243b49f3685540fa5ea49d5f35)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fc3a86ae68919cec72c1a8ae0f9ba1f98ae13f0d)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On MIPS, the compressed kernel image target is vmlinuz.bin
(From OE-Core rev: ed459bc971697fdd46e5204f625cde7afcdef6eb)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 74d97569aa4e0f82e094a539dec302076103affa)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.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: 3db4004b2982a297a02ebeb6b0cb90cebdb44a0a)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 00bc7682473c2558d72ba42c182f8e3bd445f8af)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.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: d60b3d02949ba318e30627131fd38f74c74cf590)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 614e8be7a89a2f2113fa40b11e7a05b9e8155f6a)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.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: 1353892f3a130bcfa4e9c5b36b3ed7eb4a2c872d)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 9d2ec9c046c4a9c6a842d28133d40639f5a65297)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.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: feb78cb536a5e5cc9f1c36014b1a1ae1c147f45c)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 335fc50cf54e47db4e3d5c35a9846484faf0270f)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix up the generation of uImage from vmlinux when KEEPUIMAGE != 'yes'.
This fixes up the working directory that do_uboot_mkimage is run from,
such that it is run from the ${B} directory to access built artefacts.
Simplify the logic in the task so that the parse step either adds the
task or not if the conditions are met. This reduces the need for the
task to run in cases when it is not used. The task is also changed to
depend on the kernel_link_images task as arch/<arch>/boot/* is not
available until after kernel_link_images in certain cases (e.g.
vmlinux/uImage only KERNEL_IMAGETYPES).
Fix up the use of ${S}/vmlinux when pulling the entry symbols
address so that it accesses the vmlinux in ${B}.
(From OE-Core rev: 60f0e4b18c7d77d7be2b22573b7d0c7ad3d0832f)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit e0b4f018d1c2a65e66c81e5be1da8894e9a6c132)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the changes introduced in ae9102bda3
("copyleft_filter.bbclass: Allow to filter on name"), it is
impossible to filter on the recipe type, all recipes are
treated as though they should be included if the license
matches, irrespective of the COPYLEFT_RECIPE_TYPES
variable.
Fix this.
(From OE-Core rev: 23b520c42e93e47e3a19037877281af673144b31)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit e612dfa520c7d7ecf58006e82189be601204f38d)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With these changes it is possible to have a .bbappend that
- sets SYSCONFDIR to some persistent storage
- modifies SYSCONFDIR/sshd_config to use ssh host keys from
the (writable) sysconfdir
(From OE-Core rev: 79c7c8342859306750f0af17210a183fdc543caf)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Reviewed-by: Stephane Ayotte <sayotte@tycoint.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 106b59d9f96f70d133fa1421091ad280d27a5b6a)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Back in the dark days before recipe-specific-sysroots the paths being passed in
this manual construction of the pseudo environment made sense, but now they're
incorrect and result in pseudo writing to two different databases during a
single build. The result is that pseudo doesn't follow changes to /etc/passwd
in the sysroot, and warns in the logs.
Remove the PSEUDO_LOCALSTATEDIR assignment and inherit the correct assignment in
FAKEROOTENV.
(From OE-Core rev: 02457ef7f600ce954874e2d11e74b1c6daaa3bfc)
(From OE-Core rev: e8112536055e75dff43369395a6cf6ba44ba8db7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous logic applied a regex to TUNE_FEATURES which could
set the GOARM value to 7 incorrectly, for example when dealing
with an arm1176 core. Simplify to check for the presence of
"armv7" instead. At the same time add a check for "armv6" and
set GOARM to 6 in that case.
(From OE-Core rev: 93dd2f9f3edf0584f9e806c629611d645dd72dbf)
Signed-off-by: Will Newton <willn@resin.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When selected multiple subimages a similar error could happend:
Variable do_image_cpio[subimages] value changed \
from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot'
To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'.
This garantee that 'CONVERSION_CMD_xxx' are always written in tha same
order and consequently 'do_image_cpio' have the same hash.
(From OE-Core rev: 271f1a5f65b8685a1e3645026876251122ef3974)
(From OE-Core rev: 404a04a862a71a5a0fb1c20b6bc9fc9c8b2bb98c)
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For URIs with the npm:// transport but with no other slash in it, the
common MIRRORS and PREMIRRORS pattern of npm://.*/.* fails to match.
Make the last slash in the pattern optional in the mirros.bbclass and
own-mirrors.bbclass classes.
Many URIs with the npm:// transport have no slash after the host part:
npm://registry.npmjs.org;name=foo;version=0.1.2
This means that MIRRORS and PREMIRRORS containing entries like the
first one will not match these URIs:
npm://.*/.* # fails to match
npm://.*/?.* # matches this and URIs with path components
For normal regular expressions, a pattern like 'npm://.*(/.*)?' would
probably be preferred, but that won't work here: the pattern gets split
into the substrings 'npm', '.*(' and '/.*)?', which are not valid
regular expressions individually.
(From OE-Core rev: 0d1e2b4507af28fc451b8fa94130a39ac342637d)
(From OE-Core rev: 1f5675a43e1781635fee15cc3674143c195da169)
Signed-off-by: Olaf Mandel <o.mandel@menlosystems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_rootfs log contains a number of unsatisfied package
recommendations. At the moment those are only visible when
reviewing the rootfs log.
This patch adds an extra check to surface any unsatisfied
recommendation as WARNINGS to the build output.
Enable this check with:
ROOTFS_POSTPROCESS_COMMAND += "rootfs_log_check_recommends;"
(From OE-Core rev: 9d049bf7941f30e35c51775684559e95185fba96)
(From OE-Core rev: 514cadd28d05f5060b2538ef9b2920370c22bf73)
Signed-off-by: Jose Alarcon <jose.alarcon@ge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In images built with pam in DISTRO_FEATURES, we end up with dangling symlinks
if su is not packaged into image
$ ls /mnt/a/oe/build/tmp/work/raspberrypi3-bec-linux-gnueabi/core-image-minimal/1.0-r0/rootfs/etc/pam.d/su-l -l
lrwxrwxrwx 1 kraj users 2 Aug 9 07:56 /mnt/a/oe/build/tmp/work/raspberrypi3-bec-linux-gnueabi/core-image-minimal/1.0-r0/rootfs/etc/pam.d/su-l -> su
This causes image do_rootfs to fail
| sed: can't read /mnt/a/oe/build/tmp/work/raspberrypi3-bec-linux-gnueabi/core-image-minimal/1.0-r0/rootfs/etc/pam.d/s
u-l: No such file or directory
| WARNING: /mnt/a/oe/build/tmp/work/raspberrypi3-bec-linux-gnueabi/core-image-minimal/1.0-r0/temp/run.ssh_allow_empty_
password.19238:1 exit 2 from 'sed -i 's/nullok_secure/nullok/' /mnt/a/oe/build/tmp/work/raspberrypi3-bec-linux-gnueabi
/core-image-minimal/1.0-r0/rootfs/etc/pam.d/*'
Therefore we need to filter out dangling symlinks before sed'ing
things out
(From OE-Core rev: b92105e5a085c8cd3c650579644922ed97163e73)
(From OE-Core rev: ed1aaf24bfd4a09132c7e0247c460102ec85254d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As we're not using them and they're getting in the way of
reproducibility.
[YOCTO #11718]
(From OE-Core rev: 1bd3ed18379c330c1c733dc9f043dbbe8aa0d254)
(From OE-Core rev: 5c8f831c71932e2abebd72f8be1ec95e1b6c3ab7)
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>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPM's default is single-threaded gz; the change greatly helps with
both buildtimes (when there is a small number of large-sized packages)
and disk space taken by resulting rpms.
(From OE-Core rev: f108c4d09926bd28e7a57b665fc8cb5373827780)
(From OE-Core rev: fd329fdc6374ebde3f5ab171dbe76bf5cec6771d)
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>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed for packages like linux-firmware which have a
legitimate reason for it. Oe-core has a separate package_qa
test for this situation, so any accidental inclusions of such
binaries will still be caught.
[YOCTO #11329]
(From OE-Core rev: 6aaff392d703183d19192e2d171e10a92f259c65)
(From OE-Core rev: 35059f271964da1f8112a45f19875b59fb9cd02f)
Signed-off-by: Ng Wei Tee <wei.tee.ng@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a logic error in the dependency cleanup code which meant
it would remove dependencies which other tasks still depended upon.
Fix the path names so the comparisions work as intended.
This fixes dependencies accidentally disappearing from sysroots
under certain reconfiguration situations.
(From OE-Core rev: 1634fe5148b3501f2c1b75cf7fb704a2ef60424e)
(From OE-Core rev: 3969c068bc9557b405a5ad61c10c402ec93bd932)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a6631eed6fc70b305e769998d6f22f345e37decc)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently items are added to the sysroot, the obsolete items are removed. If
a change such as pkgconfig -> pkgconf is made, this leads to conflicts of
overlapping files in the sysroot.
In order to better support this, handle removing items before adding them.
This requires some minor refactoring to construct the installed list
before the main function loop, otherwise there are no changes in this
patch other than reordering the operations.
(From OE-Core rev: add4f107c151d32d9ea914bb0b93c3d3c17c776c)
(From OE-Core rev: 970d4df7336e5102ac61e66689e977fb2e41a1aa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5b45fe40db81292dd6bb57b210d1e4ba32e65e9e)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently a task could remove a dependency needed by another task leading
to build failures, often due to missing dependencies (e.g. dynamic libraries
not being found). This was often seen for all-arch recipes in package_write_rpm.
When removing a dependency, first check that no other task active for the
recipe has that same dependency.
(From OE-Core rev: ff3617cc2cd5618f48a25aa4e3b2014430fcbe23)
(From OE-Core rev: 67438ac91a40429affc952ad1d7e92c763f52bab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3de078642925e720c2fca5b89cd3abb8b29d2439)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In OE-Core commit a48fea275b, a check on
the value of a "sha256" parameter was added, however there was no
mention of this in the commit message and no corresponding code to
actually verify the checksum as sha256 was added along with it either,
so there's no point in getting the value. Additionally it was assuming
that a sha256 value would be present without checking first, with the
result that if you leave out the md5 value in a recipe intentionally in
order to get it to tell you the correct value on the next build, you got
a traceback instead of the appropriate error containing the information.
Drop this entirely - if we want to implement this we need to do it
properly.
(From OE-Core rev: e9eaa7d15fe7ab643ab19556dab84051f8f1974e)
(From OE-Core rev: fcedfce43adad8659a1376bb28b1ed41e621dd53)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the transition to dnf and rpm4, the functionality to
automatically make RPM determine dependencies was lost.
Before the transition, an OE specific tool called rpmdeps-oecore had
been added to the rpm suit. It was based on the rpmdeps tool that is
part of rpm. For each file specified on its command line, it would
output the provides and requires that RPM could determine.
During the transition to rpm4, rpmdeps-oecore was replaced with the
standard rpmdeps. However, what no one noticed was that unless rpmdeps
is given options, e.g., -P or -R, to tell it what it should output, it
will not output anything. Thus, it would do all the work to determine
the requirements, but would keep silent about it. And since no output
from rpmdeps is expected unless there are requirements, there were no
warnings indicating that everything was not working as expected.
Porting the old rpmdeps-oecore to work with rpm4 is not really
possible since it relied on being able to access internals of RPM that
are no longer available. However, it turned out that rpmdeps had a
debug option, --rpmfcdebug, that would output exactly the information
that we need, albeit in a different format and to stderr. To make this
usable, rpmdeps has now received a new option, --alldeps, which sends
the information we need to stdout.
Since enabling this may cause packages to break, it is required that
ENABLE_RPM_FILEDEPS_FOR_PYRO is set to "1" to activate it for Pyro.
The name of this variable has been chosen as to indicate that it only
affects Pyro (since releases before and after Pyro has it enabled by
default).
(From OE-Core rev: 1009498f23ad319825c00ba60a4693d15aada553)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ross Burton
Richard Purdie
Otavio Salvador
Khem Raj
Mikko Ylinen
Nikolay Merinov
Zhenbo Gao
Dengke Du
Patrick Ohly
Joshua Watt
Paul Eggleton
Ming Liu
Tom Rini
André Draszik
Nathan Rossi
Will Newton
Gerson Fernando Budke
Olaf Mandel
Jose Alarcon
Alexander Kanavin
Ng Wei Tee
Peter Kjellerstedt