| Age | Commit message (Collapse) | Author | Files |
|---|
|
- libc-package.bbclass: Do not use --old-style
This option has been dropped from latest glibc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
localedef handles attempts to read/write the archive in parallel correctly by
creating the file atomically, gracefully handling racing to create, and has
exclusive locks when writing. Therefore I can't see any purpose to copying the
archive to /tmp and back again when manipulating it.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This fragment dates from when this class was used for more than just glibc
locale packaging, and as glibc-locale disables do_configure it can't have been
executed.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
If all locales are being generated then the list used is the keys from a
dictionary. In Python 3.4 onwards the ordering of a dictionary changes for
every instance, so sort the key list.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In python3, strings are unicode by default. We need to encode/decode
from command pipelines and other places where we interface with the
real world using the correct locales. This patch updates various
call sites to use the correct encoding/decodings.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
python hard-codes the encoding of many locales; for instance, en_US is
always assumed to be ISO-8859-1, regardless of the actual encoding of
the en_US locale on the system. cf
https://hg.python.org/cpython/file/7841e9b614eb/Lib/locale.py#l1049,
getdefaultlocale(), etc. This code appears to date back to python 2.0.
The source of this hard-coding is Xorg's locale.alias but is ultimately
justified by glibc's SUPPORTED.
This causes problems on OE, because any locale lacking an explicit
encoding suffix (e.g. en_US) is UTF-8. It has been this way from the
beginning (svn r1). That is not a bug, per se -- no specification
prohibits this AFAIK. But it seems to be at odds with virtually every
other glibc-based distribution in existence. To avoid needlessly
aggravating hidden bugs that nobody else might hit, it makes sense to
disable this behavior such that locales are named precisely as specified
by SUPPORTED.
I suppose that reasonable minds may disagree on whether or not the
current behavior is prudent; at the very least, this is likely to break
IMAGE_LINGUAS settings. So let's create a new distro variable
LOCALE_UTF8_IS_DEFAULT to allow either behavior. Set it to 0 and all
your locales get named exactly like they are in SUPPORTED. Leave it at 1
to preserve current OE locale naming conventions.
Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Building nativesdk-glibc-locale results in many messages like:
QA Issue: nativesdk-locale-base-en-sg rdepends on localedef, but it isn't a build dependency? [build-deps]
It should depend on ${MLPREFIX}localedef, not just localedef
to fix these warnings.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently if exec_func() isn't told what directories to create and change to, it
uses B. This is not obvious and may be changed in the future.
Instead, pass -C<dir> to oe_runmake.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.
This patch was mostly made using the command:
sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add aarch64 target to locale_arch_options in libc-package.bbclass to
support Arm V8.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The 'overrides' here are PACKAGE_ARCH based and hence not overrides
as such and the _append wasn't working in many cases. This adjusts the
code to use PACKAGE_ARCH as the accessor and ensures the variables
work as expected. This fixes various segfaults and ensures postinsts
run at build time rather than on the target system.
The bug was introduced in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7efad8a1b56df6ee07c12ad360c0493d7b1d6d23.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
BitBake has the exact same code as oe.utils.contains so there's no
reason to duplicate it. We now rely on the bb.utils.contains code for
metadata.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Using the contains function results in more optimal sstate checksums
resulting in better cache reuse as we as more consistent code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add big endian ARMv8 target to OE infrastructure
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
tar version 1.27 returns:
tar: --same-order option cannot be used with -c
with the commandlines we have been using. We can remove the -s option (which
is --same-order) to remove the error.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fix gconv build failure on ARM big-endian architecture:
ERROR: locale_arch_options not found for target_arch=armeb
ERROR: Function failed: unknown arch:armeb for locale_arch_options
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
There are various bits of cruft that have built up around our file accesses. This patch
cleans some of them up, specifically:
* Remove pointless "from __builtin__ import file"
* Use open(), not file()
* Wrap file usage in a with container to ensure files are closed
* Add missing .close() calls in some cases
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The names used to generate the binary-localdata packages need to match the location
the dependencies are added. In one case the dash replacement is made, in the other it
is not leading to packages which cannot be installed:
eglibc-binary-localedata-af-za.iso88591 is needed by locale-base-af-za.iso-8859-1-2.16-r22.i586
eglibc-binary-localedata-cs-cz.iso88592 is needed by locale-base-cs-cz.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-ru-ru.koi8r is needed by locale-base-ru-ru.koi8-r-2.16-r22.i586
eglibc-binary-localedata-pl-pl.iso88592 is needed by locale-base-pl-pl.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-hu-hu.iso88592 is needed by locale-base-hu-hu.iso-8859-2-2.16-r22.i586
eglibc-binary-localedata-de-at+euro.iso885915 is needed by locale-base-de-at+euro.iso-8859-15-2.16-r22.i586
eglibc-binary-localedata-sv-fi.iso88591 is needed by locale-base-sv-fi.iso-8859-1-2.16-r22.i586
This fixes things so the names are consistent.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This avoids the hardcoding of ${libdir}/locale which is all over the place,
and will facilitate use of ${exec_prefix}/lib/locale instead of
${libdir}/locale.
This doesn't actually change any output at this time. Verified this with
buildhistory against the packages produced from core-image-base.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The bb and os modules are always imported so having these extra import calls
are a waste of space/execution time. They also set a bad example for people
copy and pasting code so clean them up.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
needed for new architecture support
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
|
Added multilib prefix to the locale related package names/dependencies.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We need to add MLPREFIX when set RDEPENDS by setVar() function.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
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.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
|
|
MLPREFIX is needed in RDEPENDS for multilib build
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The PACKAGE_NO_GCONV var manipulations ware happening in the
eglibc-options.inc file, and the eglibc-locale recipe do not
see it. Moving that into the libc-package.bbclass which is
common to eglibc & eglibc-locale recipes.
This fixes bug: [YOCTO #2089]
This avoids this error for poky-tiny
NOTE: package eglibc-locale-2.13-r19: task do_populate_sysroot: Started
ERROR: Error executing a python function in
/opt/poky.git/meta/recipes-core/eglibc/eglibc-locale_2.13.bb:
OSError: [Errno 2] No such file or directory:
'/home/rchatre/concordia/dev/ccd-distro-work/tmp/work/core2-poky-linux/eglibc-locale-2.13-r19/package/usr/lib/gconv'
ERROR: The stack trace of python calls that resulted in this exception/failure
was:
ERROR: File "package_do_split_gconvs", line 264, in <module>
ERROR:·
ERROR: File "package_do_split_gconvs", line 45, in package_do_split_gconvs
ERROR:·
ERROR: File "package.bbclass", line 30, in do_split_packages
ERROR:·
ERROR: The code that was being executed was:
ERROR: 0260:»------»-------bb.note("generation of binary locales disabled.
this may break i18n!")
ERROR: 0261:
ERROR: 0262:
ERROR: 0263:
ERROR: *** 0264:package_do_split_gconvs(d)
ERROR: 0265:
ERROR: (file: 'package_do_split_gconvs', lineno: 264, function: <module>)
ERROR: 0041:»------»-------»-------d.setVar('RPROVIDES_%s' % pkg,
pkg.replace(bpn, 'glibc'))
ERROR: 0042:
ERROR: 0043:»------do_split_packages(d, gconv_libdir,
file_regex='^(.*)\.so$', output_pattern=bpn+'-gconv-%s', \
ERROR: 0044:»------»-------description='gconv module for character set
%s', hook=calc_gconv_deps, \
ERROR: *** 0045:»------»-------extra_depends=bpn+'-gconv')
ERROR: 0046:
ERROR: 0047:»------def calc_charmap_deps(fn, pkg, file_regex,
output_pattern, group):
ERROR: 0048:»------»-------deps = []
ERROR: 0049:»------»-------f = open(fn, "r")
ERROR: (file: 'package_do_split_gconvs', lineno: 45, function:
package_do_split_gconvs)
ERROR: Function failed: package_do_split_gconvs
ERROR: Logfile of failure stored in:
/home/rchatre/concordia/dev/ccd-distro-work/tmp/work/core2-poky-linux/eglibc-locale-2.13-r19/temp/log.do_package.31042
NOTE: package eglibc-locale-2.13-r19: task do_package: Failed
ERROR: Task 552 (/opt/poky.git/meta/recipes-core/eglibc/eglibc-locale_2.13.bb,
do_package) failed with exit code '1'
Signed-Off-By: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
* While building for i686 architecture an error was coming that
locale_arch_options does not have support for i686. Add missing support.
* Verified on intel architecture.
Signed-off-by: Noor Ahsan <noor_ahsan@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These allow the recipe to build again:
- add compilerlibs, g++, libgcc to the provides
- add linux-libc-headers-dev to the packages
- in libc-package, only sed the ldd.bash.in file if it exists, as the external
toolchain is using that class as well
- shift the inherit location of the libc classes, as they were overriding the
recipe's do_install
- use ?= for EXTERNAL_TOOLCHAIN, so the user can set it
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes this bug: [YOCTO #1874]
Fixes an issue where a locale package depends on one package while it
also provides the same, as seen bellow.
Package: locale-base-de-de
Version: 2.12-r19
Depends: eglibc-binary-localedata-de-de
Provides: virtual-locale-de-de, virtual-locale-de,
eglibc-binary-localedata-de-de
Actually the eglibc-binary-localedata-de-de is ia separate package,
and it should not be part of provides of the locale-base-de-de.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Complete the bb.data.getVar/setVar replacements with accesses
directly to the data store object.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is the result of running the following over the metadata:
sed \
-e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \
-e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-i `grep -ril bb.data *`
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
parallelization
We can generate the locales in parallel. The easiest way to do this is
generate a Makefile and then run this with our usual parallel make
options.
[YOCTO #1554]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There are some places that PACKAGES are dynamically set. To support
multilib, we need to add MLPREFIX before the package name in those
settings.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
|
|
This reverts 19fb07bf337e1d724798e2eb4479c35fc45b1941 and restores
the behaviour of the code to the way it was prior to 561d875404ef1783f94f37314b6e756766db8411.
See http://lists.linuxtogo.org/pipermail/openembedded-core/2011-August/007407.html and subsequent messages.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using binary locales rootfs generation fails with:
| Unknown package 'locale-base-en-us'.
| Collected errors:
| * opkg_install_cmd: Cannot install package locale-base-en-us.
This is due to:
$ dpkg-deb -I ipk/armv7a/locale-base-en-us_2.12-r16_armv7a.ipk | grep Depends
Depends: eglibc-binary-localedata-en.us
Note the '.' seperator
$ ls ipk/armv7a/ | grep binary-localedata-en | grep us
eglibc-binary-localedata-en-us_2.12-r16_armv7a.ipk
Note the '-' seperator vs the '.' in the locale-base packages.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In multilib support, it iterate values in PACKAGES and then extend name
for variables like "FILES_xxx", "SUMMARY_xxx", etc.
However eglibc-gconv is dynamically put in PACKAGES by
package_do_split_gconv function. Therefore the name will not be
extended automatically.
Specially handle the FILES variable for eglibc-gconv to fix the issue
of missing "lib32-eglibc-gconv" issue in doing multilib do_rootfs.
Also when set PACKAGES, add the MLPREFIX.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* libc-{common,package}.bbclass: fix shlib renaming for the C library
Without this you'd end up with eglibc_2.12.ipk instead of libc6_2.12.ipk as before
* eglibc-locale: don't make versions go backwards after split from eglibc
eglibc was way beyond PR = "r1" at the time of the split, so increase PR to make package upgrades work
[RP: Fixup PR merge conflict]
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
After the recent locale changes there were warnings about many unpackaged files.
Fix this by directing libc-package.bbclass to operate directly on the files in
the sysroot and adding packaging for .debug files in this package.
Also sync up the eglibc and glibc versions of this code more closely.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Replace the hard coded libdir for locale generating to meet the multilib
requirement.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
|
|
*libc's do_package will cost a lot of time due to the locale handing,
which may delay the other recipe's do_package task and affect the build
performance.
This commit moves locale handling into a separate recipe *libc-locale.
[RP: Add fixup with recent eglibc commit conflict for FILES_pn-dbg and PACKAGES]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We don't package /etc/rpc and do_install() makes some effort to remove
that file so as to avoid the "installed but not shipped" diagnostic. But,
due to a typo in the command line, the file wasn't actually being removed
and the diagnostic continued to be issued.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
versions
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
I searched the various classes and looked for copies that should attempt to
preserve hardlinks. This fixes the majority of this copies by switching to
using tar as the copy method. It also has the side effect of preserving sparse
files.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
|
|
{e}glibc should install the scsi/*.h files, which are needed by hal.
Currently hal can build because eglibc-initial (which has its own do_install)
installs the files. In future eglibc will have its own sysroot, so hal
won't build.
BTW: in OE side, eglibc's do_install also doesn't remove the files.
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
|
|
cross-localedef
Along with qemu this provides another option to generate locales for
[e]glibc. The new method is to use cross-localedef with appropriate arch
specific parameters.
The cross-localedef method is found to be 15 times faster than qemu's
emnualted method.
LOCALE_GENERATION_WITH_CROSS-LOCALEDEF : This is new config variable
introduced to selet qemu or cross-localedef method for locale generation.
Thanks to Mark Hatle from Windriver for providing the rich
information for cross locale generation.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
|
This solution is what Mark Hatle recommended.
To disable pseudo, while already running, you need to set:
PSEUDO_RELOADED=YES, and then exec something...
This causes pseudo to disable itself from LD_PRELOAD, and thus fall
out of memory on the exec.
This Fixes [BUGID #226]
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
|
