| Age | Commit message (Collapse) | Author |
|---|
|
Documentation.conf is used in WebHob to display
information strings about the collected variables.
This patch brings the file up-to-date with latest
information available from the manual.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
QEMU machines don't have virtual IrDA or PCMCIA hardware, so don't claim to
support them.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This has now been superseded by testimage.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
To make it easier to move WORKDIR, define it using the new variable
BASE_WORKDIR, which is the root of the work directory.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The variable ##COREBASE## has been deprecated, so use ##OEROOT## instead.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As there are two alternative mesa recipes (mesa and mesa-gl), there needs to be
a virtual provider that recipes that explicitly need Mesa (such as xserver-xorg)
can depend on.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some machines have hardware-specific GL drivers that do EGL and GLES (many ARM
boards). Others have their own EGL/GLES drivers and provide a Mesa DRI driver
(EMGD). Previously adding Mesa, for software GL/GLX rendering in the first case
and hardware GLX in the second, involved bbappends and changing Mesa to be
machine-specific.
By adding a just-GL Mesa the machine definition can combine it with the hardware
drivers cleanly.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
directory
Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.
This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.
With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.
The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.
It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Increase the version to signify the layout change of the images
in the deploy directory.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows a clean seperation between image outputs from different
machines, and makes it possible to have convenience symlinks to make
the output ready to deploy.
This did require some surgery in runqemu; if explicit paths to the image
and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined
from bitbake or set in the environment. However the script does try to
avoid requiring it unless it really is needed. Corresponding changes
were made in the automated testing code as well.
Based on an RFC patch by Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For a long time we've provided PN-PV and PN-PV-PR by tweaking PROVIDES. This looks
nice at first glance however it turns out to be a bit problematic. Taking make as an
example where there are two versions, 3.81 and 3.82, what should "bitbake make-3.81" do?
Currently it builds make-3.81 and make-3.82 and breaks in interesting ways. Is that
a bitbake bug? Well, it certainly shouldn't try and run the build. Why is it building
3.82 though? Its due to finding a dependency on "make-dev" and then trying to figure
out what provides it? The answer is "make" and the default version of "make" is 3.82.
So arguably, finding "make-3.81" should infer PREFERRED_VERSION_make = "3.81". Doing
so resolved the above problem since now "make" resolves to "make-3.81".
So what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make-3.82"
That is clearly an error, easy. So finally what about if we have Recipe A:
DEPENDS = "make-3.81"
and Recipe B:
DEPENDS = "make"
The first recipe infers the PREFERRED_VERSION_make = "3.81" and then forces that
version on everything else. Is that desired? Probably not in most cases, at least not
silently.
As mitigation, we could print a WARNING about this happening. The final part of the problem
is that we can ony figure this out within bitbake itself. That means we'd have to teach bitbake
about the PN-PV format of PROVIDES which is breaking the separation between bitbake and the
metadata. We can't win :(.
Nobody that I know of is using or relying on this functionality so perhaps we should
just remove it instead which is what this patch does. Opinions?
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-i9xx and the GLX X module have to be conditional in the ia32 machine
defintion too.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As Mesa refuses to compile if the "opengl" DISTRO_FEATURE isn't enabled,
mesa-driver-swrast has to be conditional in the QEMU machine defintions too.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
APM is not only obsolete, but requires a kernel config enabled and is meaningless for QEMU VM
[YOCTO #5121]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
bundling
This patch aims to fix the following two cases for the INITRAMFS generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
as core-image-minimal-initramfs. This allows building a base
image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
the initramfs.
A key requirement of the initramfs is to be able to add kernel
modules. The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.
The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point. The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.
The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.
[YOCTO #4072]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add an example of how to enable FORTRAN from local.conf. Make
it clear this is not officially supported.
[YOCTO #5091]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gcc recipes reference this however we account for it in the work
directory paths and we don't want recipes depending on the value changing.
This avoids unecessary rebuilds when switching SDKs.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These have been deprecated for a long time, convert the remaining
references to the correct modules and prepare for removal of the
compatibility support from bitbake.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This was never a particularly useful browser and is a dead codebase, retire
it and suggest midori instead.
[YOCTO #2318]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SPDX integrates real-time license scanning, generates
SPDX standard output and license verification
information during the OE-Core build process. The
existing module includes scanning patched packages
and creating package and file level SPDX documents.
Signed-off-by: liangcao <liangcao@unomaha.edu>
Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Now that the 3.10 kernel has been released we can bump the libc-headers to
that version and remove the 3.8 variant. Userspace compatibility is
maintained through kernel versions, we also make the single 3.10 version the
toolchain default.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is a need for a default provider for bluez
now that bluez5 recipe is also present.
After the introduction of bluez5 recipe,
the following warnings are displayed:
"NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez"
Upon debug, bitbake shows:
DEBUG: checking PREFERRED_PROVIDER_bluez4 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101-r5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7-r0 (value None) against ['bluez4', 'bluez5']
Bitbake is faced with the question "what should provide libasound-module-bluez?"
which is a runtime name. It needs to try and find a PREFERRED_PROVIDER entry
which matches this but those use *build time* naming. So it converts "libasound-module-bluez"
into the canonical ${PN} of bluez4 and bluez5 and then tries to look those up.
What it actually should do is go one step further of mapping bluez4/bluez5
into the virtual/bluez but that does not happen.
Bug opened on this issue: YB5044
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5044
[YOCTO #5030]
Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There were darwin8/darwin9 overrides spinkled in the code from times gone
by. Lets settle on the darwin override and remove the others since its pointless
duplication. We always inject darwin into OVERRIDES if needed in the darwin8/9
cases.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
On darwin, we have:
libxxx.dylib -> libxxx.Y.dylib
compared to Linux which has:
libxxx.so -> libxxx.so.Y
Our ordering of PACKAGES with -dev first and then ${PN} makes it impossible to
match the files correctly using simple globbing. This makes darwin targets
completely broken since both the libs and the dev symlinks end up in ${PN}-dev.
Whilst this commit is a hack, it at least puts the files into ${PN} and allows the
builds to be used. Symlinks don't take up much space so this isn't the end of
the world. I'm open to better solutions to this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Hardcoding -nativesdk as the sdk package architecture is inflexible. We may have
multiple different target OS and we need a way to be able to separate them. Turning
this into a configurable value allows the flexibility we need to build different
SDKMACHINEs with different OS targets.
The commit should have no behaviour change, just makes things more configurable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The gettext handling of USE_NLS has become a bit tricky to understand, or
alter from the SDK context. This patch introduces a SDKUSE_NLS which can
be set to configure a given SDK/ADT to use NLS or not. This is independent
of the target system NLS usage.
The code in gettext.bbclass is therefore simplified and the classes
themselves now set USE_NLS to appropriate values. No NLS is used
for native, cross and crosssdk since it is never used there and
would just increase build time.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add NO_RECOMMENDATIONS support. A way to disable all recommended
packages from being installed. This will help shrink the size of
the resulting filesystem.
Add documentation on NO_RECOMMENDATIONS and BAD_RECOMMENDATIONS.
Note, using NO_RECOMMENDATIONS has side effects such that kernel-modules may
not have been installed. A user will need to manually add to their image
any kernel-modules required to be on the image for functionality.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add the foundation for the PACKAGE_EXCLUDE support.
As part of this work, it was noticed that the PACKAGE_INSTALL and
PACKAGE_INSTALL_ATTEMPTONLY were still using he 'normal' version for
dependencies. This should no longer be necessary as of the change in the way
the complementary package groups (dev, dbg, ptest and others) are defined.
By making this change the dependency tree is more correct than before, and
gives the ability for manipulating PACKAGE_INSTALL and
PACKAGE_INSTALL_ATTEMPTONLY, while adjusting the dependencies at the same
time.
Warning messages will be generated if the user is trying to exclude a
package that was previously in the PACKAGE_INSTALL or
PACKAGE_INSTALL_ATTEMPTONLY variables.
(See additional commits for package manager specific support.)
Add documentation on PACKAGE_EXCLUDE and related variables.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
When making distributions based on the default distro-less config, it
is useful to be able to reuse the default DISTRO_FEATURES options
without the need of duplication. The new variable,
DISTRO_FEATURES_DEFAULT, allow this reuse and customization.
So distros can include 'default-distrovars.inc' and use:
,----[ Use example ]
| DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature"
`----
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
We use mac99 as platform for qemuppc
lets choose a tuning thats appropriate for it
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
This is appropriate tune for mac99/g4 platform
that we use for emulating qemuppc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
* it's safer to select it consistently with virtual/libgl* providers
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
One patch (submitted upstream) for when Gallium is enabled, and another
(inappropriate for upstream) to fix out-of-tree builds with
0003-EGL-Mutate-NativeDisplayType-depending-on-config.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add a comment explaining the libproxy failure, and note that wpa-supplicant doesn't support B!=S.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
In case the compiler version cannot be extracted instruct user to check
that the toolchain supports MACHINE's architecture and that the latter
is set correctly in local.conf.
[YOCTO #4901]
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Addess the issue with multiple .bb providers
ERROR: Multiple .bb files are due to be built which each provide virtual/libc (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide virtual/arm-none-linux-gnueabi-libc-for-gcc (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
ERROR: Multiple .bb files are due to be built which each provide virtual/libiconv (/srv/hdd/releases/dylan/meta/recipes-core/eglibc/eglibc_2.17.bb /srv/hdd/releases/dylan/meta/recipes-core/meta/external-sourcery-toolchain.bb).
This usually means one provides something the other doesn't and should.
Thanks to Kergoth (Chris Larson) and Lpapp (Lazslo)
[YOCTO #4908]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add support for the BAD_RECOMMENDATIONS variable that can be used to
prevent specific packages from being installed via an RRECOMMENDS
relationship when using the RPM backend. (Previously this
functionality was only available when using ipk packaging.)
In the process this moves the defaulting of BAD_RECOMMENDATIONS (as
empty) to bitbake.conf since it is no longer specific to the ipk
backend, as well as unifying some of the code that creates the
configuration for smart for use on the host and target.
Fixes [YOCTO #3916].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add detailed explanation of EXTRA_USERS_PARAMS which is used for
image level user/group configuration.
[YOCTO #4074]
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Create a local SECURITY_NO_PIE_CFLAGS to cover the recipes that have
issues with with pic and pie cflags set.
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Its gone with eglibc 2.18
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Bumping LAYERVERSION_core to denote where meta-toolchain* is being
depreciated.
This goes back to my RFC:
http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/39016
As we are removing meta-toolchain* and replacing it with bitbake
<imagename> -c populate_sdk this causes issues with those of us who
need to do automated builds both on the current development branch and
on prior development branches.
Example: For prior releases, I need to build meta-toolchain*. Without
having a simple way to figure out where this is no longer the case, I
(and other folks who run automated builds) end up having to jump
through a lot of hoops trying to figure out where this layer changed.
Utilizing LAYERVERSION_* to do it makes sense as there is a
significant change that would cause issues for build engineers.
Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
These flags add addition checks at compile, link and runtime to prevent
stack smashing, checking for buffer overflows, and link at program start
to prevent call spoofing later.
This needs to be explicitly enabled by adding the following line to your
local.conf:
require conf/distro/include/security_flags.inc
[YOCTO #3868]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Add SGI license used, for example, in glmark2
Signed-off-by: Diego Rondini <diego.ml@zoho.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Somewhere along the line this change got lost, update the git
proxy examples to match the current usage.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Belen Barros Pena
Ross Burton
Paul Eggleton
Richard Purdie
Saul Wold
Jason Wessel
liangcao
Bruce Ashfield
Cristian Iorga
Mark Hatle
Otavio Salvador
Khem Raj
Martin Jansa
Laurentiu Palcu
Chen Qi
Elizabeth Flanagan
Diego Rondini