Cleans up the packaging by moving libasound.so.2 back into the alsa-lib
package which was previously empty.
Previously, it was difficult to create an image that had libasound.so.2,
then create an SDK from that image that had the proper development
files, because the only way to get libasound.so.2 was to do:
IMAGE_INSTALL += "libasound"
This however caused a problem because all of the development files that
would be desired in the SDK were located in alsa-lib-dev, which wouldn't
be included because alsa-lib wasn't included, and it was impossible to
include alsa-lib because it was an empty package that was culled.
(From OE-Core rev: 6c3438a62d10f155cd6a391bdb2f1939fc4774ec)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 30352f3d84)
Change-Id: I2fb065b7e00569ba3a6aac631ac863999455bfb2
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We assume that LIC_FILES_CHKSUM is a file: URI but don't actually verify this,
which can lead to problems if you have a URI that resolves to a path of / as
Bitbake will then dutifully checksum / recursively.
[ YOCTO #12883 ]
(From OE-Core rev: e2b8a3d5a10868f9c0dec8d7b9f5f89fdd100fc8)
(From OE-Core rev: a5db618986746bf9082c4b3cbdac4e523328432e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bzip.org domain expired and is now a holding site for adverts, so we can't
trust a tarball that appears on that site (luckily we have source checksums to
detect this).
For now, point SRC_URI at the tarball in the Yocto Project source mirror, but
set HOMEPAGE and UPSTREAM_CHECK_URI to the sourceware.org/bzip2/ page which
apparently will be resurrected as the new canonical home page.
(From OE-Core rev: 9e291d9923efc988abe8689c64bafbb29da06339)
(From OE-Core rev: 1bd48516cc3f65e860a2d8a8a3c6cee56c8332a1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building with `clang -target bpf` using the
multilib_header, a recursion was unavoidable because
bits/wordsize.h would #include itself, still lacking
a definition for __MHWORDSIZE or __WORDSIZE.
(From OE-Core rev: 70b41b3c335a80b4ac243f468f22331d261299db)
(From OE-Core rev: b4738c5cf68a3a5d38dcd42f5b8361378f247db0)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As reported by ChenQi, leaving bits/wordsize.h out of being
multilibbed introduced a problem in building the SDK for
arm64:
Error: Transaction check error:
file /usr/include/bits/wordsize.h conflicts between attempted installs of lib32-libc6-dev-2.27-r0.armv7vet2hf_vfp and libc6-dev-2.27-r0.aarch64
This effectively reverts commit a74c77d6.
(From OE-Core rev: 90ad502bf8faa233e25cf297c1eeefcb0367aea3)
(From OE-Core rev: 056ae940da49b38890c2960651f0fdb5331a5fac)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support for variables suffixed with package names, e.g., PKGV_foo, was
removed in commit 3d2c87c4, which broke support for recipes that set
other versions on their packages than what is in ${PV}.
(From OE-Core rev: 38f8284212370999e1e7b0f6559f7cd786e80d1a)
(From OE-Core rev: b750b310afacf298fc450e71d116ed20eef16428)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a package name exists in runtime-rprovides, lookup-recipe and
package-info would finish after printing information about that
package even if more packages were specified.
(From OE-Core rev: 32c2a2ddb1614f978f511dfccb6cc3e9398df841)
(From OE-Core rev: 8ec64f613266987417ca4941b55b988b50af7aff)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's possible that downloading file from updateserver fails. In
this case, we should error out instead of continue.
We have users reporting unexpected behavior of 'devtool sdk-update'.
When an invalid url is supplied, e.g., `devtool sdk-update http://invalid',
the program reports 'Note: Already up-to-date'.
This is obviously not expected. We should error out in such case.
(From OE-Core rev: 449564783dfb162536a2f772b3a8704973221e0f)
(From OE-Core rev: 61a56f6c5db9a3575a21f0c206f0fa760cf005e0)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
poky.ent - updated variables for 2.5.1
mega-manual.sed - updated string from "2.5" to "2.5.1"
<manual>.xml - updated manual revision tables for 2.5.1
and September 2018 date
(From yocto-docs rev: a47382f00ad1a5a1df02ffa3dead7a0bd597bf45)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Took out an occurrence of PACKAGE_WRITE_DEPENDS
(From yocto-docs rev: e983c3215139b566ea02df6e6160b05fdcbce081)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I made some re-writes for clearity.
(From yocto-docs rev: 45e710923afb45066383877252af79faf3b2f5fc)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On second thought, the list I turned into a bullet list from the
previous commit was a bit hasty. That list is order dependent.
Reverted the list.
(From yocto-docs rev: 24a77078af0e7a59dd180bdfe6a29afbaefdffcf)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The list appears to be not a numbered list. Fixed that. Also, provided
better wording around "exposing" the sstate-cache.
(From yocto-docs rev: e1f8c9bf3ef7028b48b38801557292434c872419)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Step 1 of the "Providing Updates to the Extensible SDK After Installation"
section really did not do much for the reader regarding setting up a
HTTP or HTTPS directory. I added more detail on how to generally do
that.
(From yocto-docs rev: b90de53859545a835629a56eab08fa58479c36ff)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two sections that deal with this topic. One is from the
standpoint of a user using a 3rd party published and installed
extensible SDK ("Applying Updates to an Installed Extensible SDK").
The other is from the standpoint of a person providing Extensible
SDKs for consumption ("Providing Updates to the Extensible SDK
After Installation"). These sections needed some closer examination
regarding fully describing what was going on. I provided some
re-writes to both.
(From yocto-docs rev: 62028ea4df684e495e78d00a440318d061098f15)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The title for the section on how to effect changes to an installed
extensible SDK is better suited as "Providing Updates to the
Extensible SDK AFter Installation."
(From yocto-docs rev: 382c172fd9a51cd4c650333549210aa760ea9774)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In "Providing Updates After Installing the Extensible SDK" section,
Step 1 had a bit of a grammar error. Not technically, but it
could have been written better. I fixed that.
(From yocto-docs rev: f6710a7047c215f9a1a989b9a009399405770c06)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added more information on how this is done. Still could use a bit
of detail on how you actually do it.
(From yocto-docs rev: 7a035ffb4443f7920521ccd918ec844d1ca118e5)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I provided some real detail on this variable. It was woefully brief.
(From yocto-docs rev: 6b40243984b7cc69a291b6f90ed04b45b7ce3ac5)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I added a cross-reference to the "DISTRO_NAME" variable as it is
the long version of the distribution name.
(From yocto-docs rev: c707da8121171cc81e0d07ac14369b0045de5119)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I updated this section with clearer text.
(From yocto-docs rev: bb0e6613b7dbe7f8c9ca80a64ee9c67a74e01fc1)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Made improvements to this section and tied the variables together
for the explanation.
(From yocto-docs rev: 592abe8fe11389b58e8c0cf7991a400bdd515b16)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Wording did not match that of similar SDK variables.
(From yocto-docs rev: 6fab0bbc62e7f9caf020718a4a8fd047b9fb450f)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Put in a cross-reference to the section in the sdk-manual where it
talks about customizing the configuration of the extensible SDK.
(From yocto-docs rev: 23e4a2d0f461a8c672aa3780965ca4e30d1aac50)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added information on the class in which the default is set. Also,
put in a reference for more information on customizing the
extensible SDK configuration.
(From yocto-docs rev: 1ca9f8dd90cccb4692c16d7757b80bfd50237495)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enhanced this description by indicating the class that it is set in
and by including a pointer back into the sdk-manual where filters
are described for extending the extensible SDK.
(From yocto-docs rev: 22dcaf2c75532f45111b79db067edfc92212441e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added more detail including the class that sets the default variables
for exclusion and the list of actual variables that are excluded by
default.
(From yocto-docs rev: 7764a54add2911c2da8174e48e4d3166a873d63a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This figure had changed. I updated the file and folder hierarchy.
Also fixed some wording.
(From yocto-docs rev: 40e89997f50fdaecee88c8c98e21cc212bf1ed13)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The figure was incorrect for the installed file and folder hierarchy
for a standard SDK. I updated it. This figure goes in both the sdk-manual
and the mega-manual.
(From yocto-docs rev: c21d76b885afedafe7b866d9f4997633a776902c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Verified a good example and updated the text to match that example.
(From yocto-docs rev: 8655662b1f031463fafcf11fcd22243a75e817f8)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The value of SDKMACHINE must match the architecture of the machine
on which the SDK installer is being built if you are building an
installer for an extensible SDK. I added a note to this effect.
(From yocto-docs rev: 8720b3ea9e7260f891db1be46fb756aba09d5f51)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
