Clean up some packaging issues, cairo-sphinx was installed
and is a testing tool that does not need to be packaged
(From OE-Core rev: 6a0dac89932b41502bb55a2dae07d835ca3c6245)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bin/python2 link is provided by the python install process,
so no need to create it.
rebase these patches to the newer code:
fix_for_using_different_libdir.patch
04-default-is-optimized.patch
remove this patch as it is upstream now:
sys_platform_is_now_always_linux2.patch
Change default python version to 2.7.3 in the distro config
(From OE-Core rev: 5d92a95ea9b480235b7c9ca5949a681376eba725)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were a couple problems with the handling of precompiled locales.
- it gathered the list of locales from the directories - this breaks due to
the naming mismatch, e.g. en_US.UTF-8 vs en_US.utf8.
- it retained its hardcoded assumption that the non-suffixed locale (en_US, as
opposed to en_US.*) is UTF-8, while the others are otherwise. Hardcoding
this is both inflexible and just plain wrong for some toolchains. It's most
common in desktop distros for 'en_US' to be non-utf8, and ''en_US.UTF-8' is
utf8, and this is the case in some external toolchains as well.
The code now uses the SUPPORTED file to hold the knowledge it needs. This file
not only holds the list of locales to generate, but also maps the locale names
to the charsets they correspond to. The code now uses this to assemble its
charset map, falling back to the '.' suffix as charset when the locale is not
in the map. For precompiled, it now uses the locale->charset knowledge it has,
thereby allowing non-utf8 non-suffixed locale names, whereas for
non-precompiled, it reverts to the previous assumption, renaming the utf8
locale and forcibly suffixing the others.
So, a person maintaining an external toolchain recipe is responsible for
ensuring that the SUPPORTED file they provide matches up with the compiled
locales in the toolchain, if they want to utilize precompiled locales.
I believe in the long term the compiled case should do the same thing
precompiled does, and use SUPPORTED or a similar mechanism to encode the
knowledge, and if people want all the non-suffixed names to be utf8, they can
change that file to do so. This would avoid the hardcoded assumption in the
code, as well as consolidating the behavior between the compiled and
precompiled cases.
(From OE-Core rev: 3f36058923ccda25a3dd85046542e65b6034c09e)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is handled by IMAGE_LINGUAS, so hardcoding it here is at best unnecessary
duplication.
(From OE-Core rev: 7808c7ee9277170fbfb22bcf0575285174c2718a)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This silences one of the QA warnings.
(From OE-Core rev: 3412a1d69201951dd097e4d9a4abcec124d34d68)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to ensure that changing external toolchain version will change the
metadata checksums of target recipes. This will do so via ensuring that any
variable which references TOOLCHAIN_OPTIONS also pulls in the toolchain
version variables.
(From OE-Core rev: 041a61368350dfbca825d2b2781543ea22678161)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A quick glance at configure.ac shows that both are required to build mesa, but
we were relying on their being built implicitly via other recipes in the
dependency chain. Make it explicit.
(From OE-Core rev: 4fb71999fad9e844850831caf2431ee8731787db)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a newly installed directory and Makefile that is not needed
in an embedded setup
It fixes:
ERROR: For recipe eglibc, the following files/directories were installed but not shipped in any package:
ERROR: /var
ERROR: /var/db
ERROR: /var/db/Makefile
(From OE-Core rev: 35b5fb2dd2131d4c7dc6635c14c6e08ea6926457)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update to version 1.0.25.
Add option "--prefix" to GITCOMPILE_ARGS and FILES_${PN} to package
the installed but not shipped files.
(From OE-Core rev: f5da0cdc2ac2e14704319a83bd39e1e0e85ffaed)
Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Set lists_dir to /var/lib/opkg
commit 16808bc4817492beba512f4e73bce8c232d1eafa
Author: Marcin Juszkiewicz <hrw@openembedded.org>
Date: Mon Mar 17 23:40:48 2008 +0000
* Update new options sample and move the opkg.conf to correct place
commit cc9825d97962287df75e164aec456901292e1b7f
Author: Tick Chen <ticktock35@gmail.com>
Date: Mon Dec 29 19:41:47 2008 +0800
(From OE-Core rev: ffe93e2a099e4cadb1829dc12a58a6d7bef9a5a7)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* We have now .bbappends in meta-oe, but adding native BBCLASSEXTEND
doesn't add any maintenance cost to oe-core and makes recipe upgrades
easier (no need to wait for .bbappend renames ready for meta-oe).
(From OE-Core rev: 320816f96b81b8eac02b5bbdbd3d8c79d0095a00)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -mabi option is part of HOST_CC_ARCH which does not
appear in CFLAGS. This is for completeness since compiler
already defaults to n64 it wont matter that much
(From OE-Core rev: 2aa0540515efc15957101e24224b425ee00446d9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
shift the cmdline argument after determining
there is atleast 1 argument to shift otherwise
it ends up in error when no argument is specified
(From OE-Core rev: 4cd306ab0c9404a31f38c7e5fb67fe32fdca3d4b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
uclibc has recently got posix_spawn implementation
and the implementation resided in librt so we link
-lrt to get the configure tests using uclibc provided
definitions and not the gnu-lib wrappers
Let libintl.a live in -staticdev package
(From OE-Core rev: 68e07a5ff114b5f413a5eeedeb551d82bc77774c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently we stub out iconv in glib when building
for uclibc which is not needed and infact results
in building systems with false hope of having
iconv and they misbehave during runtime
(From OE-Core rev: d13b1dc1897af733cc2ec22df50ae9d1fd0b48af)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In tune-sh3, tune-xscale, and tune-sh4, several FEATURES lines referred
to nonexistent features like "sh3eb" when they should have referred to "sh3
bigendian" or the like. Caught by the TUNEVALID sanity check.
(From OE-Core rev: e63fb1e9918bff6f91bbab09b29248ab8b649e84)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 1.5 is not compatible with glib-2.32 and newer
| In file included from gisi/client.h:30:0,
| from gisi/client.c:33:
|/OE/shr-core/tmp-eglibc/sysroots/spitz/usr/include/glib-2.0/glib/gtypes.h:28:2: error: #error "Only <glib.h> can be included directly."
(From OE-Core rev: 72684aac1d97469ee5cf9ef0d017a8b933e2a6d6)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove a patch since it is already in upstream.
(From OE-Core rev: 90f32e0fffaef55415088f523e282ca3c08fa7ee)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
