freetype-2.4.6/docs/LICENSE.TXT changed a little to describe more clearly
the compatibility about FreeTypeLicense and GPLv2+, but the actual license
remains unchanged: it's still LICENSE = "FreeTypeLicense | GPLv2+".
(From OE-Core rev: 06e0d50a936c01d4f02e7208b7e3784947436462)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the patch since 3.2.2 has integrated it.
(From OE-Core rev: a39c0c022090ba078ba6132ff69f9587fea592be)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1330]
If tcf-agent's do_compile happens before openssl does populate_root, we'll
get such a compilation failure:
framework/channel_tcp.c:34:27: fatal error: openssl/ssl.h: No such file or directory
Thanks Kumar Gala for reporting this!
(From OE-Core rev: 9314d5844a16812bb66e8c9c471ee9fd70a574c2)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1371]
Recently bluez4 was updated from 4.82 to 4.96 and bluez-hcidump can't build:
src/hcidump.c:54:24: error: redefinition of 'ntoh64'.
In 2.1 the duplicated definition of ntoh64 was removed.
(From OE-Core rev: 15a369b4e65fc8068ba7fec70ec24b7c23e7950b)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1345]
The new variable ALL_MULTILIB_PACKAGE_ARCHS contains all the values of
PACKAGE_ARCHS for each multilib variants. The opkg backend now uses this
new value insteald of the PACKAGE_ARCHS to update the opkg indexes and
to generate the opkg configuration files. This allows the normal
packages and multilib packages may be installed into the same rootfs.
(From OE-Core rev: b774bf44ef004276da12a83ebd69715c00b596ac)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bumping the linux-yocto meta SRCREV to pickup new target
configurations and features.
(From OE-Core rev: 110ca8dcaee263bc3c8380bcb91f6ada20655c14)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The explicit setting of version preference to 2.6.37 is
no longer required. All of the qemu targets have been built
and boot tested on 3.0.1 for core-image-minimal and core-image-sato
and are safe for wider build/boot testing.
(From OE-Core rev: 14831b6ba26a6e43a1771a8516d0af145006c504)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was some confusion around the 3.0 version string in the
linux-yocto recipe when the merged version was 3.0.1. Bumping
the version string should clarify what version will be fetched.
(From OE-Core rev: 29017755329ff1ad740fe094a4a89057e9c2a48d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When dynamically setting RDEPENDS, we need to add MLPREFIX to adapt
multilib case.
[YOCTO #1368]
(From OE-Core rev: 2ed808b764f023c074fa3aabef18b4f874cd82c7)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_package task will write information into pkgdata and
do_package_write_rpm will read them out. Take lib32-dates as an example,
one of its RDEPENDS is li32-gtk+, and PKG_lib32-gtk+ = "libgtk-2.0",
these info is stored at:
tmp/pkgdata/x86_64-pokymllib32-linux/runtime/lib32-dates.
Function "mapping_rename_hook" in do_package_write_rpm is to handle
those renamed packages. However before it executes, translate_vers
has stripped the multilib prefix out, making it failed to find PKG_gtk+
value in pkgdata.
This commit moves the strip_multilib out of translate_vers and call it
after "mapping_rename_hook".
[YOCTO #1368]
CC: Mark Hatle <mark.hatle@windriver.com>
(From OE-Core rev: 216a1cfe7973e99e3e79585040e91f7a6e298884)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous logic could only strip MLPREFIX from the first element in
an array, take an example, strip_multilib the [lib32-a lib32-b lib32-c]
will result in [a lib32-b lib32-c]. We need to strip prefix one by one.
This commit change the logic to strip all elements' multilib prefix.
[YOCTO #1368]
CC: Mark Hatle <mark.hatle@windriver.com>
(From OE-Core rev: ca729de4b261e4feba74fdf0b2578890bc80ea90)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"virtclass-multilib" is set to OVERRIDES in multilib.bbclass, remove the
duplicated settings here.
Besides, DEFAULTTUNE has overrided and it can be directly used.
[YOCTO #1368]
CC: Mark Hatle <mark.hatle@windriver.com>
(From OE-Core rev: dc78cdb318671862c5cd15711364c1c4462d9ece)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It requires libx11 and libGL(if enabled GL) for building, which introduce extra
dependence in qemuppc target. Futhermore, qemu's GL code is x86-oriented, thus
some hacks needed for building in qemupcc. For simplicity, just make qemu GL's
code for native only, so that qemu building is okay in world build.
[YOCTO #1011] got fixed.
(From OE-Core rev: e744d4e2d33d914b2ca31be2d4eadab9fbcc3251)
Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nothing in the source refers to libX11 or libXmu so there would appear to be
no good reason for them to be in DEPENDS. It looks as though these are perhaps
a relic from an earlier version which did need those libraries.
(From OE-Core rev: 5d0b45c982b92eecde48cc10dd095927fa38a047)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When CMake is looking for perl, it only searches in the specific directories
that it's told about and ignores ${PATH}. If perlnative is in use, ensure
that the appropriate installation path is added to the list of places that
cmake will look for perl, otherwise it won't ever be found.
(From OE-Core rev: add9e4e30e0b1e0f93479b43ce61953efb90985d)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1050]
I got do_compile failure during building qemux86 image
| ../../../doltlibtool: line 17:
/distro/dcui/0704/pc1/build/tmp/work/i586-poky-linux/libx11-diet-1.3-r2/libX11-1.3/modules/im/ximcp/../../../libtool:
No such file or directory
This is due to not found libtool, but i586-poky-linux-libtool in libX11-1.3
So I disable dolt for solving this problem.
(From OE-Core rev: 710ad20f005cb96a6aabf3f0eb184a254ada1610)
Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes bug [YOCTO #1165]
The /etc/init.d/skeleton doesn't work on minimal image, this is
because of the pidofproc doesn't return "$?" correctly, so store
$? in the variable status would fix it.
(From OE-Core rev: 4d31193a6969df25bb85a9862b7295e85dcec04b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
in the qt4.inc python annomyous code, there is case where package name
is set to "${QT_BASE_LIB}-tool", and FILE_${QT_BASE_LIB}-tool is set to xxx.
here QT_BASE_NAME=qt4. multilib.bbclass will try to rename the FILE_qt4_tool to
FILE_lib64_qt4_tool. unfortunately, there is only FILE_${QT_BASE}-tool, no
FILE_qt4-tool, so FILE_lib64_qt4_tool will not be defined.
to fix this issue, this patch expand the QT_BASE_LIB when assigning the package
name.
FIX [YOCTO #1344]
(From OE-Core rev: b5d381133660fe338796b965131cee39cec01b96)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
using ${QT_BASE_NAME}-dbg as RRECOMMENDS is not correct in qt4-x11-free
case, because ${QT_BASE_NAME}-dbg i.e. qt4-dbg does not exist
this patch fix it by using ${PN}
(From OE-Core rev: d72adf3c4cf3de09d2a0bc6d1b9e7c9fd127bd60)
Signed-off-by: Yu Ke <ke.yu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To enable opengl for libsdl, we need DEPENDS on virtual/libgl. Add a check for
"opengl" in DISTRO_FEATURES and when it's set, "--enable-video-opengl"
and "virtual/libgl" will be added into EXTRA_CONF and DEPENDS.
(From OE-Core rev: c28e62125209aa2e9606f094a4100ac1107fdd28)
Signed-off-by: Jiajun Xu <jiajun.xu@intel.com>
Acked-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename libsdl-nativesdk to libsdl to enable target version. libsdl
is needed in some graphics testing.
(From OE-Core rev: 2d719f69676e9a64f7baf34f058441b887dfa14a)
Signed-off-by: Jiajun Xu <jiajun.xu@intel.com>
Acked-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it possible to include dbus in a non-X11-equipped DISTRO.
(From OE-Core rev: abf2ab7b4d6e9f615f86ba84e684ae0753c602a8)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it possible to build cairo-using apps without X11.
(From OE-Core rev: ba22cfac56120d001a53d33aee3b8eb3feda2786)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This stops (most) x11 packages leaking into a non-x11 distro by mistake.
(From OE-Core rev: 2f94ff4fdb66755ba2448794baea19315ff96273)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nothing in pixman actually uses libx11, so no need to DEPEND on it.
(From OE-Core rev: e3432253da5af35345a978c7435e31fee6938217)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License is GPLv2 change it.
Defining PERL for native intltool is not needed anymore
(From OE-Core rev: d4b4ecb33c727ed54ab52de79e69cd3f0d14fb35)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All the other utilities get deleted as they should not be packaged,
delete this one as well.
(From OE-Core rev: 2c036c71cf0d978fac2ddc4abfb702d42af6bcda)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
QML components from Qt were installed to ${prefix} before and never got
packaged. This is now fixed and QML components are now installed into
${libdir}/${QT_DIR_NAME}/imports and packaged into qt4-*-qml-plugins
package.
Additionally qmlviewer and the examples/demos are now dependent upon
these plugins as needed.
Originally based on OE commit 4adf97be8c5b5f71ad92095a19968af534baa9e2
by Simon Busch <morphis@gravedo.de>
(From OE-Core rev: 49c43e2bea64f70a22a2741ea280bd1c13e5110a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These tools are required to build some external utilities (such as those
found in KDE). We avoid building qdbus and qdbusviewer as these are
not required.
(From OE-Core rev: 11f456f4f5c1d4b2aad93856ff6cbb4d7ce3969e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Installs native versions of the Qt libraries in addition to the tools,
allowing compilation of external native tools that require Qt libs.
PROVIDES qt4-tools-native so it should be a drop-in replacement.
Developed with reference to the corresponding qt4-native changes in OE.
(From OE-Core rev: a6fd9b8104e8d3cbfce0376811aeeef746ad6889)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bug fixing [YOCTO #1236].
1. Collect all the values for RTLDLIST for the current multilib
configuration to modify the ldd scripts.
2. Collect all the values for KNOWN_INTERPRETER_NAMES for the current
multilib configuration. Set the correct ld.so names for ldconfig to deal
with the multilib configuration.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. Added variable MULTILIB_VARIANTS to store all the instance variants
for multilib extend.
2. Added function all_multilib_tune_values to collect the variable
values for all multilib instance.
3. multilib bbclass handler will save the orignal value of all variables
defined in MULTILIB_SAVE_VARNAME.
(From OE-Core rev: 18bba910e04bff75460f408e4557d4bae21ad592)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The old valgrind package do not support for Linux kernel 3.x, only for
kernel 2.4 and 2.6. Now adding the configuration to the configure.in
file to support Linux kernel 3.0.
This commit fixes the problem in valgrind [YOCTO #1129]
(From OE-Core rev: 5fc1e6d27f52e2032aa7a8ca20bb90d939d03c77)
Signed-off-by: Lin Tong <tong.lin@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Added new recipe 4.96 and removed 4.82 version and its files.
(From OE-Core rev: 000d5244e21837338614ef4450f54c8744fffcd6)
Signed-off-by: Noor Ahsan <noor_ahsan@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using a tag, like v0.73, forces network access to resolve a
commit ID. Use the corresponding commit ID in the recipe.
(From OE-Core rev: d126e22f6b3f27196144f87e22b36ebccd6dea65)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PPC e5500 is a 64-bit core so we add both a 32 and 64-bit set of
tune files to allow for:
* pure 32-bit build
* pure 64-bit build
* 32-bit base, 64-bit multilib
* 64-bit base, 32-bit multilib
(From OE-Core rev: 60286934715c5f7f27d539f4a43a7226488ef963)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need --with-cpu based to glibc to get proper support on 603e & e500mc
to pickup proper math libs to deal with sqrt. These core do not
implement the fsqrt[s] instructions that the normal PPC math libs
utilize.
This causes use to not set AVAILTUNES specifically to the sub-arch only
as we arent generically compatiable.
(From OE-Core rev: 078699cb8c707830c86b55787fd535d87171388e)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Document the non-obvious bits of using the recipes-rt recipes.
(From OE-Core rev: 2c86e636972bd02b35523b36bc81a2765f430f70)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Keeping the rt recipes in their own layer has led to maintenance issues,
particularly with the linux-yocto-rt recipes. As these kernel types are part of
the same linux-yocto source repository, it seems reasonable to include the rt
kernel recipes alongside the standard recipes. A new recipes-rt directory for
the other recipes provides adequate separation and eliminates the need for a
separate layer.
As there is no meta-rt/conf/layer.conf to force the kernel, users must now
specify the rt kernel in their local.conf or in the machine.conf:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
The merging of the rt recipes into the core also eliminates complications with
multiple layer dependencies for new BSP layers. Having to either separate RT
BSPs from standard BSPs or force users to add meta-rt to bblayers even when not
building an RT BSP (because the RT BSPs in the same layer would fail to parse
without it) was sub-optimal at best.
(From OE-Core rev: bafaaad264fe3e745c714951ddcf2784d33b755a)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1325] [YOCTO #1366]
Packages that were in the PACKAGE_ATTEMPTONLY and SUGGESTS were not
being properly found, which was causing image creation failures.
In PACKAGE_ATTEMPTONLY, when an item was not found, it caused an
error. This should have been a note, followed by skipping the
package.
The SUGGESTS processing was simply broken. It was using a
non-existant function, due to an apparently typo.
In addition to the above, the MLPREFIX processing was not being
done properly, preventing multilib packages from working in this
with PACKAGE_ATTEMPTONLY. (SUGGESTS doesn't need this as the names
are munged when creating the packages.)
(From OE-Core rev: 4fb6723ab1ee14cf539f0ef2df63a3ee1b978de6)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. We dont need the aclocal patch as this will be handled by automake
2. We need to update xcb-proto.pc.in to know about ${libdir} since
we'll end up with something like:
pythondir=${libdir}/python2.6/site-packages
(From OE-Core rev: 4de2ba0eeaefbd6813443c6906108b815af9e109)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As we tweak libdir we need python libs that utilize configure to respect
it setting. By updating the python.m4 template, when we regen automake
files they will than respect the setting of libdir which is standard for
any autotools based recipe.
(From OE-Core rev: d300cfe603b00fc963f7ed874563016fcbcc47a8)
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #1151]
Change the offset from the beginning of the disk to aligne the blocks.
In this script, we use mkfs.ext3 to create file system after partition, but we use mkpartfs to create file system repeatly,
and get some warnings about choose another specific tools to create file system for reliability.
So use mkpart instead of mkpartfs and only use mkfs.ext3 to create file system.
(From OE-Core rev: 67c9804e0416defb7c3f69bd02bbae3710e5be0a)
Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When constructing the /etc/rpm/platform file, we need to ensure that
the any, all, and noarch platforms will allow any "linux" variant to
be installable, not just matching variants.. i.e.
arm-oe-linux-gnueabi should be able to install noarch-oe-linux
Also ensure that we pass the full canonical arch via the --target=
parameter. This allows us to define the proper platform settings
for all packages.
(From OE-Core rev: c6bb9445de90cfb46db9c40842dbe1bfbb5b8ce8)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dexuan Cui
Lianhao Lu
Bruce Ashfield
Dongxiao Xu
Zhai Edwin
Dmitry Eremin-Solenikov
Phil Blundell
Xiaofeng Yan
Robert Yang
Yu Ke
Jiajun Xu
Khem Raj
Paul Eggleton
Lin Tong
Noor Ahsan
Darren Hart
Kumar Gala
Mark Hatle
Mei Lei