The bitbake fetcher now enforces that a commit is contained by a branch,
so this code can be dropped from do_validate_branches.
(From OE-Core rev: 9e473d348d9e0db34e03446065c6c48d36964e1e)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than attempting to condition the entire tree to machine SRCREV (since
we don't know what branch will be built), we can instead wait until patching
has completed and then confirm that we are indeed building a decendant of the
specified SRCREV. The result is a much simpler check, and no mangling of the
tree.
(From OE-Core rev: 97075af9e9a691276cd417f1181ca73223f52d1c)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Parsing the output of git show is error prone, since it changes based on
the type of issue with bad comit IDs. Since the output is no longer used
in the case of a valid ref, we can switch to git-cat-file and simply
check the return code.
(From OE-Core rev: 228c05013fe691321ec00467d8d0c0bb64dd175c)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_validate_branches checks to ensure that a valid machine SRCREV was
set. A test against an empty SRCREV is done in two separate locations,
we only need one, since the first check immediately returns and the
second check never hits.
At the same time, we can stop referring to the same commit hash by
3 different names. Instead we assign to a local variable at the
top of the routine, and refer to it at all times.
(From OE-Core rev: 05508339882c7cc1fe3f1f67f72314fdcab979b7)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe will sometimes be rebuilt unnecessarily if it adds users via
useradd and the pseudo-native task has not been populated.
This patch adds the correct dependency.
(From OE-Core rev: 2bb244e9e18124b3b86195e0e10b2ebd40cd4f81)
Signed-off-by: Jate Sujjavanich <jatedev@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This quite coincidentally invalidates the sstate for do_package which
is needed due to the correction of oe.utils.multiprocess_exec().
(From OE-Core rev: 9972f0686794a01582fd1a15889dcbd89bc5cf72)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages have additional configuration options that are currently
not accessible through cpan_build.bbclass. Similar to cpan.bbclass, add
EXTRA_CPAN_BUILD_FLAGS to pass the optional parameters to perl Build.PL.
(From OE-Core rev: bef6c3f4ebcd19ea3845aab27a165c370102b62c)
Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently this variable isn't passed through the magic rename
mangling. This means that if you try adding "nativesdk-eglibc"
to an image directly, you can't since the package is renamed
by debian.bbclass and nothing sees the renaming.
This is annoying since I wanted to exactly that. This code
change passes it through the standard renaming function, the
tricky part is that we have to set PKGDATA_DIR to point to
the correct sysroot during the call. We create a copy of the
datastore for the purposes of the call to do this.
(From OE-Core rev: d2fbc55d6863a767e69092bac686c02c3ec34650)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- There might be a space between "#!" and "/pat/to/usr/bin/perl", e.g.:
"#! /usr/bin/perl", now also matches it.
- There might be the lines like the following in the body:
eval 'exec /path/to/usr/bin/perl-native/perl -S $0 ${1+"$@"}'
Now we only check "#! */path/to/usr/bin/perl" to make sure it is a
perl script, but match and fix the lines in both header and body.
(From OE-Core rev: 0d2e2ac137465885a1d55103010ccfdec579f1ce)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some cases we do either need to add extra sstate manipulation
functions, or change the existing modification functions. This patch
parametrises them to SSTATECREATEFUNCS and SSTATEPOSTUNPACKFUNCS and
abstracts the "hardcoded path" functions into separate functions using
these new variables.
We may use this new functionality to improve binary relocating using
patchelf for example, this at least lets us have the hooks to be able to
experiment.
(From OE-Core rev: 9d659c6f20fa4a141b491c62a3ef0dfb1f896d9c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to use hasFeature and hasPackage methods in sdk test modules, we need specific fields to be set in the TestContext object.
Adding pkgmanifest, imagefeatures and distrofeatures to the TestContext.
(From OE-Core rev: cd342b399b2d78724032cdd7042968d3238cd548)
Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to the way BSP images have rootfs a manifest, the toolchain now also has a manifest file created alongside the sdk image.
(From OE-Core rev: 3d42fd1f050a1382b15c3c4d59fd02d0ed7091b2)
Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When archiving original source, insert the first 10
characters of srcrev, after stripping off any
AUTOINC+, into the filename for tarfiles created
from directories.
(From OE-Core rev: 36726049a6a452f85d7cc849d57ad6af05d6d3ea)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In cases where we override variables e.g PACKAGE_ARCH
conditionally and use a MACHINEOVERRIDE to qualify the
override like
PACKAGE_ARCH_<MACHINE> = "some target PACKAGE_ARCH"
This would also be effective if this recipe is
BBEXTENDED to native or nativesdk which is undesired
This particular issue will cause wrong sysroot to be
used for nativesdk case since PACKAGE_ARCH would have
been modified and eventually changing value of
STAGING_DIR_TARGET which we use as --sysroot option
to cross and cross-canadian built SDK gcc
(From OE-Core rev: 6907da7eb44dca812dbb9e214357ee96e9ff738a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Use clearer variable names
- Use variable unpacking to reference elements by name rather than index
- Sacrifice a small amount of time (iterate over protocols twice per entry
rather than once) for clarity: use readable generator expressions with any()
rather than maintaining state.
(From OE-Core rev: 9d31e1e6ce07991fe360e67295311e62a55603af)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It doesn't really make sense to run the remapping code on these
variables. If specific renaming is needed, it should be applied
manually. This means that the debian RPROVIDES of the original package
name can be preserved. There was also a bug report about this on the
OE-Core mailing list recently where someone else ran into this problem
too.
(From OE-Core rev: a0cd18ff5405b63b8296b8ef1fc2a488b906f576)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For package groups, use the original package names and don't use the
remapped (e.g. debian) naming.
(From OE-Core rev: afde71e8784144f05cebb0bdeeff6b3184819362)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently its hard for a packagegroup recipe to depend on something who's name
can change unpredictably. We therefore add in RPROVIDES for the original
package name so that these are also available to use as dependencies.
(From OE-Core rev: 3409c4379559afbb1d1d29045582995147a33bbc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we want to start including this class conditionally, detect cases
where packagegroup files use the old ordering and inform the user they
need to update this.
(From OE-Core rev: 30aaada4b79fc1acad5fdaba98071b63c52b9e05)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the allarch inherit conditional on PACKAGE_ARCH being left as
all. The one downside to this approach is that recipes need to set
PACKAGE_ARCH *before* inheriting the class in order to avoid the inherit.
The advantage is that we could start to detect the use of the
allarch inherit in the sstatesig code for improved task checksums.
(From OE-Core rev: 9c826962ec8fa45c2b035427442b90a41517144e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check the format of MIRRORS, PREMIRRORS and SSTATE_MIRRORS:
* Each mirror shoudl contain two memebers.
* The local "file://" url must use absolute path (file:///).
* The protocol must in protocols list.
(From OE-Core rev: c8c213bb25b137cf70ba8ce9a45e60065d926735)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- Remove an unused line
- Remove unneeded code after d.getVar(), we don't need the "or ''" after
d.getVar() unless we need a string.
- typo: PREMIRROS -> PREMIRRORS.
(From OE-Core rev: 7849e50107a27b0ff2aaac47480ac1a0a79533dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The DEBIAN_NAMES feature renames some of the libc packages to
"libc6*" names --but only some. A previous patch added the -dbg
package. However, this doesn't cover other packages (such as
the -doc package), and it didn't take multilibs into account.
(From OE-Core rev: 64362a8f7ad7534515a9448445606581f3c572f6)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Jeff Polk <jeff.polk@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Might as well move this default to the class which uses it allowing
for easier reading/understanding of the class.
(From OE-Core rev: 177aec177306e68bcd822dee6b29a7efbd558a91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We may as well use the common function for this rather than
duplicating the code.
(From OE-Core rev: 20979854c52607212c16e0b01cf610c80d8b524e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If directory names in SRC_URI ended with "/", function
do_ar_original() in layers/oe-core/meta/classes/archiver.bbclass
will generate a tar file whose name is ".tar.gz".
So delete the "/" at the tail of the directory names before use the names.
(From OE-Core rev: a539e823d002fefe129e3045f893d1237fadb87f)
Signed-off-by: Jian Liu <jian.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
vdso build could generate so files, avoid installing such so files into kernel
source dir, otherwise the below package QA error might be hit:
ERROR: QA Issue: File '/usr/src/kernel/arch/x86/vdso/vdso64.so' from
linux-yocto was already stripped, this will prevent future
debugging! [already-stripped]
(From OE-Core rev: daff14bf44c59542c8b8f1a455dcc59586be7e59)
Signed-off-by: Yang Shi <yang.shi@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the recipe being built is listed first in BB_TASKDEPDATA (i.e. item
0) this is still valid and should not trigger an error.
(From OE-Core rev: 945c98969bcfe5516b89ac6dfbe4552fb5d68a48)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we have done do_package_qa_setscene we do not also need
do_package_setscene. This means we can again for example rebuild an image
without needing do_package sstate packages to be present.
(From OE-Core rev: a0f584ac3d5a94dec121b684206ecd40c968f7fc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use .txt extension like other reports (e.g. image-info.txt) it's
also useful when looking at the file from web server which doesn't
have text/plain as default content-type
* include whole BUILDCFG_HEADER/BUILDCFG_FUNCS instead of just layer
info
* this makes it easier for distro to include more fields without the
need to modify buildhistory.bbclass
* currently it adds following fields:
Build Configuration:
BB_VERSION = "1.23.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Gentoo-2.2"
TARGET_SYS = "x86_64-oe-linux"
MACHINE = "qemux86-64"
DISTRO = "shr"
DISTRO_VERSION = "2013.07-next-20140725"
TUNE_FEATURES = "m64 core2"
TARGET_FPU = ""
(From OE-Core rev: 6db6c74f2876df7a183990426bb4262972966441)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- add new testsdk task for meta-toolchain testing.
- enable the get_tests_list method to work with sdk tests.
- add default TEST_SUITES value for meta-toolchain package
NOTE: Original patch made by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: b78bc50904d53d5091729de481b99cc3ac4aaa1e)
Signed-off-by: Corneliu Stoicescu <corneliux.stoicescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was old debug which can safely be removed for less noisy builds.
(From OE-Core rev: d0be4b37743492fc9c178fd6f9ef73a5eb2fd9c3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this, things like arm* can make it into OVERRIDES when we're
building a compiler to build binaries for another architecture like
x86. This can can lead to build failures dependning on the
exact configuration and overrides.
For example:
MACHINE=imx53qsb bitbake gcc-crosssdk-initial-x86_64 -e | grep EXTRA_OECONF
was showing an armv7 configuration option to gcc.
(From OE-Core rev: 859ac3fdb75303f9f0b4bf1d8d83db0069f0a27b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The image_types.bbclass is a must since we use this in image.bbclass:
[snip]
python () {
deps = " " + imagetypes_getdepends(d)
d.appendVarFlag('do_rootfs', 'depends', deps)
[snip]
The imagetypes_getdepends() is defined in image_types.bbclass. Use "+="
to replace "?=" since it is a must, so that the user can use
"IMAGE_CLASSES = foo.bbclass" in local.conf to add their own image
class.
NOTE: the IMAGE_CLASSES_append = " foo" doesn't work since we use this
in image.bbclass:
IMAGE_CLASSES += "image_types"
inherit ${IMAGE_CLASSES}
I think that it is because inherit takes effect before append?
Another way to fix the problem is:
IMAGE_CLASSES ?= ""
inherit image_types ${IMAGE_CLASSES}
But it seems that we need another name for IMAGE_CLASSES, for example
IMAGE_CLASSES_EXTRA, and also need update the doc, which would make it
complicated.
(From OE-Core rev: c225613d997ef40dedf64b880b5ca4ae89adfded)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "squashfs-lzo" to the image types. LZO compression support has been
in both kernel and squashfs tools for many years, but OE never enabled
it.
(From OE-Core rev: ab659b1c1e13fd6863893abff86990d88aa36790)
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in base.bbclass to spread PREFERRED_PROVIDERS values
to multilibs doesn't work for things which rely on TARGET_PREFIX,
such as virtual/${TARGET_PREFIX}gcc. This is because the expansion
of TARGET_PREFIX produces the wrong value if executed prior to
the assignment of TARGET_VENDOR_virtclass-multilib-libxx, which
will always happen since that assignment doesn't happen until recipe
parsing, but the PREFERRED_PROVIDERS expansion is happening
around ConfigParsed.
To solve this, we make a couple of changes. First, the creation
of the TARGET_VENDOR override values is moved into a new ConfigParsed
event handler in multilib_global. Second, the preferred_ml_updates()
function's code is moved into that function too. It seems safe to
assume that PREFERRED_PROVIDER values only need to be spread to
other multilibs when multilibs are in use.
I don't think this directly affects any use cases that don't involve
third-party or alternative toolchains.
(From OE-Core rev: 513f72274460e54fd35dda5ef70fa42ba2b284f8)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used to ensure the proper version of --with-float=FOO
is passed to gcc's configure script. gcc also has a --with-fpu=FOO
option that means something different. To avoid confusion, change the
names to be consistent.
(From OE-Core rev: c17d883fa99b6967d83c3796d22fc0c1dbe704e6)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was dropped from default CXXFLAGS in:
commit 24dd8e129447013ee98609f3892ec414b1b21340
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Sun Mar 2 17:38:33 2014 +0000
bitbake.conf: Drop -fpermissive
Drop the -fpermissive C++ compiler flag. We've had this around for years, most
code should have been fixed long ago. Its possible some recipes may fail
however we can (and should) just use the flag where needed.
* I haven't build world with this yet, but maybe it's time to
drop it here as well at least for consistency
(From OE-Core rev: 578124aedd3dbffd79ea01862d57223ffaa7216a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 6a7b989933 introduced a typo in
command, a whitespace was missing between --new-line-format and path to
original file. As a result, diffconfig task did not work, diff failed
with exit status 2, resulting in empty fragment.cfg.
(From OE-Core rev: 8c75aa7c30cc5a796962d099896ca2a9a16c3a06)
Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It makes sense to move the script to a separate file, making the bbclass
clearer and allowing the end user to more easily customise or replace
it. There are no functionality changes, just the addition of some
substitution variables.
(From OE-Core rev: f99732a29689c65083ad09abb302f372042c8cd4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no real reason to have these separate files any longer. It does
mean in meta-toolchain type recipes some extra variables are defined but
it also means the common code can be grouped and maintained together
which I believe is more beneficial. We therefore merge the classes.
(From OE-Core rev: 2cf42b49003494e1b10775523c9a2547eaf16ea4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Default core image actually includes packagegroup-base-extended, not
just packagegroup-base.
(From OE-Core rev: 1e567d497713c31e03b58c9997058fc4c0181e5a)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use $HDDDIR rather than ${HDDDIR} in build_boot_dd(), otherwise may
errors:
- Set these in local.conf:
IMAGE_FSTYPES += "live"
IMAGE_FSTYPES += "vmdk"
AUTO_SYSLINUXMENU = "1"
NOHDD = "1"
$ bitbake core-image-sato
DEBUG: Executing shell function build_boot_dd
install: cannot create regular file
`/path/to/core-image-sato-1.0/hddimg//vesamenu.c32': No such file or directory
WARNING: exit code 1 from a shell command.
This because it uses the ${HDDDIR} which is set in bootimg.bbclass, use
local HDDDIR which is set in build_boot_dd() will fix the problem.
(From OE-Core rev: 1891c39a359e983bb8fd7992b7b5a1aaac11baf7)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
