* Fixed:
The netmap has been blacklisted in
meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can
be built (suppose it doesn't depend on another broken recipe netmap-modules, it
is a little complicated, will talk below):
$ bitbake lib32-netmap
This is because of the old code masks on bb.event.ConfigParsed which can only
handle global blacklist, netmap sets blacklist in the recipe, so it can't be
handled, and lib32-netmap can be built. which was incorrect:
blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed"
Move multilib code into multilib.bbclass can fix the problem easily:
$ bitbake lib32-netmap
ERROR: Nothing PROVIDES 'lib32-netmap'
ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: <foo>
* Not fixed
Another problem is netmap-modules has also been blacklisted in the recipe, and
the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the
code shows:
# There should only be one kernel in multilib configs
# We also skip multilib setup for module packages.
provides = (e.data.getVar("PROVIDES") or "").split()
if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data):
raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")
And netmap-modules provides lib32-netmap-modules which is handled in
multilib_global.bbclass, so bitbake lib32-netmap-modules can't show
the blacklist message:
$ bitbake netmap-modules
ERROR: Nothing PROVIDES 'netmap-modules'
ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: <foo>
ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel
$ bitbake lib32-netmap-modules
ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches:
netmap-modules
netmap-modules
lib32-fbset-modes
Note the different messages between netmap-modules and lib32-netmap-modules.
This is because multilib.bbclass doesn't handle the "module" recipe so
there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't
handle it.
Note, there are two "netmap-modules" which needs to be fixed later.
(From OE-Core rev: c8749ed1edcbb544f6656ee5da80f2cf647c405a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.
(From OE-Core rev: 8de0c5d3bd01919e2bf0394f9c485936d6098cec)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:
d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')
which I've corrected (they happend to work by luck).
(From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
base.bbclass sets 'check_license' to False (and therefore skips
license checking completely) for native, nativesdk, etc recipes
(ie anything which could potentially be classed as "host tools"),
so supporting a dedicated whitelist of GPLv3 host tools is not
necessary.
(From OE-Core rev: 8fc8b60005e7641861324c8541fb45058e7aab8e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building something like lib32-core-image-minimal -c populate_sdk, we
expect one sysroot with both multilibs installed. We therefore
need a single SDKTARGETSYSROOT value which doesn't change when multilibs
are enabled.
This makes the image generation code match what the meta-environment
files set the SDK up to use.
(From OE-Core rev: a6ade4d24e8153920311db9a9033a7f5c430d1e4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I believe this code dates from previous times when we didn't extend
the TOOLCHAIN_TARGET* variables to cover all multilibs. We now do
this so this code acutally breaks things by removing the non-multilib
variants.
By changing this, a multilib SDK now contains both sets of base libraries
which matches the tools we ship with it. If the user wishes to customise,
this also becomes easier.
(From OE-Core rev: 568b81b5102213643e382d31a4e5e56f90ee6ff9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use package_qa_handle_error to handle the QA issue.
(From OE-Core rev: c925847dea7b0480c901e94b6a071a18f5e00d45)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, PN is used in overrides which is expanded to have a MLPREFIX. This
means and pn- overrides without the prefix would be ignored which is not what
is usually expected.
We noticed huge problems using poky-lsb with multilib since the per recipe
overrides were not applied. This adds in handling for PN with and without
the prefix. This should unbreak world-lsb builds on the autobuilder.
(From OE-Core rev: b4cf6631efd526728ac515ced1a7e578674ca6c1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...
In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But for the build of lib32-
meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is
deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...
|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|# set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|# "x86"
|# del data_smart.py:406 [finalize]
|# ""
|# pre-expansion value:
|# "None"
...
The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted
it at DataSmart.finalize
...
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Tue May 31 23:52:50 2011 +0100
bitbake/data_smart: Change overrides behaviour to remove
expanded variables from the datastore
...
We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the
value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.
For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib
-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>
[YOCTO #6842]
(From OE-Core rev: 9c59d3d8b538d3a98ff4b5e5b189a4a23a85da2d)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While building multilib extended images such as libXX-core-image-minimal,
the WORKDIR has the same dir with the building of core-image-minimal.
$ ls tmp/work/qemux86_64-poky-linux/ -al
...
drwxrwxr-x 3 jiahongxu jiahongxu 4096 Oct 13 16:01 core-image-minimal
drwxrwxr-x 3 jiahongxu jiahongxu 4096 Oct 16 11:11 lib32-core-image-minimal
...
While image class is inherited, it did not assign OVERRIDES with
'virtclass-multilib-libXXX', so the reason is variable TARGET_VENDOR was
not override for multilib in that situation.
It refers what did for PN and MLPREFIX, and manually do the multilib
override for TARGET_VENDOR in RecipePreFinalise handler.
[YOCTO #6844]
(From OE-Core rev: 7ca012fb3addb11ba3f899efa0619ddd8d3c6946)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that all licenses are canonicalised to SPDX names when processing, we need
to rename the whitelists to the match.
[RP: Fixed up multilib.bbclass too]
(From OE-Core rev: 5b6cdac26e35e9a3b8b09185fc16765fa99dfe5f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multilib QA warning was observed, as follows:
------
WARNING: Multilib QA Issue: lib32-oprofile package lib32-oprofile -
suspicious values 'kernel-vmlinux' in RRECOMMENDS
------
The package starting with 'kernel-vmlinux' should be ok with multilib QA
checking.
(From OE-Core rev: 00012b63fefd77c57169f7cc06d648f54890e5df)
Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we don't do this, systemd.bbclase will complain to unable to find multilib
packages since PACKAGES is expand with mlprefix, but SYSTEMD_PACKAGES is not,
like in ntp.inc:
$grep PACKAGES meta-oe/meta-networking/recipes-support/ntp/ntp.inc
PACKAGES += "ntpdate sntp ${PN}-tickadj ${PN}-utils"
SYSTEMD_PACKAGES = "${PN} ntpdate sntp"
$
$bitbake ntp
ERROR: ntpdate does not appear in package list, please add it
ERROR: sntp does not appear in package list, please add it
$
(From OE-Core rev: 84f1d3252c369dff06a517baa4fd7fe274782e40)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 1b8e4abd2d9c0901d38d89d0f944fe1ffd019379)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that bitbake supports masking events for event handlers, lets use
this so event handlers are only called for events they care about. This
lets us simplify the code indentation a bit at least as well as mildly
improving the event handling performance.
(From OE-Core rev: bff73743280f9eafebe4591f7368ead91a4eb74d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PACKAGEFUNCS_append = "do_package_qa_multilib" lacks a "space",
which would cause unexpected errors.
[YOCTO #3190]
[YOCTO #4396]
(From OE-Core rev: acd5fc716bc3095d568bd1474b79f3a0fd616eea)
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>
If we don't do this, multilib packages don't have any code
added to the postinstalls to handle user additions.
(From OE-Core rev: b10d17d1b03fd0564103a6998f218d0968d1032b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were problems where a SRC_URI with:
SRC_URI_append_powerpc = " xxx"
SRC_URI_append_powerpc64 = " xxx2"
would end up with *both* xxx and xxx2 being added when using a multilib
which is clearly incorrect and undesirable.
The issue is that OVERRIDES has virtclass-multilib-xxxx added to it,
this eventually changed DEFAULTTUNE which then changes
TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to
re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied
twice since once you apply an override, it doesn't get undone.
Expanding DEFAULTTUNE to the correct value in advance avoids the issue
and means only the correct overrides get applied.
[YOCTO #3874]
(From OE-Core rev: 920c9024f5a47ad14670067f910450983bae2aa7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than keying on recipes that inherit kernel.bbclass, we should
be checking for providers of virtual/kernel when skipping kernel
recipes in multlib builds.
Not all providers of virtual/kernel inherit kernel.bbclass (notably
linux-dummy), so checking on the provider is a more complete check.
We need to be sure to check for inheritance of module-base as well, this
allows for packages that provides modules to avoid the multilib renaming.
(From OE-Core rev: dc7d181ab03ceab87a24d932130109003334dbf8)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- skip the non-packagegroup allarch recipes in multilib_virtclass_handler
- extend PROVIDES/RPROVIDES for allarch recipes which are not packagegroups
- use variants from MULTILIB_GLOBAL_VARIANTS (lib32 lib64 libx32) to create
additional pkgdata files for multilib allarch: ${pkgdatadir}/${variant}-${PN}
and ${pkgdatadir}/runtime/${variant}-${pkg}
- use variants from MULTILIB_VARIANTS to create additional pkgdata files
for multilib kernel/module-base recipes
- add a sanity check to determine if the current multilib is in
MULTILIB_GLOBAL_VARIANTS
[YOCTO #2918]
[YOCTO #3440]
[YOCTO #3565]
[YOCTO #3568]
(From OE-Core rev: bc4da2573dfb59ea2fc4af359701818df20f7663)
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The packages which start with "rtld" are ok
[YOCTO #3440]
(From OE-Core rev: 1bb3f44065d0470dd2f6950e267ef991c2ce6fd5)
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With this recently introduced exclusion, <multilib>-meta-toolchain-sdk
throws errors about missing DEPENDS that don't exist since it needs the
PROVIDES/DEPENDS remapping. This patch tweaks the class tests to fix
the errors.
(From OE-Core rev: 9cc18fe12bd8d1c73df291b4057aab6167ef6b16)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Crosssdk packages are not actually multilib packages, so treat them
the same as other nativesdk packages in the multilib, base, and
classextend components.
(From OE-Core rev: 15834451525453e0f7ceac25d4f98117f1825f37)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for the generation of cross-canadian packages.
Each cross-canadian package has:
PN = "pkg-cross-canadian-${TRANSLATED_TARGET_ARCH}"
in order for that to be evaluated properly with multilibs enabled, it was
necessary to detect both the presence of the cross-canadian packages and
then update the vars using the OVERRIDE for the multilib. Additional checks
were made to ensure that any dependency that sais "cross-canadian" did not
get prefixed with the MLPREFIX.
Also, make sure that even when building multilib cross-canadian packages,
we only use the single SDK PACKAGE_ARCH, we don't want or need variants.
(From OE-Core rev: 132a182e2f6c330aa645de42c1aeb386e43bddd3)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that PACKAGES_DYNAMIC is more standardised, starting with ^ anchors,
the variable manipulations performed by clsextend for multilib don't work.
This patch at least improves it to hack around the problem and enable
mulitlib builds to work again. If this code doesn't do the right thing, the
recipe is free to override the variable with the correct multilib case.
(From OE-Core rev: 593faec6e0155bdd7a43ee84c24de8ee20287681)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bb.utils.explode_dep_versions function has issues where dependency information
can be lost. The API doesn't support maintaining the correct information so this
changes to use a new function which correctly handles the data.
This patch also fixes various points in the code to ensure that we do not have any
duplicates in things that use explode_dep_versions.
A new sanity test to test the contents of the R* variables is also added.
[Some changes from Mark Hatle <mark.hatle@windriver.com>]
(From OE-Core rev: 16a892431d0c0d03f8b561b92909cf2f11af4918)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the STAGING_DIR_KERNEL is set in the multilib.conf, then it may be
set incorrected. The evaluation happens before TMPDIR and LIBC are
defined in other components.
Moving the definition process to the multilib.bbclass ensures that
everything has been loaded before it is set.
(From OE-Core rev: 6bd87edc383b40e300b0ef4bf851c39b698305cd)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current multilib search path code for packagedata is flawed since it
doesn't correctly handle changes in the TARGET_VENDOR/TARGET_OS that
multilib may make. This patch enhances the code to correctly build the
search paths so multilib packagedata is found correctly.
(From OE-Core rev: f50c5d36b2da9b36d56d95a7d89404509a1a3e9b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It isn't supported to mix multilib and nativesdk in the same target, so
explicitly skip multilib processing if nativesdk is inherited. As a
bonus this fixes a bunch of related "missing file" warnings from the
file checksum code during parsing because BPN was not correctly stripped
for these targets.
Second half of the fix for [YOCTO #3146].
(From OE-Core rev: d9a1eb5054d487affb94431374a9cb1a735e2122)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for
the value of BPN) can derive the bare name from the multilib-extended
name for image recipes. BPN being set correctly avoids missing file
warnings during parse from the file checksum code for (unusual) images
that set SRC_URI, such as build-appliance-image.
First half of the fix for [YOCTO #3146].
(From OE-Core rev: ddec9a1b45159c75e97e92abe9a940268acd84b2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RP: The list of recipes in multilib.conf needs to go away and we need
to just be able to extend all recipes with the multilib class.
Tested by building and running lib32-core-image-sato-sdk.
[YOCTO #1563]
(From OE-Core rev: 5d691f1bc95dfb9109b07827b33957b1fa5b2fa4)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable the remapping for SDK generation, this is required to be able to
create an SDK that targets an alternative multilib. Note, this work does
not finish SDK/multilib support, but it is one more step toward making
it work properly.
(From OE-Core rev: d66d2bdf6214939e8b131f47db2f35d3c64e7dd2)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added a new PACKAGEFUNCS function to check the multilib packages'
dependency.
(From OE-Core rev: f193729cdf0f3eccf96a8ce7bf5f599eca89a0d0)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The value of ALL_MULTILIB_PACKAGE_ARCHS needs to be consistent both
in multilib extended recipes and in normal context. If this isn't the
case it can lead to inconsistent configuration files at a minimum.
This patch ensures the value is preserved during the class extension code
since computing it after that point is hard.
[YOCTO #2290]
(From OE-Core rev: 529bc145152bb36d9696226b93729377a3b6a240)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we set this bit, we can override the ugly "pokymllib32" to back to
"poky" (powerpc-pokymllib32-linux-gcc -> powerpc-poky-linux-gcc). I've
left this unset by default, but can be set by adding the following:
TARGET_VENDOR_virtclass-multilib-lib32 = "-poky"
(From OE-Core rev: 01fd9be5db633d881c789c5b119f794a3f1000da)
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There should just be a single IMAGE_INSTALL variable. If the package
backends need this split into different multilib components they should
be responsible for doing this, not the user.
This commit removes the MULTILIB_IMAGE_INSTALL variable.
[YOCTO #1564]
(From OE-Core rev: 7736862a74c92fe1afe42e170822be13117575c2)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add MLPREFIX to multilib deploy forlder to avoid the confliction between
multilib and normal package deploy directory.
(From OE-Core rev: 18b8d1f7769b63725c3b6883298a841806cd06ab)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.
Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.
[YOCTO #1497]
[YOCTO #1498]
(From OE-Core rev: 64c0279e6b0d2325a326058476228360898550f3)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RDEPENDS of image type recipe needs to be mapped to make sure that the
packages included in the image should be multilib version.
Also add LINGUAS_INSTALL into MULTILIB_PACKAGE_INSTALL list.
[YOCTO #1496]
[YOCTO #1527]
(From OE-Core rev: 93984bb1c9440294a694986831d7a4114c55a282)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch partially fixes problems when building multilib extended
images such as libXX-core-image-minimal. Its not a perfect/complete
solution but works much better than any previous code did.
[YOCTO #1496] (partial)
[YOCTO #1497] (partial)
[YOCTO #1498] (partial)
(From OE-Core rev: 00c38774ef0232cc2be924ed8e59220e7c452096)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently MACHINE_ARCH deploy folder is unique in multilib system, thus
a lib32 version of rpm package will override a normal rpm package if
its PACKAGE_ARCH is ${MACHINE_ARCH}.
Define different deploy folder for multilib architectures to avoid the
confliction.
(From OE-Core rev: 921f984aa65e23d5a8ec5c2e58a96cb8a4790b5d)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a given system we only want one kernel to be built. This change makes
the main kernel recipe provide all of the provides of the various enabled
multilibs hence allowing it to fulfil all the appropriate dependencies.
To make this work a global multilib class file needed to be created.
This patch also enables this multi provider functionality for "allarch"
packages.
[YOCTO #1361]
(From OE-Core rev: 2fd257f6c610624f05c8dd3fe1486364af04696f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1388]
This change is needed to correctly add the dependencies for the do_package
task which bitbake is unable to automatically detect itself.
(From OE-Core rev: 0614b9aa62a46f81d334ca4230080cc707347f3c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Initscripts are missing in target image in multilib case. This commit
adds the renaming logic for the related variables in multilib.bbclass.
This fixes the no response of mouse/keyboard in target system due to
the missing of udev startup script.
(From OE-Core rev: 477fc6e2fc034c68a250005461774bc8ecf91a52)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "pkg_postinst" and "pkg_postrm" as renaming elements, which fixes
missing post install/rm scripts in target image.
(From OE-Core rev: a5c9f8af79c1632d2f3de5dd9627a7ca24fa0b76)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the orignal logic, the renaming will not work for "FILES_" if defined
variables as:
PACKAGES = "${PN}"
FILES_abc = "/usr/include/abc.h"
It is because ${PN} is "lib64-abc" so it will not be contained in
pkgrename.
This commit enumerates all element in PACKAGES, getting the original
packages and multilib packages, then doing renaming for "FILES_",
"RDEPENDS_", etc. This fixes a lot of missing files and incorrect
dependencies.
(From OE-Core rev: ea7c196b4097d64b4f42faccaf075334c297ba20)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Robert Yang
Richard Purdie
Joshua Lock
Andre McCurdy
Hongxu Jia
Ross Burton
Ming Liu
Roy Li
Jackie Huang
Constantin Musca
Bruce Ashfield
Mark Hatle
Paul Eggleton
Bogdan Marinescu
Lianhao Lu
Matthew McClintock
Dongxiao Xu