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>
Made several editing corrections for various terms and phrasings based on
Scott Garman's review.
(From yocto-docs rev: a21ba80151ce82683d45cd67ddb0728d779b007a)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield suggested adding a note near the explanation of creating
a bare clone that suggests if the user already has a linux yocto kernel
Git repo handy they can reference that repo in the 'git clone --bare'
command rather than referencing the upstream source repository as
a way to speed up the process.
(From yocto-docs rev: 132a9cfcef3397677b54eace7831d25f8a321b93)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
1. now refer to the linux 2.6.39-rc1 as the 'latest upstream release
candidate available.
2. Noted where you can find the linux-2.6 kernel - in the meta-kernel-dev
area.
These changes were from Bruce Ashfield's review of an early version
of the Yocto Project Development Manual.
(From yocto-docs rev: 83d6e75e7d5f4d60040c4b7ebb0c7bb11b1b67e8)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bruce Ashfield's review comments indicated that we will be using
linux-yocto-3.0 and not linux-yocto-2.6.37. So I am putting these
changes in to anticipate the 1.1 release.
(From yocto-docs rev: ecbe1c90c5aa65b2dde77ba6094b5956e37d061d)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Had to set to scalefit="1" so this figure would appear correctly in the
PDF version of the manual.
(From yocto-docs rev: 166305f39859e11f15702a8f6eb1f5a524b589c4)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Two additional section placeholders added for changing kernel
configuration and for adding kernel recipes added to the appendix.
(From yocto-docs rev: 27c0ea3dddb652c4367b097b612edbdb76d7725d)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After getting the example in kenerl example appendix working I discovered
much that was wrong in this overview. The overview attempts to generalize
all the situations for kernel modification. These include code changes,
configuration changes, and the addition of new recipes. It also includes
the situation where a developer wants to gather all the changes into a
separate layer for distribution and for when they want to push them up
the tree.
(From yocto-docs rev: 5498d7b38d3a2f14befa82b66af9919a449e0f04)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are some issues with the fact that the build process parses
all kernel .bbappend files whether they are used or not during the
build process. I added an extra build configuration note regarding
editing the .bbappend file. I noted that you either have to edit
every .bbappend file and comment out the COMPATIBLE_MACHINE statement
or simply remove all the kernel recipe append files except the one
you are interested in.
(From yocto-docs rev: ecece911a1623b9b12bb73bab50891fbdea7afbe)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I changed 'linux-yocto-2.6.37.bbappend' to 'linux-yocto_2.6.37'.
Also started a new note.
(From yocto-docs rev: c78a937b9df37f68beee31c51914811ddd4d771f)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I changed 'linux-yocto-2.6.37.bbappend' to 'linux-yocto_2.6.37.
(From yocto-docs rev: 0eb284374ef9dfb26142ae4d0254a0fe4056d0ab)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Had to tweak the viewing area to get two figures to display
correctly in the PDF version of the file.
(From yocto-docs rev: 89b2618e11c05744f54a9fbd39cd899117a2affc)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added the figures/kernel-example-repos.png to the list of tarfiles.
(From yocto-docs rev: 8967a9b8ae6fb27f7c0aeb44c2d04eacba98ed81)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This figure provides a conceptual look at the repos and file structures
needed to run the example. Or, for that matter, to get set up to
modify the kernel.
(From yocto-docs rev: d469449f1d416a6a96bdde297daae68a9f3094e5)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I performed a major re-write of this section that touched all
aspects of it. This was necessary due to the fact I could not get
the example running because of not understanding the repo location
and branch needs to set it up.
(From yocto-docs rev: 160e66d0c8ddf11584c53306def916a45a05f62b)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I separated the section that explains how to set up the poky-extras
git repository. This used to be in the kernel area right after
creating the bare clone and the copy of the bare clone. I thought
it would be better as a stand-alone bulleted item.
(From yocto-docs rev: 4ea917c7218f238e2b0d2bb377a97f4b1f5eb1f6)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added instruction on how to set up a bare clone of the linux yocto
kernel files and then how to create a clone of the bare clone.
Finally added a part about setting up the meta-kernel-dev repository.
This setup should do it for those that want to modify the kernel and
not have to download source files from the upstream everytime they
make a change.
(From yocto-docs rev: 90ae8249d119d5db17507eea37eb6deb0822a682)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
still working on the kernel example.
(From yocto-docs rev: 90c8cb778d3c146f24626a681f05b88bab1e9766)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added a new section for the example that ensures the image for qemu
is available.
(From yocto-docs rev: a3ca52cb7088ec85502b507093082f35f23befd4)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I placed an anchor point in the Index of Downloads bulleted item for
reference from other documents.
(From yocto-docs rev: 7d4f96d20667fbf5f52e25840b39f1994b1c4cd3)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tightened up the section that talks about setting up the environment
and starting qemu. I just added a little more clarification on the
kernel-image variable.
(From yocto-docs rev: 54c037d45ca46c09544dae67793237c76a1205f5)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updated the downloading the filesystem section to have an inclusive list
of image profiles and a reference to more information on that. Also
included more explanation of the two types of image tarballs.
(From yocto-docs rev: 14965cbedd719beb6191771c6dcb92742f4229bf)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I made some edits to the section that shows how to download a pre-built
qemu image.
(From yocto-docs rev: 89127522b09cc201008dc760f8b1397b5ff36e42)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I changed the 'i686' stuff to 'i586' after seeing that it is named that
in the actual index of downloads area. I also tightened up the example
a bit.
(From yocto-docs rev: ab76e8f8aa3d8d24d1fd8ff3b7f8f175b8b8f663)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
various things going on in the kernel example. Far from complete.
(From yocto-docs rev: 0c0548b79589a606f91bdb39e5a2ece71f4c108e)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the section that describes how to get the local Yocto Project files
I was referencing the general section. I have added a more specific link
to the bulleted item that describes how to get these files.
(From yocto-docs rev: 2b03c4d39a83d731581a6cd63a5c9e5c7e4cb57b)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the flow section for the kernel modification section I added a new
step for getting a local copy of the linux yocto kernel files. The section
indicates that you need a local Git repository of the files and then
references back to the Getting Started section for an example.
(From yocto-docs rev: 6601e06635c6f57ddbf8109cc1dfdc8a8e7f74af)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the section that shows how to get various groups of files needed for
using YP I added a bulleted item to show how to clone the linux yocto
kernel files. this section will be referenced from the kernel example
flow section and the kernel example appendix.
(From yocto-docs rev: 4126d1456290d677ab8dc1d02d11aac6eb8add46)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
the user should use Git commands..no probably about it.
(From yocto-docs rev: 84b0b4e8c7b6b89c81503f40ba855e9f624887c3)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.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
Richard Purdie
Scott Rifenbark