In some cases we want to pull in DEPENDS and RDEPENDS of recrdeptask
dependencies but we need a way to trigger or avoid this behaviour
depending on context. The logical syntax to trigger such behaviour
would be a self referencing recrdeptask:
do_a[recrdeptask] = "do_a do_b"
The dependency chains already recurse this kind of expression correctly, the
missing piece is to avoid any circular reference errors. Since the dependencies
have already been recursively resolved, simply removing any recrdeptask
references is enough to break the circular references.
This patch therefore removes any circular references using the set
difference_update() operator. There will be metadata tweaks required to
add any references needed to the extra taskname.
(Bitbake rev: a5324da9b8a0c9307a6c511ea9009f34be70c92b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'git remote prune' at this location does not make much sense because
the following 'git remote rm' will prune stale and non-stale branches.
The 'prune' can cause trouble because it will access the network
bypassing the no-network code in bitbake. When this operation fails and
throws an exception, the next command (--> 'git remote rm') will be
skipped. This in turn, will make all the following operations fail,
because they assume that the remote does not exist yet.
(Bitbake rev: 2ba23df5fad4b94d38a6aed97f7822226d72eb89)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This also deletes the buildall task since I seen usecases for it.
(From OE-Core rev: 8229fb5d7205f5e5b198ab2860fbcc02054476eb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This enables a switch to subversion 1.7 now bitbake is able to cope with
upgrading existing working copies. The impact of this change should be
minimal since we don't have many subversion recipes now.
(From OE-Core rev: ac0aa35ba6d7a21636bdd23d45ae0bf8112bdaa8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to include the OpenEmbedded and BitBake mailing lists here as
they are an integral part of the community especially for patch
submission.
Note that this supersedes the information about mailing lists in the dev
manual (which should be replaced with a link to this section).
(From yocto-docs rev: e9bae0a323af2d95505c5492be985232440842ff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I have changed as many "Yocto Project" terms as possible so that
better reflect reality.
(From yocto-docs rev: 5f729e53b0cb653c97621e4e6598d9295d60ada5)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Got rid of some old author text.
(From yocto-docs rev: 358ff9b2de4196d23a51215ea56193fa23ebaa1a)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed all occurrences of "Yocto Project" to terms better suited
to reality.
(From yocto-docs rev: fdd7b8c2bcbaf566cad336c67c582c2a24aa9dc1)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Throughout the manual, the kernels that are built and available through
the Yocto Project were being referenced as a "Linux Yocto kernel."
This reference is poor. First, it placed Linux and Yocto very close
together and could upset the Linux folks. Second, a better way would
have been to say "Yocto Linux kernel." I have fixed by referring to
kernels that are available through the Yocto Project as
"Yocto Project kernels."
(From yocto-docs rev: 9b8319328cd4ab4ce3363001c9feeec585d9cab9)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I have replaced the term "Yocto Project" with more appropriate terms
where possible.
(From yocto-docs rev: 622ef9a2b4897ecd151b641b43d7706ab673c989)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Scrubbed the manual for the term "Yocto Project", which has been
over-used. I updated occurrances to better represent actual bits
rather than generically referring to everything as Yocto Project.
(From yocto-docs rev: f70cffeffa0d8863a88783607621bf6f7125d02d)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #2605].
Added openssh-sftp-server to the tools-debug IMAGE_FEATURE.
(From OE-Core rev: a6b6df1350149c116050cb93c3c7b4802c709d31)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
IMAGE_FEATURES such as 'ssh-server-dropbear' and 'ssh-server-openssh'
can't be both enabled. User can use the following variables to define
the relationship of image features:
IMAGE_FEATURES_REPLACES_foo = "bar" means including image feature "foo"
would replace the image feature "bar".
IMAGE_FEATURES_CONFLICTS_foo = "bar" means including both image features
"foo" and "bar" would cause an parsing error.
(From OE-Core rev: e36d12a9c1cf69540079e48a1dfadbc343758e48)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using Gentoo Linux as the build host, it fails without this patch
Use Getopt::Std in place of getopts.pl.
https://bugs.gentoo.org/show_bug.cgi?id=420083
which following error:
/usr/bin/perl -w ./../msggen.pl -l jstyleModule InterpreterMessages.msg
/usr/bin/perl -w ./../msggen.pl -l jstyleModule DssslAppMessages.msg
Undefined subroutine &main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [InterpreterMessages.h] Error 2
make[2]: *** Waiting for unfinished jobs....
Undefined subroutine &main::Getopts called at ./../msggen.pl line 22.
make[2]: *** [DssslAppMessages.h] Error 2
(From OE-Core rev: 169a89b10817b742c063fcd76721e4dbbcca6199)
Signed-off-by: Dennis Lan <dennis.yxun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This appears to be an oversight in the original implementation. All of the
host package types were being ignored except for the SDK cross-canadian type.
(From OE-Core rev: 750f99d4e2c805985cd87a2358b0625a808ecf4d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building an image recipe, you can now build a companion SDK by
calling the populate_sdk task:
bitbake -c populate_sdk core-image-minimal
Note: there are still issues w/ the SDK not working completely with
multilibs.
A lock is required between rootfs and populate_sdk activities to prevent
configuration file clashes and similar package management problems in ipk
and deb based systems. (RPM already had a lock for a different reason.)
(From OE-Core rev: a0de2a56f19ae4d8cd88e46e96917a7a019fe1ab)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Most of the time skipping per file dependency generation is a bad idea, but
when building a nativesdk or similar you may be required to pickup host
dependencies. These host dependencies can not always be reconciled within
the scope of other nativesdk components, so if we skip them we can facilitate
this unique situation.
(From OE-Core rev: a1ca125de55a8e7cab402e2ba5737a56d4e890c2)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The libc-common attempts to rewrite the package information in a way similar
to debian.bbclass. When it does this, it should be appending to the
dependency variables (RPROVIDES, RREPLACES, and RCONFLICTS), instead
of simply setting a hard coded value. Otherwise the lib package can not
tailor the dependency variables to suite it's needs.
(From OE-Core rev: fa1c7b797593cbd5e82dc264bde2667620eb0515)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When configure fails, it usually says "see config.log" yet nobody ever shares
the config.log file meaning the person trying to help invariably has to ask
for more information.
This patch dumps all the config.log files into the main bitbake log files when
configure fails, meaning all the information is present to help someone debug
such failures. It does make the log rather larger but this is preferable to
not having enough information in most cases.
[YOCTO #2463]
(From OE-Core rev: 7ad08f5b73aa949a877adc5641b4bb1d007de750)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The u-boot tree is fully capable of parallel builds, so this
setting should not exist as a blanket setting for all of the
recipes. Going forward, if there is a parallelism issue
in u-boot, it needs to be reported and fixed there, and not
with the "make -j1" band-aid approach.
(From OE-Core rev: 7fdd1f82803df9752e908f01f7643d66b82a690e)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't want to force everyone to be stripping the -Os
flags from their u-boot builds. Remove it, since it pertains
to an old toolchain issue that is no longer relevant, and it
breaks the powerpc mpc8315.
(From OE-Core rev: 5e3f777f9fcc986ae66203651830b5765bca49fd)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to enable basic multilib support for the export of an SDK
image, a number of minor changes had to be made:
The value of MULTIMACH_TARGET_SYS needs to be variable. This way we
can define the value to the appropriate multilib. (Also in some cases
the default PACKAGE_ARCH is set to MACHINE_ARCH which is incorrect for
the SDK.) Add a companion REAL_MULTIMACH_TARGET_SYS, based on code
from meta-environment, to allow for this.
We have to convert the do_populate_sdk into a python call, and then
break up the previous items into three parts.
* Image construction
* Setup of environment files
* Generation of the tarball
Then we can iterate over the multilibs to populate the environment files.
Finally, matching changes were needed in the toolchain-scripts file. And
what I presume is an optimization of immediate evaluation for
TOOLCHAIN_CONFIGSITE_NOCACHE and ..._SYSROOTCACHE needed to be done at
runtime, otherwise the wrong values may be used.
(From OE-Core rev: 42545ffbb37f2646a2a8c20999c21d3300e24f59)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we combine the do_populate_sdk with the image generation, we want
to avoid the dependency processing unless do_populate_sdk is run.
This requires the bitbake change to implement task based rdepends.
(From OE-Core rev: 5fa9f980248e7813ce74f48a29c4b7d94e308cf9)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to be able to supply attempt only packages in the SDK in order to
support more advanced SDK images that more closely match specific image
recipes.
(From OE-Core rev: 9b9efa96537f4977b158c29151e53d02600d2294)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
populate_sdk was renamed to populate_sdk_base in order to allow for changes
that may break existing SDK recipes. Any such changes need an analog
in populate_sdk (new version) to restore previous desired behavior.
In addition to the rename, one minor change was made. The _base version
only had the do_populate_sdk as an added task, but no before or after defined.
For compatibility, populate_sdk has do_populate_sdk defined as "after"
do_install and before do_build, this is identical to the original behavior.
(From OE-Core rev: bde224ba44c16edc1892cea1b33ab973ae971115)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a recent change, the path to log files may be contained within an
arbitrary directory. To generate the manual log files in the correct path
we should be using the ${BB_LOGFILE}'s path instead of always assuming the
logs go into ${WORKDIR}/temp.
(From OE-Core rev: 779db325d407f0bade84572ef99fdad4d0c88011)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While sdk images already have dev-pkgs included, the kernel-dev package
is special and does not get installed. Add kernel-dev explicitly to the
*sdk image recipes.
Note: We have to be careful with "IMAGE_INSTALL +=" as it must appear
after "inherit core-image" which makes an "IMAGE_INSTALL ?=" assignment.
(From OE-Core rev: 337428316de3612a8e1efa70b3a4ba7cb6e058d2)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jessica Zhang <jessica.zhang@intel.com>
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the linux-tools include as perf is now packaged independently.
Without this, including meta-skeleton in bblayers.conf results in a
build failure as linux-tools.inc cannot be found.
(From OE-Core rev: 9d27daeafcc6ea892dee0ee5d0816069b04f6771)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a "Segmentation fault" error when the tmpdir is longer than 470
(or less), this is because it used "char cmd[1024]" which is not enough
for the command line. Allocate a larger memory size should fix this problem.
[YOCTO #2664]
(From OE-Core rev: 3fd5d0334439b6231a6afd2a544a16b87ae81c99)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kconfig-frontends provides the kconfig infrastructure
thats used for linux kernel as a standalone package. Its
not intended to be used for kernel itself but can be
used by packages who are based on kconfig e.g. busybox
uclibc or new packages who wants to use kconfig infra
for the package build
kconfig-frontends names it's shared library as -3.4.0.so instead of .so.3.4.0,
this causes the -dev package to grab it since it matches on *.so. This error
would also have shown up with the old PACKAGE order.
(From OE-Core rev: 705baf06d151eb4f9dcae7b23c7f3e57c0c09a74)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pared down the use of the term Yocto Project.
(From yocto-docs rev: d62747ca1d42cae703d1cd307dfe16bb9682b741)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These variables all take package name extensions and should be considered in sstate
dependency processing.
This may also fix some multilib alternatives issues (unconfirmed).
[YOCTO #2056]
(From OE-Core rev: 64422f7c5da160050a5454817c8fa9d070104b34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this it will match on expressions like "NOTE:" which
are not fatal errors.
(From OE-Core rev: 8f4e160ce0b0c755545d62b06db14decd45b9f1e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I noticed this when qemu-native failed to build and a rootfs was not generated
which is not the intended behaviour.
Also update the syntax to use appendVarFlag instead of get/setVarFlag
(From OE-Core rev: fa13e83ec3f91dce866ac212e91b62db24b6486d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: ff3f912eed0270afa14d706fc1e57f8a1de2614b)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 8846728da016a964f581e3aa76ec9d457a3d795d)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If cross-compiling, apr's configure script assumes that pid_t is
64-bit which is wrong - it appears that 32-bit is a safe assumption
for Linux no matter what the architecture, so use that instead by
default.
This fixes Apache writing garbage to its pid file when built using apr
produced from this recipe.
(From OE-Core rev: 81eb71736a4d14abe85d810f9862d8a9421e9ef5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
apr will use libuuid if it is present, and thus we should require that
it is there so that we have a deterministic build.
(From OE-Core rev: b880cebf503ca13cd4fcb741895e57e6353065be)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 935a7f3847bd86ed78418db5cb6dd98ac0b6e65d)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu can fail to with the following message:
You need libGL.so and libGLU.so to exist in your library path to run the QEMU emulator.
Fedora package names are: mesa-libGL mesa-libGLU.
The libGL.so and libGLU.so files are provided by the mesa-libGL-devel
and mesa-libGLU-devel Fedora packages (yum provides '*/libGL*.so').
(From OE-Core rev: f2b6f9c3a8b4f87b5570b78766a118e4290d773a)
Signed-off-by: Cristian Ciupitu <cristian.ciupitu@yahoo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In build detail page, the response action of clicked the 'run image'
or 'deploy' button will accroding to below as ui design:
1)if there has one file in building result, it will responsed the
'run image'(now, we only support the qemu) or 'deploy' directly
2)if there has more than one file, it will popup a dialog with listed
created files type, they are has same action attributes 'deploy'
or 'runnable'.
Note: because the qemu image (runnable file) can't be deployed and
we can't generated a image that has the two attributes now, can be run
or can be deployed, so the code will not deal with this case.
[YOCTO #2155]
(Bitbake rev: 0d24b1e85a11b68c8464cf15b49d3fc78f216818)
Signed-off-by: Liming An <limingx.l.an@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(-) rename it also in maintainers.inc
[YOCTO #2636]
(From meta-yocto rev: eabf9a60e6b56a9074319e5216119c03a76e44ba)
Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only bit we seem to need from the linux-yocto include is the
SRCREV_FORMAT. If we define this explicitly, we can avoid including the
linux-yocto include.
This is desirable so that linux-yocto can require kernel and simplify
the PR update process of all the linux-yocto* recipes. Pulling in
kernel to the linux-libc-headers-yocto recipes causes build failures by
pulling in "update-modules-nativesdk".
(From meta-yocto rev: be73421c4c8f5ae119aa8c030cca2442087d5c22)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Bruce Ashfield <bruce.ashfield@windriver.com>
CC: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes throughout the manual that either eliminate or change
many of the "Yocto Project" strings. The file structure for
the meta data is now called "source directory." The build
directory is referred as just that - "build directory." Any
where the build system is referred to it is called the
"OpenEmbedded build system."
(From yocto-docs rev: 1210c19f90d4a52042fec12657212ae3e58e13d6)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
include-unistd.h-for-gcc47.patch is no longer needed, since it was fixed upstream.
(From OE-Core rev: 54429dfcca0e35a3aeaa78e509240b87d6a8f4ac)
Signed-off-by: Jonathan Santos <jrsantos@jonathanrsantos.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie
Liming An
Enrico Scholz
Paul Eggleton
Robert P. J. Day
Scott Rifenbark
Lianhao Lu
Dennis Lan
Mark Hatle
Paul Gortmaker
Darren Hart
Robert Yang
Khem Raj
Cristian Ciupitu
Valentin Popa
Jonathan Santos