Compare commits

..

383 Commits

Author SHA1 Message Date
Andre McCurdy
6717d19848 mklibs-native: update SRC_URI
The upstream oe-core recipe fixed similar fetcher issues by switching
to a specific debian snapshot version. However, the debian snapshot
doesn't provide mklibs 0.1.38 so fetch from yoctoproject.org mirror
instead.

(From OE-Core rev: bad46f25ec5d0069d7274e22662b71ba9a9753c4)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Andre McCurdy
aeb31e09f0 netbase: update SRC_URI
The upstream oe-core recipe fixed similar fetcher issues by switching
to a specific debian snapshot version. However, the debian snapshot
doesn't provide netbase v5.2 so fetch from yoctoproject.org mirror
instead.

(From OE-Core rev: ac617c2802c781bdc1516d48987b3e9458270556)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Andre McCurdy
26f0c306cb lsof: update SRC_URI
The official lsof ftp site rejects download attempts from hosts for
which it can not perform a DNS reverse-lookup. See:

  https://people.freebsd.org/~abe/

Fix for long download timeout and warnings from the bitbake fetcher.

(From OE-Core rev: 65887209baf4c97241716621fd1609999a1fd76f)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Andre McCurdy
d65bcef0ae libproxy: update SRC_URI
Google Code has been shut down so libproxy tarball needs to be
fetched from elsewhere.

(From OE-Core rev: ca015a8bbc3cca41ed5fec58cf37c278ed07d084)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Andre McCurdy
f1729cdbfa dpkg: update SRC_URI
The upstream oe-core recipe fixed similar fetcher issues by switching
to a specific debian snapshot version. However, the debian snapshot
doesn't provide dpkg v1.17.4 so fetch from yoctoproject.org mirror
instead.

(From OE-Core rev: f1dd3d54f1b104e0ab3d3857c4cdc9f6f1ecde9f)

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Maxin B. John
925e46623a ossp-uuid: use snapshot.debian.org for SRC_URI
Using ${DEBIAN_MIRROR} for SRC_URI doesn't work very well as that will
only contain releases that are currently in Debian. So, move all of SRC_URI
to the .bb so it can use snapshot.debian.org instead, and set
UPSTREAM_CHECK_URI to ${DEBIAN_MIRROR} so upstream release checking continues
to work.

[YOCTO #10040]

(From OE-Core rev: 1194231ad4d3076824a84a92004ced13379d1983)

Signed-off-by: Maxin B. John <maxin.john@intel.com>
(cherry picked from commit 1b38ad4cb8faeb86c5e8cb6b7201194722c5ef31)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Alexander Kanavin
b8603a494d ossp-uuid: update SRC_URI to not use Google Code
Google Code is shutting down so tarballs will be fetched from a Debian mirror
instead

(From OE-Core rev: d8a3f404f2c54ce3f3aae15f1fc3fd4dcbdc1424)

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 779c53911da663f06437e8a06c9a8c361d614fe6)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Robert Yang
dc2ee2feb7 mailx: fix SRC_URI
The old one is not available any more.

(From OE-Core rev: 6edc2a0bc5f579893ee40fbcf39bcb9f8cbf1ee8)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 3569d434e754a62ec998fbf48380d653d1524dc4)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Robert Yang
9901828b0d dosfstools: fix SRC_URI
Fixed:
WARNING: Failed to fetch URL ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-2.11.src.tar.gz, attempting MIRRORS if available

And add a HOMEPAGE for it, there is no dosfstools 2.11 on its official
page (but 3.x).

(From OE-Core rev: 9e7710c8f021b7e88f1e8d16846b707e62fb3d35)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
(cherry picked from commit cba73a598abc396fae4fb582be98fc04cb2a580f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Robert Yang
ad89b1fe80 base-passwd: fix SRC_URI
Fixed:
WARNING: Failed to fetch URL ftp://ftp.debian.org/debian/pool/main/b/base-passwd/base-passwd_3.5.29.tar.gz, attempting MIRRORS if available

(From OE-Core rev: 9707527623a1e3bb7035bc1bd1be96619846cabc)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
(cherry picked from commit 9ac88e3a9ac36ed83f01ac21db57a3c01a24385e)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Chang Rebecca Swee Fun
ff505d781d cryptodev-linux: update SRC_URI
Gna! project announced that the download site from gna.org HTTP server
will soon be closing down. We have verified that the site is no longer
accessible without network proxy cache. We need to update SRC_URI to
point to new alternative (nwl.cc HTTP server) in order to avoid fetcher
issues in future.

[YOCTO #11575]

(From OE-Core rev: f28d763bd73275068ed0a5a7b8efba073c5f8a62)

Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dc8b21ae0ed3bceb9f3df4f6cd8f8f55b9c306fb)

Tweak commit to apply to older cryptodev 1.6 recipe in OE 1.6

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Richard Purdie
905938d0a1 pigz: Update SRC_URI
Upstream have released a new tarball and removed the old one. Revert to
the Yocto Project source mirror instead, preserving the upstream version
check.

(From OE-Core rev: de49fa8db38ea4e2d925c85b3cce252191916035)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 839b17ffd96abff3e9cf47fb4a6d680637c865b1)

Tweak commit to apply to older pigz v2.3.1 recipe in OE 1.6

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Robert Yang
1b58412449 stat: fix SRC_URI
The old SRC_URI is redirected to the new one, fixed:
WARNING: Failed to fetch URL ftp://metalab.unc.edu/pub/Linux/utils/file/stat-3.3.tar.gz, attempting MIRRORS if available

(From OE-Core rev: c7bb712d0a5f1333eb97a515e8f839d606141274)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 45034239c7e38ec991aa75d7c30417c22bfdef28)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Alejandro Hernandez
2cd70c9150 kernel: Added bc-native as DEPENDS
The makefile checks for bc during for compilation

[YOCTO #6781]

(From OE-Core rev: a3778df1699ac8a1e80cae6886b41bfcbbebc016)

Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c067e52cffe002de3b39aa1bced308dd532859c1)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Yue Tao
9e9bb64fb5 setserial: add missing depends on groff-native
[YOCTO #6526]

setserial needs groff-native to build

(From OE-Core rev: 8f7d4a59c22cd90050bb3597daf89785f4ff5f71)

Signed-off-by: Jonas Zetterberg <jonas.zetterberg@windriver.com>
Signed-off-by: Yue Tao <yue.tao@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1a1d1d89b490703ec163b82ba93f10a7d3e93270)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-09-11 10:48:04 +01:00
Javier Viguera
39ec0738d4 eglibc: security fix CVE-2015-7547
CVE-2015-7547: getaddrinfo() stack-based buffer overflow

Backport patch from GLIBC-2.20 to EGLIBC-2.19.

(From OE-Core rev: a4e80e831cd13e6418af0d770c5dbd5b9270eaa5)

Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-11 22:02:13 +01:00
Paul Barker
3d7df7b5b5 package_manager: Fix BAD_RECOMMENDATIONS for opkg
In package_manager.py, when using opkg as the packager, the command 'opkg <args>
info <pkg>' is called to get information about each pkg in BAD_RECOMMENDATIONS
in a format that can be written to the status file. The 'Status: ...' line is
modified and all other lines are passed through. Changing the verbosity level
argument for this command will change what it written into the status file.
Crucially, with the default verbosity level, no blank lines are being printed by
the opkg command and so no blank lines are being written to the status file to
separate each package entry.

The package parsing code in opkg expects package entries in the status file to
be separated by at least one blank line. If no blank line is seen, the next
package entry is interpreted as a continuation of the last package entry, but
the new values overwrite the old values.

So with the default verbosity level, a blank line follows some package entries
and these are parsed. The others are dropped due to the lack of blank lines. As
the verbosity increases, more debugging messages add blank lines and more
packages are parsed.

The solution to ensure that this works correctly regardless of the verbosity
level is simply add a blank line after the output of 'opkg info' is written to
the status file, ensuring that the next package is separated from the current
package.

[YOCTO #6816]

(From OE-Core rev: d0326ff5abde814da8647debfd559fcb9aede3a4)

Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Cc: Chris Carr <chris.carr@ge.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-19 21:32:01 +00:00
Richard Purdie
0b1be9dc67 bitbake: cooker: Ensure bbappend files are processed in a determistic order
self.appendlist is a dict and as such unordered. This can lead to cases
where appends with different names (e.g. x_%.bbappend vs. x_123.bbappend)
can be reordered in application which in turn reorders the variables
that those bbappend files might touch. Reorderd variables changes the sstate
cache signatures causing real world issues.

To avoid this, use a list for the append files instead.

This patch is conservative and just adds a new data structure alongside
the existing one and uses it to resolve the core issue. Later patches
(post release) can handle some of the wider but less problematic ones
(e.g. issues in bitbake-layers flatten).

[YOCTO #7511]

(Bitbake rev: d9a695e9e546cf3a158c88b0ecf2ecc132fb52e5)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-01-17 17:52:14 +00:00
Martin Jansa
b9ec9f7425 squashfs-tools: enable building unsquashfs and fix squashfs-4.2-fix-CVE-2012-4025.patch
* build unsqaushfs, useful when debuging corrupt squashfs from
  mksquashfs
* squashfs-4.2-fix-CVE-2012-4025.patch fixes CVE in unsquashfs which we
  weren't building and it actually breaks building it, because someone
  missed squashfs_fs.h change from the original change
* add git headers in all patches and fix references to new github
  repository

(From OE-Core rev: e1a2540227250d854d5bba278634bcc9e7572cda)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-16 20:45:25 +01:00
Tudor Florea
9e4aad97c3 openssl: upgrade to 1.0.1p
This upgrade fixes CVE-2015-1793
Removed openssl-fix-link.patch. The linking issue has been fixed in openssl.

(From OE-Core rev: d140c1b13c3f3a7e2d982b5aa8b11c5e0c23c158)

Signed-off-by: Tudor Florea <tudor.florea@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-07-15 15:25:46 +01:00
Beth Flanagan
240da75616 poky.conf: DISTRO_VERSION bump
We missed the DISTRO_VERSION bump for the 1.6.3 release. I've opened
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7836 to
ensure that this doesn't happen again.

(From meta-yocto rev: d1dea3bd544788aaec977908c5d0ca1f0e6d9e56)

Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-06-03 16:41:56 +01:00
Richard Purdie
b2ba41b575 build-appliance-image: Update to daisy head revision
(From OE-Core rev: 5a577ec878a15f3caaf4893b819825ffb8c81266)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-13 13:28:56 +01:00
Richard Purdie
56bd68e82c security_flags: Fix typo for cups
(From OE-Core rev: 327da66bb4d0b2a219e8a1b0805b504b269b22d9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-13 08:52:06 +01:00
Martin Jansa
0fb598c6b9 powertop: Fix build for !uclibc
* EXTRA_LDFLAGS isn't defined for !uclibc and configure fails
  when it reads it unexpanded, see config.log snippet:

  configure:4177: checking whether the C compiler works
  configure:4199: i586-oe-linux-gcc  -m32 -march=i586 --sysroot=/OE/sysroots/qemux86  -O2 -pipe -g -feliminate-unused-debug-types  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed ${EXTRA_LDFLAGS} conftest.c  >&5
  i586-oe-linux-gcc: error: ${EXTRA_LDFLAGS}: No such file or directory
  configure:4203: $? = 1
  configure:4241: result: no

(From OE-Core rev: fd6418949249be252e4831ecf88f84297f81eaeb)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Backported from OpenEmbedded Dizzy branch, commit
c8f9b5c9a8e5179c2013f25decd6a5483df9c716.
Signed-off-by: Jens Rottmann <Jens.Rottmann@ADLINKtech.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-12 15:46:59 +01:00
Jonathan Liu
b0c1820261 systemd: fix /var/log/journal ownership
The ownership needs to be explicitly set otherwise it inherits the user
and group id of the build user.

(From OE-Core rev: 0752c79282b1cc9699743e719518e6c341d50a3a)

(From OE-Core rev: e64cee7ccf9dedbadc3a63e4ed3eb15172ef4403)

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Conflicts:
	meta/recipes-core/systemd/systemd_219.bb
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-12 15:46:59 +01:00
Armin Kuster
ccd470ba5f eglibc: fix two security issues.
The includes two CVE fixes:
CVE-2012-3406
CVE-2014-7817

(From OE-Core rev: fed4d140da67fc51d54b02df83882177f6ddab10)

Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:52 +01:00
Sona Sarmadi
90a33dde44 e2fsprogs: CVE-2015-0247
Fixes input sanitization errors.

References
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=f66e6ce4
http://www.ocert.org/advisories/ocert-2015-002.html

(From OE-Core rev: f3e5b052689b2eba30e26903e964791f92241e65)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:52 +01:00
Sona Sarmadi
b9da1f441b elfutils: CVE-2014-9447
directory traversal in read_long_names()

Reference
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9447

Upstream commit with the analysis:
https://git.fedorahosted.org/cgit/elfutils.git/commit/?id=147018e729e7c22eeabf15b82d26e4bf68a0d18e

(From OE-Core rev: 6e7badf6819f372bd6dced191c7fda9748062126)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:52 +01:00
Sona Sarmadi
ccbb7ef72f coreutils: parse-datetime: CVE-2014-9471
Memory corruption flaw in parse_datetime()

Reference
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9471

(From OE-Core rev: 0b13fbf3f9b4419141445b381ffa9445af6e52ab)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:52 +01:00
Sona Sarmadi
cafdccb29c libpng16: CVE-2015-0973
Fixes CVE-2015-0973 (duplicate of CVE-2014-9495), a heap-based overflow
vulnerability in the png_combine_row() function of the libpng library,
when very large interlaced images were used.

Upstream patch:
dc294204b6/

External Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0973
http://seclists.org/oss-sec/2014/q4/1133

(From OE-Core rev: 10c8aeebca301ffd853e75df3f9c1d16d0352d76)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:51 +01:00
Sona Sarmadi
13eda67126 Qemu: CVE-2014-2894
Fixes an out of bounds memory access flaw
in Qemu's IDE device model

Reference
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2894

(From OE-Core rev: 5f7cdf1e1212af5e3dcf36c8817c63cc853b1a91)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-01 12:34:51 +01:00
Scott Rifenbark
91c507ce1c documentation: Updated manual revision table to new date
Using May of 2015 now.

(From yocto-docs rev: b5ade15ae89769e6e9a082e48d635a09ecdcc116)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-28 16:31:07 +01:00
Sona Sarmadi
97e9be8130 python: CVE-2014-7185
Integer overflow in bufferobject.c in Python before 2.7.8 allows
context-dependent attackers to obtain sensitive information from
process memory via a large size and offset in a "buffer" function.

PoC:

(From OE-Core rev: 2590eb53a6dac90cba52edd09ea56a6bdf4c4533)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-27 15:20:45 +01:00
Paul Eggleton
523aaea8e2 bitbake: lib/bb/utils: add safeguard against recursively deleting things we shouldn't
Add some very basic safeguard against recursively deleting paths such
as / and /home in the event of bugs or user mistakes.

Addresses [YOCTO #7620].

(Bitbake master rev: 56cddeb9e1e4d249f84ccd6ef65db245636e38ea)

(Bitbake rev: aa56ab0593b36abb4d7d2303ab19eb80d9cee93d)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-24 11:33:15 +01:00
Anders Darander
e625a82af2 bitbake: fetch/git: Remove a possible trailing '/' in subpath
If the subpath parameter to the git fetcher ends with a trailing '/',
 bb.utils.prunedir() will be called on '/'...

Fixes [YOCTO #7620].

(Bitbake master rev: 380a3fb372c8b0a53dd7528562e6e7a222dc76ef)

(Bitbake rev: fad3ea40ebaf2cdcb981fb38bd755015e50fc9a5)

Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-24 11:33:15 +01:00
Brendan Le Foll
efde5a1303 openssl: Fix x32 openssl patch which was not building
x32 builds where broken due to patch rebase not having been done correctly for
this patch

(From OE-Core rev: a2966949e68bbdce8d0a0fd5946d078b84ae63e9)

Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-15 15:56:08 +01:00
Richard Tollerton
f1bb6acacc bitbake: data.py: fixes bad substitution when running devshell
Running bitbake inside make results in the exported environment variable
MAKEOVERRIDES="${-*-command-variables-*-}", which the shell chokes on
when trying to expand it. But of course, it probably shouldn't have been
trying to expand it in the first place -- so just escape the dollar
sign.

(Bitbake rev: 18cd0ce6a55c9065c3f1bf223b47d817b5efcd8f)

(Bitbake rev: 012fb876c1cf0b3aeee3c8c168af0a8947518246)

Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-11 16:27:21 +01:00
Scott Rifenbark
7effa6edd0 ref-manual: Corrected the "package_rpm.bbclass" section.
A cut-and-paste error had left a "package_deb" string in the
first sentence of the section.  Replaced with "package_rpm."

Reported-by: Geoffroy VanCutsem <geoffroy.vancutsem@intel.com>
(From yocto-docs rev: 1197367b394d4d2267ed1ce4fefdd55b9efae621)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-10 14:28:58 +01:00
Richard Purdie
02e603e48c Revert "file: Update CVE patch to ensure file gets built correctly"
This reverts commit ece58a88ef905e42de4b8b690106b553ccaa9f30.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-28 10:56:59 +00:00
Richard Purdie
2d80a6bc8a file: Update CVE patch to ensure file gets built correctly
If we touch both files, we can end up in a situation where magic.h should be
rebuilt and isn't. The easiest fix is not to touch the generated files which
ensures the timestamps are such that it is always rebuilt.

(From OE-Core rev: ece58a88ef905e42de4b8b690106b553ccaa9f30)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-28 10:45:35 +00:00
Brendan Le Foll
159f66aea7 openssl: Upgrade to 1.0.1m
Security update, some patches modified to apply correctly mostly due to
upstream changing indentation/styling

* configure-targets.patch updated
* fix-cipher-des-ede3-cfb1.patch updated
* openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch updated
* openssl-avoid-NULL-pointer-dereference-in-dh_pub_encode.patch removed as no
merged with 3942e7d9ebc262fa5c5c42aba0167e06d981f004 in upstream

(From OE-Core rev: 248dec5e550cfcaaaa479a5bff9b79ba5cd0765d)

Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-25 15:05:42 +00:00
Javier Viguera
6b8f7999c3 utils.bbclass: fix create_cmdline_wrapper
Similar to commit 4569d74 for create_wrapper function, this commit fixes
hardcoded absolute build paths in create_cmdline_wrapper.

Otherwise we end up with incorrect paths in users of this function. For
example the 'file' wrapper in current released toolchain:

exec -a
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-fsl-arm/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-file/5.18-r0/image//opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/bin/file
`dirname $realpath`/file.real --magic-file
/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc
"$@"

(From OE-Core rev: 49ab89eb9f83388e99069a4b53bdc4cba22bb6f3)

(From OE-Core rev: 8503dee5a42fc0dc6dc6c79ce316aba1c91da6d1)

Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-11 14:41:38 +00:00
Jonathan Liu
827dc7f12c qt4: add patch for BMP denial-of-service vulnerability
For further details, see:
https://bugreports.qt.io/browse/QTBUG-44547

(From OE-Core rev: 4c61140ae04b3957bec12b18863d8ff39b81b396)

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-10 11:56:17 +00:00
Armin Kuster
7c0d759c55 binutils: several security fixes
CVE-2014-8484
CVE-2014-8485
CVE-2014-8501
CVE-2014-8502
CVE-2014-8503
CVE-2014-8504
CVE-2014-8737

and one supporting patch.

[Yocto # 7084]

(From OE-Core rev: 859fb4d9ec6974be9ce755e4ffefd9b199f3604c)

(From OE-Core rev: d2b2d8c9ce3ef16ab053bd19a5705b01402b76ba)

(From OE-Core rev: 2343cdb81ddef875dc3d52b07565b4ce9b3a14a4)

Signed-off-by: Armin Kuster <akuster808@gmail.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>
2015-03-10 11:54:04 +00:00
Scott Rifenbark
9ca89fe495 documentation: Prepared for YP 1.6.3 doc release.
Updated the following:

 * poky.ent - bumped the variables for 1.6.3
 * <manuals>.xml - updated the manual revision tables for
   June of 2015.
 * mega-manual.sed - Rolled the 1.6.2 string to 1.6.3 so links
   in mega-manual will work locally.

(From yocto-docs rev: b3048611d268d129e9e1244d8dab6203519aa361)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-10 11:08:00 +00:00
Paul Eggleton
c82164fd0a lib/oe/package_manager: support exclusion from complementary glob process by regex
Sometimes you do not want certain packages to be installed when
installing complementary packages, e.g. when using dev-pkgs in
IMAGE_FEATURES you may not want to install all packages from a
particular multilib. This introduces a new PACKAGE_EXCLUDE_COMPLEMENTARY
variable to allow specifying regexes to match packages to exclude.

(From OE-Core master rev: d4fe8f639d87d5ff35e50d07d41d0c1e9f12c4e3)

(From OE-Core rev: 5e92eb11cdf1dd06a3e2ca015f1aebaace321acd)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.foll@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-03-03 14:34:17 +00:00
Scott Rifenbark
586a3d5ff5 ref-manual: Fixed icecc example code
Fixes [YOCTO #6912]

The example used to make sure builders use the same sstate
signatures regardless if they use icecc or not was incorrect.
I updated the INHERIT_DISTRO line of the example to use the
append part in the name so it appends the icecc as suggested
by the bug submitter.

Reported-by: Peter Bergin <petan679@gmail.com>
(From yocto-docs rev: 772e95e201c21b8488962e7a31b7cc02f9186882)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-17 15:17:11 +00:00
Scott Rifenbark
7849633469 documentation: Reverted back to the 1.76.1 XSL stylesheet
Using the 1.76.1 version in all the customization layers so
the manual revision tables will build with boxes.

(From yocto-docs rev: a5ff3f41ed0eb0157983affdd0238d88d545295b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>

Conflicts:
	documentation/adt-manual/adt-manual-customization.xsl
	documentation/bsp-guide/bsp-guide-customization.xsl
	documentation/dev-manual/dev-manual-customization.xsl
	documentation/mega-manual/mega-manual-customization.xsl
	documentation/ref-manual/ref-manual-customization.xsl
	documentation/yocto-project-qs/yocto-project-qs-customization.xsl
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-17 15:17:10 +00:00
Tom Zanussi
367b862d59 yocto-bsp: Add branch to SRC_URI for custom kernels
Without 'branch' in the SRC_URI, a SRCREV specified for a non-master
KBRANCH will result in a fetch failure since the branch tested by the
fetcher will default to master, which doesn't contain the SRCREV.
This fixes the problem by adding branch=KBRANCH to the SRC_URI.

Fixes [Yocto #6518].

(From meta-yocto rev: 8aeb8715690ea5aa4a36fbe6403d46f53e0f99a5)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:08 +00:00
Saul Wold
c4e9d9d9ae btrfs: create an empty file to build the fs in
The newer btrfs-utils needs an empty file to build the filesystem in, so
create an empty file and use it for the mkfs to build the fs in.

[YOCTO #6804]

(From OE-Core rev: afc44fad44261677c799558ffd35f4908556bce0)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:08 +00:00
Sona Sarmadi
7a43fb95d1 bind: fix for CVE-2014-8500
[From upstream commit: 603a0e2637b35a2da820bc807f69bcf09c682dce]

[YOCTO #7098]

External References:
===================
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8500

(From OE-Core rev: 7225d6e0c82f264057de40c04b31655f2b0e0c96)

(From OE-Core rev: 97fcb0bb1f0bead8190b0c8f2435e551c2e2efe0)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:07 +00:00
Chong Lu
46e8377c42 file: CVE-2014-9620 and CVE-2014-9621
CVE-2014-9620:
Limit the number of ELF notes processed - DoS
CVE-2014-9621:
Limit string printing to 100 chars - DoS

The patch comes from:
6ce24f35cd
0056ec3225
09e41625c9
af444af073
68bd8433c7
dddd3cdb95
445c8fb0eb
ce90e05774
65437cee25

[YOCTO #7178]

(From OE-Core rev: ee78555fe54e98c6296566b5e701ef268d77db61)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
[sgw - Fixed magic.h.in to match magic.h]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:07 +00:00
Martin Jansa
148b7d20d4 update-rc.d: Allow to use different initscripts provider
* until now all recipes were respecting VIRTUAL-RUNTIME_initscripts
  variable but commit bba835fed88c3bd5bb5bd58962034aef57c408d8
  hardcoded "initscripts" runtime dependency

(From OE-Core rev: 1cda75706d63c988a0fa9945bd320b71c8e8488a)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:07 +00:00
Sona Sarmadi
d759301a34 python: Disables SSLv3
This is related to "SSLv3 POODLE vulnerability" CVE-2014-3566

Building python without SSLv3 support when openssl is built without
any support for SSLv3 (e.g. by adding EXTRA_OECONF = " -no-ssl3" in
the openssl recipes).

Backport from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611#22
[python2.7-nossl3.patch] only Modules/_ssl.c is backported.

References:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7015
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6843
http://bugs.python.org/issue22638
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566

(From OE-Core rev: 926904f65db33aa7a6a54bd6cdc9c8b34f000b0d)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:07 +00:00
Jonathan Liu
134246d3d4 systemd: backport patch to fix reading journal backwards
(From OE-Core rev: 85029adf4f2dbf2d100f1d1b41c7a7323afc008b)

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:07 +00:00
Saul Wold
c088bac2f0 openssh: move setting LD to allow for correct override
Using the export LD in the recipe does not allow for secodnary toolchain
overriding LD later, by setting it in the do_configure_append the export
is used by autotools setting LD based on the env, but would allow for
override later.

[YOCTO #6997]

(From OE-Core rev: 9b37e630f5f6e37e928f825c4f67481cf58c98a1)

(From OE-Core rev: b38f33c96b31c807306dd8b2d7b25cf8fad21026)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-connectivity/openssh/openssh_6.5p1.bb
2015-02-06 14:56:07 +00:00
Saul Wold
9766c76268 resolvconf: add fixes for busybox and make it work
resolvconf was missing a script and needed readlink which was in
/usr/bin.  Also the /etc/resolv.conf was not being correctly linked
to /etc/resolvconf/run/resolv.conf, which is fixed by the volaties
change which is now a file as opposed to created in do_install.

Ensure that the correct scripts for ifup/ifdown get installed and that
resolvconf is correctly enabled at startup

[YOCTO #5361]

(From OE-Core rev: 853e8d2c7aff6dddc1d555af22f54c4ecef13df1)

(From OE-Core rev: cb3c7cfe00e96580db5aedc7f7c0970378ab3c6e)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-connectivity/resolvconf/resolvconf_1.74.bb
2015-02-06 14:56:07 +00:00
Bian Naimeng
78b1cbcc72 cpio: fix bug CVE-2014-9112 for cpio-2.8
Obtain detain from following URL.
http://lists.gnu.org/archive/html/bug-cpio/2014-12/msg00000.html
http://git.savannah.gnu.org/cgit/cpio.git/commit/?id=746f3ff670dcfcdd28fcc990e79cd6fccc7ae48d

(From OE-Core rev: 732fc8de55a9c7987608162879959c03423de907)

(From OE-Core rev: 6f238c8293c3578eead15bf9f9ab5fdf95d1e9a5)

Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:06 +00:00
Bian Naimeng
3a4ee6bfd9 cpio: fix bug CVE-2014-9112 for cpio-2.11
Obtain detain from following URL.
  http://lists.gnu.org/archive/html/bug-cpio/2014-12/msg00000.html
  http://git.savannah.gnu.org/cgit/cpio.git/commit/?id=746f3ff670dcfcdd28fcc990e79cd6fccc7ae48d

(From OE-Core rev: 9a32da05f5a9bc62c592fd2d6057dc052e363261)

(From OE-Core rev: 674e1b4d44c7b108a843d486178182b943607a55)

Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-06 14:56:06 +00:00
Bruce Ashfield
9bb6f7f3f0 beaglebone: enable the nowayout option for the watchdog
Bumping the meta SRCREV for the following fix:

[
  The default watchdog behaviour is to stop the timer if the process
  managing it closes the file /dev/watchdog. The system would not reboot
  if watchdog daemon crashes due to a bug in it or get killed by other
  malicious code. So we prefer to enable nowayout option for the
  watchdong. With this enabled, there is no way of disabling the watchdog
  once it has been started. This option is also enabled in the predecessor
  of this BSP (beagleboard)
]

[YOCTO: 3937]

(From OE-Core rev: 7006412c285a4a6c75d5349f60dc71b0b735ff90)

(From OE-Core rev: f34de2175f1d6a443f219b8ceaaf796cfbc6efd5)

Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-28 09:07:01 +00:00
Bruce Ashfield
15919f7e76 linux-yocto-rt/3.14: update to 3.14-rt5
Updating the the latest 3.14-rt release.

(From OE-Core rev: ca1d952c964ce25bf78d47c7a856105d59d72cac)

(From OE-Core rev: 3211df158743f1b3d24421336c6bfbc2087b689a)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-28 09:07:01 +00:00
Bruce Ashfield
1e216c8087 linux-yocto/3.14: update to v3.14.4
Bumping the 3.14 recipes to the latest korg -stable release.

(From OE-Core rev: 5c0088767a59c63d2197b54450a54578fa10fa07)

(From OE-Core rev: 9a63b30c4ab41dee1c4c5a0d2a4053d29902db3c)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-28 09:07:00 +00:00
Bruce Ashfield
a67b95ade2 linux-yocto/3.14: update to v3.14.2
Updating to the korg 3.14.2 -stable release.

(From OE-Core rev: 34afc38d86d169f0c0c5f2427f644b0dcc3bf9a1)

(From OE-Core rev: 992d94d886abc9a971cfb8a8ba7f7b189c40cf6d)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-28 09:07:00 +00:00
Javier Viguera
1e668ccf1a file: add wrapper to nativesdk-file
Backport commit 69a3ab3 to 'daisy' which uses a different version of
file package.

Author of the original patch: Hongxu Jia <hongxu.jia@windriver.com>

(From OE-Core rev: 4bd4da1e1433ae64720f59d48188ecd1960dac28)

Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-25 15:32:18 +00:00
Scott Rifenbark
e3dd621197 dev-manual: Updated the "Making Images More Secure" section.
Fixes [YOCTO #5482]

I did some significant re-writing and re-organization of this
section.  It now includes a bit about securing an image in general,
provides general considerations, considerations specific to the
OpenEmbedded build system, pointers to some tools in meta-security
layer, and some other items.

I added some key references to the section on considerations
specific to the OpenEmbedded build system.  In particular, I
provided some cross-linking back to the extrausers.bbclass
section to reference an example of adding a user account.  I
also split out the topics of adding an extra user and setting
a password on the image in the bulleted list.

Updated the setting root and extra user's passwords.  Also,
permanently removed the reference to the wiki that showed the
less optimal way of setting a root password.

Added a cross-reference to the meta-selinux layer in the section
that describes how to make images more secure.

(From yocto-docs rev: 812bf8e2c91c4dd14a2245509ea7008a24e90835)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-20 17:24:52 +00:00
Scott Rifenbark
30b8d9378b profile-manual: Updates to the LTTng Documentation section.
The LTTng Documentation website has been updated to actually
have extensive documentation now.  Previously, in the profile-manual,
we were stating that documentation did not exist, which was true
at the time of writing.  I updated the section to link to the
main LTTng documentation website and altered some other text in
the section appropriately.

Additionally, I found and corrected a couple spelling errors in
this chapter.

(From yocto-docs rev: d40ea4d8cfcbc225025d73288cd01336e0d41afc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-08 11:14:55 +00:00
Richard Purdie
895c86d71d build-appliance-image: Update to daisy head revision
(From OE-Core rev: 1c7a2d764c9a5df4f1d249f34c9dacfc09c0071c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 14:27:23 +00:00
Saul Wold
07a7905689 readline: Patch for readline multikey dispatch issue
(From OE-Core rev: 5ef447d243e5c4954e00d49a4c499dc3fd691725)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 11:40:39 +00:00
Saul Wold
e76d790bbf wget: Fix for CVE-2014-4887
(From OE-Core rev: 52f9eebe86e4b641229b524dd7701c01d9ed833c)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 11:40:38 +00:00
Paul Eggleton
b60383c1b9 libarchive: avoid dependency on e2fsprogs
libarchive's configure script looks for ext2fs/ext2_fs.h in order to use
some defines for file attributes support if present (but doesn't link to
any additional libraries.) There is no configure option to disable this,
and if e2fsprogs is rebuilding between do_configure and do_compile you
can currently get a failure. Because it doesn't need anything else from
e2fsprogs, and e2fsprogs isn't currently buildable for nativesdk anyway,
copy the headers in from e2fsprogs-native which we're likely to have
built already (and add it to DEPENDS just to be sure we have.)

Fixes [YOCTO #6268].

(From OE-Core master rev: ad754e46ad477acfbe7543187a5c38bc333b8612)

(From OE-Core rev: 7504c2e715d675775e166a52ae83cf48504add19)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 11:40:38 +00:00
Paul Eggleton
19dc8bf950 python: force off_t size to 8 to enable large file support
If DISTRO_FEATURES contains "largefile", force the size of off_t to 8 as
a workaround for having ac_cv_sizeof_off_t=4 on 32-bit systems. In
future we will likely drop the value from the site file, but for now
this is a slightly safer fix.

Fixes [YOCTO #6813].

(From OE-Core master rev: a8216030ee6c65531de8fbf3eed878a345a94edc)

(From OE-Core rev: 94483eff5d0858ef1b5a8850268aa6a7bc6e6463)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 11:40:38 +00:00
Paul Eggleton
6c576a4ac8 openssh: avoid screen sessions being killed on disconnect with systemd
Tell systemd just to kill the sshd process when the ssh connection drops
instead of the entire cgroup for sshd, so that any screen sessions (and
more to the point, processes within them) do not get killed.

(This is what the Fedora sshd service file does, and what we're already
doing in the dropbear service file).

(From OE-Core master rev: 3c238dff41fbd3687457989c7b17d22b2cc844be)

(From OE-Core rev: 6e6aeb7cca52b92a0c8013473e2b8bb18738a119)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-06 11:40:37 +00:00
Richard Purdie
9f5ea81070 build-appliance-image: Update to daisy head revision
(From OE-Core rev: d1729495a19bda411fa84310ecf6c0ac3073ce36)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-05 23:28:16 +00:00
Chong Lu
51a5a5df84 curl: Security Advisory - curl - CVE-2014-3620
libcurl wrongly allows cookies to be set for Top Level Domains (TLDs), thus
making them apply broader than cookies are allowed. This can allow arbitrary
sites to set cookies that then would get sent to a different and unrelated site
or domain.

(From OE-Core rev: ddbaade8afbc9767583728bfdc220639203d6853)

(From OE-Core rev: 13bb2ee98cfd159455e459501dda280a78cb5a3b)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-05 23:27:45 +00:00
Chong Lu
6c9eb8a67a curl: Security Advisory - curl - CVE-2014-3613
By not detecting and rejecting domain names for partial literal IP addresses
properly when parsing received HTTP cookies, libcurl can be fooled to both
sending cookies to wrong sites and into allowing arbitrary sites to set cookies
for others.

(From OE-Core rev: 985ef933208da1dd1f17645613ce08e6ad27e2c1)

(From OE-Core rev: dbbda31ca0a29c930f3078635ae7c5a41d933b58)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-support/curl/curl_7.35.0.bb
2014-11-05 23:27:45 +00:00
Saul Wold
b8e521809b pseudo.inc: Clean up backport of version update to 1.6.2
This uprevs pseudo to 1.6. This merges in all of the existing
    fixes, and also adds partial support for extended attributes,
    including storing arbitrary extended attributes in the database,
    and also interpreting the posix permissions ACLs as chmod
    requests.

    The extended attribute support means we need xattr.h, the simplest
    way to be sure of this is to build attr before pseudo, which doesn't
    take long.

(From OE-Core rev: 606793e7b5c129654f317e5bec9ed7f083d3383d)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-05 23:27:44 +00:00
Saul Wold
994b637d58 poky.conf: Bump DISTRO_VERISON for 1.6.2
(From meta-yocto rev: 796a2a3d74a7a0da6201513d89d57b7abd74a268)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-04 15:13:56 +00:00
Richard Purdie
a85328245d yocto-bsp: Update qemu inclusion lists
Update qemu tune definitions to match changes in main qemu machines.

[YOCTO #6482]

(From meta-yocto rev: 0d78ffd509c6caba6c74c6e75c485fb8d923cd31)

(From meta-yocto rev: c144ac0fa804ac8667f6241d05c59408dfb21c6e)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-04 15:13:56 +00:00
Alejandro Hernandez
61da1b1197 ltp: Added zip-native as a DEPENDS
The Makefile checks for zip during installation

[YOCTO #6699]

(From OE-Core rev: a6e8ced3fa8e8e2aa3df0798b80eb26e5ebc4b15)

(From OE-Core rev: 00dc2ac9e0a7d4cec2d94f4d934dc1ab42d5b20b)

Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-extended/ltp/ltp_20140115.bb
2014-11-04 15:13:56 +00:00
Peter Seebach
3428e70035 pseudo*.bb: update to pseudo 1.6.2
pseudo 1.6.2 fixes problems with 64-bit inodes and some underlying issues
involving file renames that could occasionally cause very strange behaviors
files being deleted, linked, or renamed, mostly observed as strange
recovery if an inode got reused.

(From OE-Core rev: b2c6a032d6e5deb07e76ed75fcd0931fad6a748c)

(From OE-Core rev: c2e56d7da8c7df330869babac198678b33eb3802)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-devtools/pseudo/pseudo_1.6.2.bb
	meta/recipes-devtools/pseudo/pseudo_git.bb
2014-11-04 15:13:53 +00:00
Scott Rifenbark
dbf99ab134 poky-ent: Updated the YOCTO_RELEASE_NOTES variable.
This variable now needs to have the form
"&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;"
The old form was causing the release team to have to hand-redirect
the three links in the YP manuals that resolve to the release notes.

(From yocto-docs rev: 9c6831672f8e73835ce942b6f171f50a12b0e5bb)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-31 17:53:43 +00:00
Scott Rifenbark
18d859a8c9 documentation: Added "November 2014" to manual history lists.
(From yocto-docs rev: 6666a0877ecc505493b1bb164f3c405db357f03e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-28 22:31:07 +00:00
Kai Kang
313864bf52 gnupg: CVE-2013-4242
GnuPG before 1.4.14, and Libgcrypt before 1.5.3 as used in GnuPG 2.0.x
and possibly other products, allows local users to obtain private RSA
keys via a cache side-channel attack involving the L3 cache, aka
Flush+Reload.

Patch from commit e2202ff2b704623efc6277fb5256e4e15bac5676 in
git://git.gnupg.org/libgcrypt.git

(From OE-Core rev: 0692743b51f7daa0154fd4d8982236b4702ea2da)

Signed-off-by: Yong Zhang <yong.zhang@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 21:43:15 +01:00
Saul Wold
e93f9a8382 openssl: Upgrade to 1.0.1j
This address the latest set of CVE issues

(From OE-Core rev: 461e598815f8749bb26e97369e3b877f7ce749cf)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 21:43:11 +01:00
Yue Tao
df4a397df9 gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0869
The field_end function in libavcodec/h264.c in FFmpeg before 1.1.2
allows remote attackers to have an unspecified impact via crafted H.264
data, related to an SPS and slice mismatch and an out-of-bounds array
access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0869

(From OE-Core rev: 9d0fe8f47e360ad09d4a20144da96576dd4bf82f)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Conflicts:
	meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 16:13:31 +01:00
Yue Tao
9b3389e023 gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-4358
libavcodec/h264.c in FFmpeg before 0.11.4 allows remote attackers to
cause a denial of service (crash) via vectors related to alternating bit
depths in H.264 data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4358

(From OE-Core rev: 187470bf4e1d0d87d84aae251e663c3eb490ff9c)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Conflicts:
	meta/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bb
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 16:13:31 +01:00
Kai Kang
4b22a21b4e readline: Security Advisory - readline - CVE-2014-2524
The _rl_tropen function in util.c in GNU readline before 6.3 patch 3
allows local users to create or overwrite arbitrary files via a symlink
attack on a /var/tmp/rltrace.[PID] file.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2524

(From OE-Core rev: a4fa519de008ccd5b9411fcb1880e0a64383ce9c)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 16:13:31 +01:00
Ross Burton
27a877becf openssl: upgrade to 1.0.1j
(From OE-Core rev: 5163eb2c3c492d3640aa0628c29f6b8d446a8261)

Signed-off-by: Ross Burton <ross.burton@intel.com>

Conflicts:
	meta/recipes-connectivity/openssl/openssl_1.0.1g.bb
	meta/recipes-connectivity/openssl/openssl_1.0.1i.bb
	meta/recipes-connectivity/openssl/openssl_1.0.1j.bb
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 16:13:30 +01:00
Chang Rebecca Swee Fun
2d5bd89565 lttng-modules: Update to version 2.4.2
lttng-modules breaks when building with kernel 3.10.43.
This updates lttng-modules for 2.4.2 and it will also
fixes the build failure with kernel 3.10.43.

Fixes for [YOCTO #6788]

(From OE-Core rev: 29ef1c738050e536d7824bdca6f7a0b8b1528011)

Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-23 16:13:30 +01:00
Catalin Popeanga
bda51ee782 bash: Fix-for-CVE-2014-6278
This vulnerability exists because of an incomplete fix for CVE-2014-6271, CVE-2014-7169, and CVE-2014-6277

See: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278

(From OE-Core rev: de596b5f31e837dcd2ce991245eb5548f12d72ae)

Signed-off-by: Catalin Popeanga <Catalin.Popeanga@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 18:06:09 +01:00
Catalin Popeanga
5dd12beccd bash: Fix for CVE-2014-6277
Follow up bash43-026 to parse properly function definitions in the values of environment variables, to not allow remote attackers to execute arbitrary code or to cause a denial of service.

See: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277

(From OE-Core rev: 85961bcf81650992259cebb0ef1f1c6cdef3fefa)

Signed-off-by: Catalin Popeanga <Catalin.Popeanga@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 18:06:09 +01:00
Catalin Popeanga
1d21eaf4e0 bash: Fix for CVE-2014-7186 and CVE-2014-7187
This is a followup patch to incomplete CVE-2014-6271 fix code execution via
specially-crafted environment

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7186
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7187

(From OE-Core rev: 153d1125659df9e5c09e35a58bd51be184cb13c1)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 18:06:08 +01:00
Catalin Popeanga
95821e8566 bash: Fix for exported function namespace change
This is a followup patch to incomplete CVE-2014-6271 fix code execution via
specially-crafted environment

This patch changes the encoding bash uses for exported functions to avoid
clashes with shell variables and to avoid depending only on an environment
variable's contents to determine whether or not to interpret it as a shell
function.

(From OE-Core rev: 6c51cc96d03df26d1c10867633e7a10dfbec7c45)

Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 18:06:08 +01:00
yanjun.zhu
57138de0fc perl: fix for CVE-2010-4777
The Perl_reg_numbered_buff_fetch function in Perl 5.10.0, 5.12.0,
5.14.0, and other versions, when running with debugging enabled,
allows context-dependent attackers to cause a denial of service
(assertion failure and application exit) via crafted input that
is not properly handled when using certain regular expressions,
as demonstrated by causing SpamAssassin and OCSInventory to
crash.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4777
(From OE-Core rev: 368df9f13ddf124e6aaaec06c02ab698c9e0b6c3)

(From OE-Core rev: 73aff6efb3374427234a3615ffca07874f22f3fa)

Signed-off-by: yanjun.zhu <yanjun.zhu@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Yue Tao
57a806cc32 libpam: Security Advisory - CVE-2014-2583
v2 changes:
* update format for commit log
* add Upstream-Status for patch

Multiple directory traversal vulnerabilities in pam_timestamp.c in the
pam_timestamp module for Linux-PAM (aka pam) 1.1.8 allow local users to
create aribitrary files or possibly bypass authentication via a .. (dot
dot) in the (1) PAM_RUSER value to the get_ruser function or (2) PAM_TTY
value to the check_tty funtion, which is used by the
format_timestamp_name function.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2583

(From OE-Core rev: 69255c84ebd99629da8174e1e73fd8c715e49b52)

(From OE-Core rev: 8b9164029153fa06520bd5b6349245c2ac1f605f)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Yue Tao
452619ba41 libtiff: Security Advisory - CVE-2012-4564
v2 changes:
* update format for commit log
* add Upstream-Status for patch

ppm2tiff does not check the return value of the TIFFScanlineSize
function, which allows remote attackers to cause a denial of service
(crash) and possibly execute arbitrary code via a crafted PPM image that
triggers an integer overflow, a zero-memory allocation, and a heap-based
buffer overflow.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4564

(From OE-Core rev: 9f02922d44de483ef4d02ce95b55efe79a8b09a2)

(From OE-Core rev: ff60c490c4fdb9f89d2b8e8fe7f2e7c4f2ff631f)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Guillem Jover
8d28013312 dpkg: Security Advisory - CVE-2014-3127
v2 changes:
* update format for commit log
* add Upstream-Status for patch

commit a12eb58959d0a10584a428f4a3103a49204c410f upstream

Dpkg::Source::Patch: Outright reject C-style filenames in patches

Because patch only started recognizing C-style filenames in diffs
in version 2.7, it's not safe to assume one behaviour or the other,
as the system might or might not have a recent enough version, or
a GNU patch program at all. There's also no reason we should be
supporting this kind of strange encoded filenames in patches, when
we have not done so up to now.

Let's just ban these types of diffs and be done with it.

Fixes: CVE-2014-0471, CVE-2014-3127
Closes: #746306

[drop the text for debian/changelog,because it's not suitable
for the veriosn]
(From OE-Core rev: 2c3838443eacd3a86ea8917ea53a20248e7bdf03)

(From OE-Core rev: 14273b42542151357e3299736f2b730ca3257fc0)

Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Guillem Jover
570345adfd dpkg: Security Advisory - CVE-2014-0471
v2 changes:
* update format for commit log
* add Upstream-Status for patch

commit a82651188476841d190c58693f95827d61959b51 upstream

Dkpkg::Source::Patch: Correctly parse C-style diff filenames

We need to strip the surrounding quotes, and unescape any escape
sequence, so that we check the same files that the patch program will
be using, otherwise a malicious package could overpass those checks,
and perform directory traversal attacks on source package unpacking.

Fixes: CVE-2014-0471

Reported-by: Jakub Wilk <jwilk@debian.org>
[drop the text for debian/changelog,because it's not suitable
 for the veriosn]

(From OE-Core rev: 81880b34a8261e824c5acafaa4cb321908e554a0)

(From OE-Core rev: c75316fc256d229cfad45cd57328920993d93d8d)

Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com>
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Yue Tao
9062377624 gst-ffmpeg: Add CVE patches
Security Advisory - ffmpeg - CVE-2013-0866

The aac_decode_init function in libavcodec/aacdec.c in FFmpeg before
1.0.4 and 1.1.x before 1.1.2 allows remote attackers to have an
unspecified impact via a large number of channels in an AAC file, which
triggers an out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0866

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0875

The ff_add_png_paeth_prediction function in libavcodec/pngdec.c in
FFmpeg before 1.1.3 allows remote attackers to have an unspecified
impact via a crafted PNG image, related to an out-of-bounds array
access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0875

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0860

The ff_er_frame_end function in libavcodec/error_resilience.c in FFmpeg
before 1.0.4 and 1.1.x before 1.1.1 does not properly verify that a
frame is fully initialized, which allows remote attackers to trigger a
NULL pointer dereference via crafted picture data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0860

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2011-3934

Double free vulnerability in the vp3_update_thread_context function in
libavcodec/vp3.c in FFmpeg before 0.10 allows remote attackers to have
an unspecified impact via crafted vp3 data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3934

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2011-3946

The ff_h264_decode_sei function in libavcodec/h264_sei.c in FFmpeg
before 0.10 allows remote attackers to have an unspecified impact via
crafted Supplemental enhancement information (SEI) data, which triggers
an infinite loop.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3946

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-7023

The ff_combine_frame function in libavcodec/parser.c in FFmpeg before
2.1 does not properly handle certain memory-allocation errors, which
allows remote attackers to cause a denial of service (out-of-bounds
array access) or possibly have unspecified other impact via crafted
data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7023

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-7009

The rpza_decode_stream function in libavcodec/rpza.c in FFmpeg before
2.1 does not properly maintain a pointer to pixel data, which allows
remote attackers to cause a denial of service (out-of-bounds array
access) or possibly have unspecified other impact via crafted Apple RPZA
data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7009

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0855

Integer overflow in the alac_decode_close function in libavcodec/alac.c
in FFmpeg before 1.1 allows remote attackers to have an unspecified
impact via a large number of samples per frame in Apple Lossless Audio
Codec (ALAC) data, which triggers an out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0855

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2011-4351

Buffer overflow in FFmpeg before 0.5.6, 0.6.x before 0.6.4, 0.7.x before
0.7.8, and 0.8.x before 0.8.8 allows remote attackers to execute
arbitrary code via unspecified vectors.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4351

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0848

The decode_init function in libavcodec/huffyuv.c in FFmpeg before 1.1
allows remote attackers to have an unspecified impact via a crafted
width in huffyuv data with the predictor set to median and the
colorspace set to YUV422P, which triggers an out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0848

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2011-3944

The smacker_decode_header_tree function in libavcodec/smacker.c in
FFmpeg before 0.10 allows remote attackers to have an unspecified impact
via crafted Smacker data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3944

           file://0001-huffyuvdec-check-width-more-completely-avoid-out-of-.patch \

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-7010

Multiple integer signedness errors in libavcodec/dsputil.c in FFmpeg
before 2.1 allow remote attackers to cause a denial of service
(out-of-bounds array access) or possibly have unspecified other impact
via crafted data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-7010

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2011-3941

The decode_mb function in libavcodec/error_resilience.c in FFmpeg before
0.10 allows remote attackers to have an unspecified impact via vectors
related to an uninitialized block index, which triggers an out-of-bound
write.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3941

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2013-0846

Array index error in the qdm2_decode_super_block function in
libavcodec/qdm2.c in FFmpeg before 1.1 allows remote attackers to have
an unspecified impact via crafted QDM2 data, which triggers an
out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0846

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2012-6618

The av_probe_input_buffer function in libavformat/utils.c in FFmpeg
before 1.0.2, when running with certain -probesize values, allows remote
attackers to cause a denial of service (crash) via a crafted MP3 file,
possibly related to frame size or lack of sufficient frames to estimate
rate.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6618

gst-ffmpeg: Security Advisory - ffmpeg - CVE-2012-6617

The prepare_sdp_description function in ffserver.c in FFmpeg before
1.0.2 allows remote attackers to cause a denial of service (crash) via
vectors related to the rtp format.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6617

(From OE-Core rev: 58f08a96764094189b5aaf3cc8b4cc0c95e23409)

(From OE-Core rev: 9b3a2d0716540dae72376a8c2e418b244a85c0cb)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Xufeng Zhang
0143097095 nspr: Fix for CVE-2014-1545
Mozilla Netscape Portable Runtime (NSPR) before 4.10.6 allows remote
attackers to execute arbitrary code or cause a denial of service
(out-of-bounds write) via vectors involving the sprintf and console
functions.Per: http://cwe.mitre.org/data/definitions/787.html

(From OE-Core rev: 191cab2f679491c2b6ddba49c5cf4886dcd22f57)

(From OE-Core rev: bebfeb6d4deac18601edda8dcac0f32c3382cb06)

Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:06 +01:00
Shan Hai
4b1b580749 pulseaudio: fix CVE-2014-3970
The pa_rtp_recv function in modules/rtp/rtp.c in the module-rtp-recv module
in PulseAudio 5.0 and earlier allows remote attackers to cause a denial of
service (assertion failure and abort) via an empty UDP packet.

Fix it by picking a patch from pulseaudio upstream code.

(From OE-Core rev: f9d7407e54f1fa3d3a316a5bbb8b80665e6f03fd)

(From OE-Core rev: cf008bce23e897d1c3a51805af839af9241271df)

Signed-off-by: Shan Hai <shan.hai@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:05 +01:00
Li Wang
65ed47e597 nss: CVE-2014-1544
the patch comes from:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-1544
https://hg.mozilla.org/projects/nss/rev/204f22c527f8

author  Robert Relyea <rrelyea@redhat.com>
https://bugzilla.mozilla.org/show_bug.cgi?id=963150
Bug 963150: Add nssCertificate_AddRef and nssCertificate_Destroy calls
to PK11_ImportCert to prevent nssTrustDomain_AddCertsToCache from
freeing the CERTCertificate associated with the NSSCertificate. r=wtc.

(From OE-Core rev: 7ef613c7f4b9e4ff153766f31dae81fc4810c0df)

(From OE-Core rev: 7e4f3f167c40c09bf2c32f5e366a8fad3c66b74b)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:05 +01:00
Muzaffar Mahmood
608ac7794f libtiff: fix CVE-2013-1961
Integrate community fix for the issue CVE-2013-1961
and migrated to version 4.0.3.

Stack-based buffer overflow in the t2p_write_pdf_page function
in tiff2pdf in libtiff before 4.0.3 allows remote attackers to
cause a denial of service (application crash) via a crafted
image length and resolution in a TIFF image file.

(From OE-Core rev: f24e3456c60951d2985d7c23bdcc1f8c15d6c167)

(From OE-Core rev: 9b8ca9d9b0b12dff8a3908da00020d253685958f)

Signed-off-by: Priyanka Shobhan <priyanka_shobhan@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Muzaffar Mahmood <muzaffar_mahmood@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:05 +01:00
Chong Lu
4dada3c092 adt-installer: fix sed input file error
When use default install directory, we can't get the environment setup
script path. The reason is that opkg-cl list incorrect files paths.
This patch sets env_script variable to make us get correct environment
setup script path.

[YOCTO #6443]

(From OE-Core rev: b0ac1ea1f7eaca92b613f874ee2cbf6830743a71)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:05 +01:00
Richard Purdie
43903a5bfd binutils: Add fix for recent patch on older gcc
The recent bintuils patch update breaks on older gccs such as CentOS 6.
Backport a patch to address this.

(From OE-Core rev: 947c1bab91993be149fba1d09aedbe8509902fbe)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-10 15:06:05 +01:00
Paul Eggleton
e464615684 libxml2: fix python packaging for nativesdk
We enable the python module in nativesdk-libxml2, but the python binary
used is in the native sysroot and thus you get the module installed in
the wrong path. Even with that fixed the python files are still
unpackaged, so create an ${PN}-python package and add them to it. (This
does not affect the libxml target build at all since python is disabled
for that.)

(From OE-Core rev: 360fc811ff843c63f796e958517a5152f07e851d)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-09 21:17:32 +01:00
Steffen Sledz
7a12eda785 layer.conf: Mark opkg-utils as ABISAFE for update-alternatives usage
Currently linux-firmware rebuilds for each machine due to its usage of
update-alternatives which in turn means a dependency on opkg-utils.
Marking opkg-utils as ABISAFE is the only option we have right now
to avoid this.

(From OE-Core rev: e4c4ca3101062ecc956294ac968dc488321eb33b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 17:58:35 +01:00
Steffen Sledz
d88fa68141 update-rc.d/systemd: Remove OVERRIDES dependency
Taking run-postinsts and building for two machines which have different
OVERRIDES leads to two different sets of stamps for an allarch package.

We don't need to depend on OVERRIDES in these classes, the end resulting
variables are good enough. We can therefore exclude the dependency
and allow a single package to be generated for run-postinsts.

(From OE-Core rev: 6e875148f79a6877653a5bf95879b8cda1cacbc6)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 17:58:35 +01:00
Steffen Sledz
3a93bfe1c7 layer.conf: Add in useradd dependencies as ABISAFE dependencies
Currently allarch recipes using useradd rebuild each time MACHINE
changes which is not desireable. Adding the useradd dependencies
to this list ensures they do not change under these circumstances.

(From OE-Core rev: 0306b6122a34579673ab89fa4869d577995af960)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steffen Sledz <sledz@dresearch-fe.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 17:58:34 +01:00
Khem Raj
9fee4d138b bash: Fix CVE-2014-7169
This is a followup patch to incomplete CVE-2014-6271 fix
code execution via specially-crafted environment

Change-Id: Ibb0a587ee6e09b8174e92d005356e822ad40d4ed
(From OE-Core rev: e358d20e8ccf1299e8a046e743a31e92546cd239)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 12:16:38 +01:00
Ross Burton
87e924e377 bash: fix CVE-2014-6271
CVE-2014-6271 aka ShellShock.

"GNU Bash through 4.3 processes trailing strings after function definitions in
the values of environment variables, which allows remote attackers to execute
arbitrary code via a crafted environment."

(From OE-Core rev: eb41d5d4eaee1c810f8e418704c110c2005d0197)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 12:16:38 +01:00
Armin Kuster
8de7e102cf eglibc: CVE-2014-5119 fix
__gconv_translit_find: Disable function [BZ #17187]

This functionality has never worked correctly, and the implementation
contained a security vulnerability (CVE-2014-5119).

(From OE-Core rev: 3f0a4551969798803e019435f1f4b5e8f88bea1a)

Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-29 12:02:39 +01:00
yzhu1
6780f20525 nss-3.15.1: fix CVE-2013-1739
Mozilla Network Security Services (NSS) before 3.15.2 does
not ensure that data structures are initialized before
read operations, which allows remote attackers to cause a
denial of service or possibly have unspecified other
impact via vectors that trigger a decryption failure.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1739
(From OE-Core rev: 9b43af77d112e75fa9827a9080b7e94f41f9a116)

(From OE-Core rev: 4ce30ef254511ce39dd576b80134b9316f9fa06c)

Signed-off-by: yzhu1 <yanjun.zhu@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-support/nss/nss.inc
2014-09-29 12:02:39 +01:00
Li Wang
1d04721fe8 nss: CVE-2013-5606
the patch comes from:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5606
https://bugzilla.mozilla.org/show_bug.cgi?id=910438
http://hg.mozilla.org/projects/nss/rev/d29898e0981c

The CERT_VerifyCert function in lib/certhigh/certvfy.c in
Mozilla Network Security Services (NSS) 3.15 before 3.15.3 provides
an unexpected return value for an incompatible key-usage certificate
when the CERTVerifyLog argument is valid, which might allow remote
attackers to bypass intended access restrictions via a crafted certificate.

(From OE-Core rev: 1e153b1b21276d56144add464d592cd7b96a4ede)

(From OE-Core rev: e2c81356f68eb0b77408e73f01df5bc5c9f2adb3)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-support/nss/nss.inc
2014-09-29 12:02:39 +01:00
Fabrice Coulon
a4d8015687 useradd-staticids.bbclass: Fix for Bug 6633
When using the useradd-staticids.bbclass under meta/classes,
this error occurs:
"<username> - <username>: Username  does not have a static uid defined."
There was a problem with the regular expression for parsing parameters,
it was sometimes returning an empty string.

I have fixed this by skipping empty strings.

(From OE-Core rev: f249ef32709069a2680b92dc5a5b4f6545d014b7)

(From OE-Core rev: 592f0dccaf1985194f40fc019a9d33b9623df37f)

Signed-off-by: Fabrice Coulon <fabrice@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-23 13:02:57 +01:00
Richard Purdie
7b57145498 crosssdk: Clear MACHINEOVERRIDES
Without this, things like arm* can make it into OVERRIDES when we're
building a compiler to build binaries for another architecture like
x86. This can can lead to build failures dependning on the
exact configuration and overrides.

For example:

MACHINE=imx53qsb bitbake gcc-crosssdk-initial-x86_64 -e | grep EXTRA_OECONF

was showing an armv7 configuration option to gcc.

(From OE-Core rev: d02cdf3ee88c7bbb93cecf094008858782deec3f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-20 10:41:29 +01:00
Khem Raj
38b1b68923 native/nativesdk: Clear MACHINEOVERRIDES
In cases where we override variables e.g PACKAGE_ARCH
conditionally and use a MACHINEOVERRIDE to qualify the
override like

PACKAGE_ARCH_<MACHINE> = "some target PACKAGE_ARCH"

This would also be effective if this recipe is
BBEXTENDED to native or nativesdk which is undesired
This particular issue will cause wrong sysroot to be
used for nativesdk case since PACKAGE_ARCH would have
been modified and eventually changing value of
STAGING_DIR_TARGET which we use as --sysroot option
to cross and cross-canadian built SDK gcc

(From OE-Core rev: 474234a362b4cda5f2f1afab369c98d4e0ca1b11)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-20 10:41:29 +01:00
Jonathan Liu
ec3c8fcf81 qemu: Explicitly disable libiscsi, its not in DEPENDS
(From OE-Core rev: 8f67830e41e435a142d0b905a1b9f706a1cf1175)

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-20 10:41:28 +01:00
Richard Purdie
b2f045c400 populate_sdk_base: Fix grep command usage on old hosts
"man grep" on centos:

       -R, -r, --recursive
              Read all files under each directory, recursively; this is equivalent to the -d recurse option.

"man grep" on a more recent ubuntu system:

       -r, --recursive
              Read all files under each directory, recursively, following symbolic links only if they are on the command line.  This
              is equivalent to the -d recurse option.

So we have an issue when the SDK installer (even with
buildtools-tarball) is used on old hosts since it may try and
dereference paths which it should not. This is caused by differences in
the behaviour of grep -r on older systems.

The fix is to wrap this in find so that only real files are found (as
elsewhere in the script.

[YOCTO #6577]

(From OE-Core rev: 7986adeac16550b33f65fded39a55f668e0e543f)

(From OE-Core rev: 11e83000b164340b7e261a62f074a0e0cb6d6282)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15 09:55:31 +01:00
Diego Sueiro
87671f72e7 qt4: Fix Qt 4.8.5 source to new location
Qt 4.8.5 was moved from http://download.qt-project.org/official_releases/qt/4.8/ to
http://download.qt-project.org/archive/qt/4.8/

Thi fix must be applied for dora and daisy branches.

(From OE-Core rev: 975f5865bbfd417840be745d09a68dc064ea8d1d)

Signed-off-by: Diego Sueiro <diego.sueiro@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-11 12:08:12 +01:00
Martin Jansa
b028947d67 cairo: explicitly disable LTO support by backporting patch which removes it
* cairo-native was failing to build in gentoo with gcc-4.9 and LTO
  enabled, more details in upstream bug
  https://bugs.freedesktop.org/show_bug.cgi?id=77060

(From OE-Core rev: a7b5605fc8ac5b56f7a9d1587efc5c50d98378b8)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-11 12:06:54 +01:00
Bruce Ashfield
f5847d4f24 kernel: don't copy .so.dbg files into kernel source install
In 3.16+ x86-64 kernel builds produce a vdso64.so.dbg file. If this file is
copied into the kernel source install multiple QA failures are triggered.
Specifically, this file triggers a debug package split that results in
files installed but not shipped, and invalid .debug file errors.

By ensuring that .so files are not copied, we avoid this incorrect split
with no impact on future build phases.

(From OE-Core rev: 649eb801b13e73b532688ede2d966e196d2cb314)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-11 12:06:54 +01:00
Martin Jansa
59198004c0 perf: explicitly disable libunwind
* it's not included in DEPENDS and it's detected from sysroot

(From OE-Core rev: e426f6c6711ecc752d0fef67005fb769fd74b5f1)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-11 12:06:54 +01:00
Richard Purdie
984be33145 populate_sdk_deb: Fix non x86_64 SDK builds
If building with SDKMACHINE=i686 and using the deb backend, populate_sdk
would fail. Its clear when looking at the options that the 32 bit values
were overwritten.

Replace this code with code similar to that used in package_deb itself.

[YOCTO #6458]

(From OE-Core rev: 9c45575a9df01f0d36fb03120ec86d55b15819f3)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-27 08:34:45 +01:00
Denys Dmytriyenko
96ee64c96b udev: update init script for conditional probing of platform bus
Make probing of "platform" bus conditional based on PROBE_PLATFORM_BUS
variable from /etc/default/udev-cache on subsequent boots when udev
cache is used. PROBE_PLATFORM_BUS has to be set to "yes" in order to
force probing on every boot, otherwise it uses the old default behaviour
of probing it just the first time.

This is helpful on modern SoCs where most of the low level peripheral
drivers are registered on the platform bus and need to be probed to load
the necessary modules and enable the connected buses and subsystems.

(From OE-Core rev: 6886a99758d25991ecd6ee995d18f97996b31177)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 18:01:24 +01:00
H.J. Lu
7a8f9114bc binutils: Apply the proper fix for PR 16428
It is fixed by

commit 4199e3b8669d0a36448687850374fdc2ad7240b6
Author: Alan Modra <amodra@gmail.com>
Date:   Wed Jan 15 21:50:55 2014 +1030

    non-PIC references to __ehdr_start in pie and shared

    Rather than hacking every backend to not discard dynamic relocations
    against an undefined hidden __ehdr_start, make it appear to be defined
    early.  We want __ehdr_start hidden before size_dynamic_sections so
    that it isn't put in .dynsym, but we do need the dynamic relocations
    for a PIE or shared library with a non-PIC reference.  Defining it
    early is wrong if we don't actually define the symbol later to its
    proper value.  (In some cases we want to leave the symbol undefined,
    for example, when the ELF header isn't loaded, and we don't have this
    infomation available in before_allocation.)

So replace the existing patches with this one.

(From OE-Core rev: e48b93a495205f812d71967548943ab80df79092)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 18:01:22 +01:00
Denys Dmytriyenko
21ac977e2a udev-cache.default: set PROBE_PLATFORM_BUS to "yes" by default
Force probing of "platform" bus by default.

(From OE-Core rev: 56ab3df34cbea9f139935297221cc781e44770a2)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 18:01:16 +01:00
Darren Hart
33a4425d6d kernelshark: Remove trace-cmd from the kernelshark package
Fixes [YOCTO 6550]

Images installing both trace-cmd and kernelshark would fail with:

error: file /usr/bin/trace-cmd conflicts between attempted installs of
kernelshark-1.2+git0+7055ffd37b-r3.core2_32 and
trace-cmd-1.2+git0+7055ffd37b-r3.core2_32

This patch removes ${bindir}/trace-cmd from the install prior to
packaging, as is already done with the ${datadir}.

Reported-by: California Sullivan <california.l.sullivan@intel.com>
(From OE-Core rev: e80b2075055947b45102da629f99b677f8752e0d)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
(cherry picked from commit eb08ae8f729ef77329892d19b23ddfdaa7953de0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 18:01:16 +01:00
Stefan Agner
8abf510a13 shadow-securetty: add freescale lpuart
Add Freescale lpuart tty's (ttyLPx) to securetty. Freescale Vybrid
devices running upstream kernel use this driver.

(From OE-Core rev: 80ba78dcdef75e7b1c1761cd0cfadfe497cb0591)

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 18:01:16 +01:00
Scott Rifenbark
3ff30c0bfb ref-manual: Updated note in the "CentOS Packages" section.
We want to encourage installation of the buildtools tarball for
getting the most up-to-date packages on this build host.

(From yocto-docs rev: 583b74ceeea6316fd28aea393e4fa6dccc4b86ea)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 09:18:26 +01:00
Tom Zanussi
7e68f57dec wic: Remove fstype from mkefidisk canned wks
The bootimg-efi plugin specifies the fstype internally, so remove it
from the partition definition.

(From OE-Core rev: 6b6cbf023d8fac83f3732334d04f85bedf3845da)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 09:18:26 +01:00
Tom Zanussi
3b998b3f4c wic: Fix bad directory name in bootimg-efi
The original move of the mkefidisk code to the bootimg-efi plugin
resulted in a bad hdddir - fix it.

(From OE-Core rev: 95f8728c9ab8d8de8a0f4177882858e7a806cd97)

Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25 09:18:26 +01:00
Scott Rifenbark
d8155f1f95 documentation: Updated manual history tables to support 1.6.2
(From yocto-docs rev: 8aeaec680c92955a1bf5ad3898a3f01bd45b8951)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-22 15:05:12 +01:00
Scott Rifenbark
e378410fb2 mega-manual.sed: Updates to support links to BB manual
Discovered that the sed file was processing the bitbake-user-manual
just like the others, which was wrong.  the BB manual is not
included in the mega-manual so the links there need to be left
alone.  The fix included specially creating substitution lines
to handle all the YP docs while excluding the BB manual.

(From yocto-docs rev: a0e3113802ff8524bf77753c9c67904894fd81ee)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-22 15:05:11 +01:00
Scott Rifenbark
3a1d9e9e11 poky.ent: Updated variables to support a 1.6.2 release.
(From yocto-docs rev: 4cfe5c389ef6b56d5780cbaf6fc2673a0272c3ec)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-22 15:05:11 +01:00
Scott Rifenbark
26dcc54c60 ref-manual, yocto-project-qs: Fixed some references to BitBake Manual.
Found a few references that were not linking to the manual but
were instead referencing the Source Directory structure.

(From yocto-docs rev: e14cf460f100322b7b58de23f9522c41dc0106fa)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-22 15:05:11 +01:00
Richard Purdie
8e05d5e3fe bitbake: codeparser: Fix to better catch all getVar references
Currently if you do localdata.getVar, the code parser simply ignores
the references. Change the code to use endswith() to catch more of the
references. These names are probably unique enough to get away with this.

Bump the cache version to ensure things get updated.

(Bitbake rev: 8e386a710023e000a504e05c13da0106df0c7f3a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-03 13:47:18 +01:00
Christopher Larson
5c1f10f56e bitbake: codeparser: don't interact with the cache for subshells
Doing so was causing leakage between the execs of the main value and that of
the subshell value, and was causing the cached subshell value to be used for
the overall variable. At the least this could cause execs contamination
between two variables that while differing, run the same subshell. Beyond
that, it's possible we could have been using an incomplete cached value of
a subshell for that of the main value.

Before this, bb_codeparser.dat would change between parses with differing
bbfile parse order. After, it does not change.

The codeparser cache version is bumped, to ensure we don't use potentially
incorrect cached values from previous runs.

This should hopefully resolve the difficult-to-reproduce issues we've seen at
Mentor Graphics where bitbake emits a script to run a task and misses
dependent functions, resulting in 'command not found' failures. This issue has
also been mentioned on the oe devel list, where someone hit a case where
oe_runmake was missing from a do_install task (IIRC). Adding debug information
showed that bitbake's information about the variable dependencies for this
task is inaccurate in the failure cases.

(Bitbake rev: b89c24085f005ca3abf37ae7357f85b6b6828170)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-03 13:47:18 +01:00
Henning Heinold
0843e07873 perf: add slang to the dependencies
* TUI/GUI support was added in 2.6.35 based on libnewt
* since 3.10 slang replaced libnewt completly
* changing TUI_DEFINES is not necessary, because NO_NEWT is
  still respected with newer kernels
* add comment about the gui history to the recipe

The patch was sponsored by sysmocom

(From OE-Core rev: 348b90a8a9b32e5e4a10960194a2f622cb07a0c6)

Signed-off-by: Henning Heinold <henning@itconsulting-heinold.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-03 13:47:18 +01:00
Henning Heinold
793afb3e81 perf: split packging
* some fundamental perf commands can work
  without the dependency on perl, python or bash
  make them separate packages and RSUGGEST them

* bump PR

The patch was sponsored by sysmocom

(From OE-Core rev: 7d00247a3b204cdb35a9baa1eda0eed9a54dbebf)

Signed-off-by: Henning Heinold <henning@itconsulting-heinold.de>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-03 13:47:18 +01:00
Henning Heinold
aebbf8c8f3 perf: fix broken shell comparsion in do_install
The patch was sponsored by sysmocom

(From OE-Core rev: f7650cf40492ac5cfe724177d9d9e58d89c54252)

Signed-off-by: Henning Heinold <henning@itconsulting-heinold.de>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-03 13:47:18 +01:00
Richard Purdie
c4f1f0f491 build-appliance-image: Update to daisy head revision
(From OE-Core rev: 09f7ef16bbfbdfee25f0be3fd829924a6042fae9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-23 12:21:07 +01:00
Richard Purdie
810dd79720 build-appliance-image: Update to daisy head revision
(From OE-Core rev: 146f494eb9b98acb5d61e1919ce582dea3367548)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:59:05 +01:00
Belen Barros
b0ce70ffa8 bitbake: toaster: Fix spacing and layout in no image files notification
Close the definition list before adding the notification, and
restrict the notification width to avoid uncomfortable line
lenghts.

(Bitbake rev: 2ae1fa629acf1a37f2c8ad929285cc7c76a9a40b)

Signed-off-by: Belen Barros <belen.barros.pena@intel.com>
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:09 +01:00
Farrell Wymore
ac2d94b684 bitbake: toaster: display message if no images are generated
Display message if no images are generated for a target. This
commit was amended to have more conditions for displaying the
message.

[YOCTO #6094]

(Bitbake rev: d004be9f6535567fb24f7bfa342932c03562f188)

Signed-off-by: Farrell Wymore <farrell.wymore@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Ionut Chisanovici
ce2336ddc7 bitbake: toaster: Add performance testing script
This is implemented as a django management command.
For the moment the 'manage.py perf' command will track the toaster
'gui' urls http response code and load time.

To use it:
1. do your toaster builds
2. ensure toaster is started
1. cd bitbake/lib/toaster
2. ln -s ../../../build/toaster.sqlite
3. ./manage.py perf

(Bitbake rev: fa4b483c7077637427c7fac5da23ae5de27f554d)

Signed-off-by: Ionut Chisanovici <ionutx.chisanovici@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Farrell Wymore
5b8c5ea151 bitbake: toaster: refactor the target page
the target (packages) page had to refactored to
allow the displays to differ depending on the caller
namely the license manifest link. Amended to make the
link from the tag rather than the pathname itself.

[YOCTO #6291]
[YOCTO #6079]

(Bitbake rev: 5ea0644c82560bcfc3aeb5149e4af9ee1909c299)

Signed-off-by: Farrell Wymore <farrell.wymore@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Alexandru DAMIAN
7a42bfecc2 bitbake: toastergui: fix built ETA calculation
We fix the calculation showing the estimated time
to build completion.

(Bitbake rev: 5d85d1a7bbbce2c9baaa613c5cc84c511fb88376)

Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
David Reyna
26db62e359 bitbake: toaster: reduce redundant foreign key lookups
Replace redundant foreign key lookups with "with" to improve all
recipes page load time. Do depends pre-lookup in the view class,
and use python itertation instead of filter() all to achieve x16
processing speedup.

[YOCTO #6137]

(Bitbake rev: e068727de686cd6c43cebacdac5b898c134705ef)

Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>

Conflicts:
	bitbake/lib/toaster/toastergui/views.py
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Farrell Wymore
18224a4a46 bitbake: toaster: sort columns properly after edit columns
If a sorted column is made invisible through the edit columns function,
resort the table the its default order.

[YOCTO 5919]

(Bitbake rev: 23908ecddb908d8238be0c1bdbcf2ecf6a9a088f)

Signed-off-by: Farrell Wymore <farrell.wymore@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Dave Lerner
6d0ae0ef44 bitbake: toaster: fix span2 headings for packages
[YOCTO 6147]

Fix bug in views.py that put 'span2' class id in a 'clclass' key
instead of the 'dclass' key.  This fix exposed another problem in
target.html and the target view function that used 'package_size'
instead of 'size' as the 'clclass' which is inconsistent with the
model field name, causing table data columns to be shown when
the header is hidden.

(Bitbake rev: 17183bf7cb539287da7234d296da8e3f8fcf1069)

Signed-off-by: Dave Lerner <dave.lerner@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
David Reyna
153787d4df bitbake: toaster: sort outcome and sstate columns by string value
Sort the 'outcome' and 'sstate_result' columns by their
description string values and not their numerical values.

[YOCTO #5921]

(Bitbake rev: e88e5a79c992ef3218f47adff0587d4f69c01432)

Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Belen Barros Pena
c55dea6a82 bitbake: bitbake: toaster: Fix Empty tasks filter
Somehow the counter was set to count tasks with outcome
'not available', instead of outcome 'empty'. This patch
fixes the problem.

[YOCTO #6146]

(Bitbake rev: 527f7d8ec2f4e75d6f62a967900b27faea317af9)

Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:08 +01:00
Belen Barros Pena
4ab29fc58f bitbake: bitbake: toaster: Fix total number of tasks in build dashboard
The total number of tasks in the build dashboard was counting
_setscene tasks, which are not exposed by Toaster as separate
tasks. This patch makes sure that _setscene tasks are not
counted when calculating that number.

[YOCTO #6145]

(Bitbake rev: a429278c70b55f7c11a9ef3d5af28cf88850a227)

Signed-off-by: Belen Barros Pena <belen.barros.pena@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-20 14:58:07 +01:00
Saul Wold
0bc0ee66a8 local.conf.sample: Add sdl to nativesdk qemu PACKAGECONFIG
Enable SDL by default for nativesdk as we do with natve, this will
allow qemu with ADT to use graphics no vnc by default.

[YOCTO #6446]

(From meta-yocto rev: ff6154b4cb7330e73725294855a5bf9f9a9da980)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-19 17:22:52 +01:00
Scott Rifenbark
db6819b0c3 profile-manual: Fixed a bad title for the intro chapter.
(From yocto-docs rev: dd281ed7ce0cdfc30b87dc6b48077a55cfe09929)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:28 +01:00
Scott Rifenbark
bc3484e76c dev-manual: Fixed a link that was spanning two lines.
Links using <ulink> cannot span two lines or the the
mega-manual.sed file will not convert them.

(From yocto-docs rev: 1748dc63b03691861fa6b00297c2bd467a1e92c5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:28 +01:00
Scott Rifenbark
9d84b2440d mega-manual.sed: Added a processing line for the profile-manual.
Somehow this had been dropped or forgotten for the daisy branch.
It is in there now.

(From yocto-docs rev: 4fcc96945e5114c18da65d2373d69bce3d54f30d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:27 +01:00
Scott Rifenbark
f8e61ed564 documentation: Updated the manual revision history tables for 1.6.1
Added the release date of "July 2014"

(From yocto-docs rev: 7770bbe444c152fb97b9085ac81df91bb0bdbc14)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:27 +01:00
Scott Rifenbark
1db22d39b5 ref-manual: Fixed a link to the BitBake User Manual.
This was a stale link.  Updated to point to the published
HTML file now and to mention that you can find it in the
Source directory.

(From yocto-docs rev: ed8a54999d3e3fa32aae5df39a1ce5ac3fc573f8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:27 +01:00
Scott Rifenbark
b7bf8bb051 ref-manual: Edits to "atom-pc Board Support Package (BSP)" section.
Fixes [YOCTO #6400]

Replaced the sentence in the note to specifically note that the
genericx86-64 BSP has been added for 64-bit Atom systems.

(From yocto-docs rev: 8b238e3aa2019803cc30a00042bae1a2464bd792)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:27 +01:00
Scott Rifenbark
839892ed27 ref-manual: Added ptest default build info to migrating section.
Added a ptest section to the "Moving to the Yocto Project 1.6 Release" section.

Fixes [YOCTO #6400]

Added a new section named "Package Tests (ptest)" to the migration
section stating that ptest is built but not installed by default.
I also added some cross-reference links to a usage section and to
the ptest.bbclass section.

(From yocto-docs rev: c6b8a4e4e4a398196eb2fb050cdfda8957313639)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-18 10:30:27 +01:00
Philip Balister
232af2ec04 python-native : Add patch to fix configure error with gcc 4.8.
We apply this patch to the python recipe already. Without this patch
the zeroc-ice-native recipe will not build.

See: http://bugs.python.org/issue17547 for more details.

(From OE-Core rev: da5c99c7893b589f0d2f2e6d76261b4063ffdd32)

Signed-off-by: Philip Balister <philip@balister.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-17 09:00:26 +01:00
Chen Qi
6a6bd2e96b rootfs.py: change the logic in _uninstall_unneeded
Previously, if we have 'package-management' and 'read-only-rootfs'
both in IMAGE_FEATRUES, we would meet the following error at system
start-up.

	rm: can't remove '/etc/rcS.d/S99run-postinsts': Read-only file system

However, what's really expected is that when there's no postinstall
script at system start-up, the /etc/rcS.d/S99run-postinsts should not
even be there.

Whether or not to remove the init script symlinks to run-postinsts should
not depend on whether we have 'package-management' in IMAGE_FEATURES; rather,
it should only depend on whether we have any postinstall script left to run
at system start-up.

This patch changes the _uninstall_unneeded function based on the logic
stated above.

[YOCTO #6257]

(From OE-Core rev: d51b1ced88958d31a1596e37db871257fe013446)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-17 08:58:54 +01:00
Richard Purdie
3103f04a30 ptest: Work from PTEST_ENABLED, not DISTRO_FEATURES
Some classes of recipe disable ptest even though its in DISTRO_FEATURES
(e.g. nativesdk). We shouldn't attempt to build ptest packages when
its disabled. This replaces some DISTRO_FEATURE checks with PTEST_ENABLED
checks instead.

(From OE-Core rev: d1369fe95ac6732e5747873eccd6a1e74359cea4)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-17 08:58:54 +01:00
Richard Purdie
bb27ca7562 gcc: Clean up configure_prepend and fix for mingw
The do_configure_prepend was duplicated in gcc-4.X.inc and
gcc-configure-common.inc leading to confusion when reading the resulting
do_configure task where the file was processed twice.

The only difference was the removal of the include line for gcc 4.8/4.9.

On mingw were were seeing two issues, firstly that the if statements meant
the values we wanted weren't being set, the second that the include
paths were still wrong as there was no header path set.

To fix the first issue, the #ifdef conditionals were removed, we want
to set these things unconditionally. The second issue is addressed by
setting the NATIVE_SYSTEM_HEADER_DIR variable here (it was already
set in t-oe).

(From OE-Core rev: c19bb1db2eb728899e10a28d10567e9e026ee694)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-16 14:52:08 +01:00
Chong Lu
7dcd9a6b72 dbus: fix a hard dependency about dbus-ptest
If image contains dbus and ptest is in DISTRO_FEATURES, dbus-ptest package
is installed, regardless of whether ptest-pkgs is in IMAGE_FEATURES. This
issue will increase size for most small images.
This patch fixes this problem.

[YOCTO #5702]

(From OE-Core rev: 0416583f014138656babdf78a574357ae5ff25bd)

(From OE-Core rev: d865612c7c1aaccb9f4c65224c9e4c888876fe92)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-16 14:52:07 +01:00
Richard Purdie
a43dba8c29 build-appliance-image: Update to head revision
(From OE-Core rev: d28b21e01fbc4b780d14495894c4253d422cd9d9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-12 17:51:09 +01:00
Elizabeth Flanagan
d52b91316e poky.conf: Bump DISTRO_VERSION
For 1.6.1 we need to bump version.

(From meta-yocto rev: a37e6bfb26424202ed648548fa7e537eb6021b45)

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-12 17:48:20 +01:00
Richard Purdie
efbf15ce20 rpm: Fix cpio 32 bit overflow issues on 64 bit inode filesystems
When building on XFS filesystems, the resulting rpms can be corrupted
with the same inode number being used for multiple hardlinked files.
There are two fixes, one to stop rpm crashing when accessing a broken
binary rpm, the other to stop generating them in the first places. Full
descriptions in the patch headers.

(From OE-Core rev: 53ce6bacccc0fd97487bdf31ff3b7ee098984652)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-12 17:48:20 +01:00
Ross Burton
3caae900f3 Revert "fontconfig: enable 64 bit file support"
Fontconfig doesn't need to be passed large file flags through CPPFLAGS because
it's configure script uses AC_SYS_LARGEFILE.

This reverts commit 5a49a24d35.

(From OE-Core rev: 98f9a9fd359c356c9ce6dd0ba16a557b7a07b788)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:35:40 +01:00
Paul Eggleton
3428e6e0e4 openssl: fix CVE-2014-3470
http://www.openssl.org/news/secadv_20140605.txt

Anonymous ECDH denial of service (CVE-2014-3470)

OpenSSL TLS clients enabling anonymous ECDH ciphersuites are subject to a
denial of service attack.

(Patch borrowed from Fedora.)

(From OE-Core rev: 595f2fc7dd642d729ab61f20a6719a2cc6c80426)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:20 +01:00
Paul Eggleton
96ca984621 openssl: fix CVE-2014-0224
http://www.openssl.org/news/secadv_20140605.txt

SSL/TLS MITM vulnerability (CVE-2014-0224)

An attacker using a carefully crafted handshake can force the use of weak
keying material in OpenSSL SSL/TLS clients and servers. This can be exploited
by a Man-in-the-middle (MITM) attack where the attacker can decrypt and
modify traffic from the attacked client and server.

The attack can only be performed between a vulnerable client *and*
server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers
are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users
of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.

(Patch borrowed from Fedora.)

(From OE-Core rev: fd1d740437017d3ed75684768d6915041cdb0631)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:20 +01:00
Paul Eggleton
8386f4203d openssl: fix CVE-2014-0221
http://www.openssl.org/news/secadv_20140605.txt

DTLS recursion flaw (CVE-2014-0221)

By sending an invalid DTLS handshake to an OpenSSL DTLS client the code
can be made to recurse eventually crashing in a DoS attack.

Only applications using OpenSSL as a DTLS client are affected.

(Patch borrowed from Fedora.)

(From OE-Core rev: 833920fadd58fe353d27f94f340e3a9f6923afb8)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:20 +01:00
Paul Eggleton
b4b50e52d2 openssl: use upstream fix for CVE-2014-0198
This replaces the fix for CVE-2014-0198 with one borrowed from Fedora,
which is the same as the patch which was actually applied upstream for
the issue, i.e.:

https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b107586c0c3447ea22dba8698ebbcd81bb29d48c

(From OE-Core rev: d3d6eee3353fcce09e1d6b0181a0ea7b52b7a937)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:20 +01:00
Paul Eggleton
6101dd2b4c openssl: fix CVE-2014-0195
From the OpenSSL Security Advisory [05 Jun 2014]
http://www.openssl.org/news/secadv_20140605.txt

DTLS invalid fragment vulnerability (CVE-2014-0195)

A buffer overrun attack can be triggered by sending invalid DTLS fragments
to an OpenSSL DTLS client or server. This is potentially exploitable to
run arbitrary code on a vulnerable client or server.

Only applications using OpenSSL as a DTLS client or server affected.

(Patch borrowed from Fedora.)

(From OE-Core rev: 5bcb997663a6bd7a4d7395dcdb5e027d7f2bab81)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:20 +01:00
Roy Li
ebf62ba85d openssl: add openssl-CVE-2010-5298.patch SRC_URI
make openssl-CVE-2010-5298.patch truely work

(From OE-Core rev: eab33442480cc27a5cd00b3f46984fea74b7c0f9)

(From OE-Core rev: 1bd77c28fdb51d1a0dad55c8d1af2991046c801d)

Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-connectivity/openssl/openssl_1.0.1g.bb
2014-06-10 17:12:19 +01:00
Saul Wold
9deb3333b0 update-rc.d/useradd: Add additional dependecies
These dependcies are needed to ensure that thier packages are created
correctly since these classes have runtime dependiences in their packages
but they are not actually created yet at rootfs time.

[YOCTO #6072]

(From OE-Core rev: bba835fed88c3bd5bb5bd58962034aef57c408d8)

(From OE-Core rev: 8c4ea49ba8440871f5a7008c7fa20f93bfb35d78)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Chen Qi
5bb9a05e0f systemd: update a uclibc specific patch to avoid segment fault
The alloca() function allocates space in the stack frame of the caller,
so using alloca(new_size - old_size) would possibly crash the stack,
causing a segment fault error.

This patch fixes the above problem by avoiding using this function in
journal-file.c.

[YOCTO #6201]

(From OE-Core rev: 96b6a2d446d28eabd9a943f5f2b5af12c24a7dbb)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Richard Purdie
9ee3f77ed9 image_types: Fix ubi filesystem return codes
If the first command returns an error, it will not cause the image generation
step to fail. Simply split up the statement into multiple lines to avoid
this issue, they no longer need to be one line expressions.

[YOCTO #6391]

(From OE-Core rev: f8125a1e9b6893a12355d55d4df584a8d97f0bff)

(From OE-Core rev: 414f9b4d2dd39845b537ebdc2a4ecafbd9162343)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Khem Raj
a714cf8700 x264: Update SRCREV to match commit in upstream git repo
It seems that 585324fee380109acd9986388f857f413a60b896 is no
longer there in git and it has been rewritten to
ffc3ad4945da69f3caa2b40e4eed715a9a8d9526

Change-Id: I9ffe8bd9bcef0d2dc5e6f6d3a6e4317bada8f4be
(From OE-Core rev: b193c7f251542aa76cb5a4d6dcb71d15b27005eb)

(From OE-Core rev: f2b20b169a462cf4c6e6f341b76add8a0f4d6e3f)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Trevor Woerner
d376e31c92 grub_git: fix build warning->error
This patch fixes a build warning which is promoted to an error via -Werror.

changes from v1:
 * put "Upstream-Status" in patch itself, not in OE patch header
 * fix commit wording

(From OE-Core rev: 4b41f4199d77144a629897173cff3d1efcfa85f9)

(From OE-Core rev: 69f9022126d3cd21001f48ec36730982e53a6a48)

Signed-off-by: Trevor Woerner <trevor.woerner@linaro.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Richard Purdie
333e5f7076 sanity.bbclass: Add libsdl-native check
If libsdl-native is in ASSUME_PROVIDED, check for it in the sanity tests.
This warns the user if they've said its being provided but it isn't and
prevents silent build issues.

(From OE-Core rev: d9d7b0515fcf47c4cf7533a12915ea92298ce834)

(From OE-Core rev: b26e4596d56db4120a81a07268fd174e14240e2b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:19 +01:00
Richard Purdie
a2fa51bdde libfm: Ensure m4 directory exists
configure.ac references the m4 directory so things like gtkdocize
will try and place m4 files there. We need to ensure the directory
exists or the builds can fail.

(From OE-Core rev: 0ced649c055dd25c500d0fd34e4ea94504d98580)

(From OE-Core rev: ce4cc1e8b48fb368fa96f63ee43a35d6ed142b21)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Cristian Iorga
cb468dfaf0 v86d: fix for SeaBIOS VGA BIOS compatibility
This fixes a compatibility issue between v86d
and SeaBIOS VGA BIOS where the leal instruction
is not decoded properly. Read the
http://thread.gmane.org/gmane.comp.emulators.qemu/271806
thread for more details.
Patch taken from upstream.

(From OE-Core rev: 3e890dd00ed27cc30800caefa85827cb16da5a3a)

(From OE-Core rev: 730206ccbcbe7f75a5946b64fba82a794cd9da5a)

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Saul Wold
d4c5f12601 util-linux: add sulogin to alternatives list
sulogin is provided by both busybox in /sbin/sulogin and util-linux provides one
in /usr/sbin/sulogin, so move util-linux's to sbin and setup ALTERNATIVE_LINK.

[YOCTO #6384]

(From OE-Core rev: a827ca74d27b916df8d40ec8155bc0340f8a0487)

(From OE-Core rev: 92f0657a89087a4a388030fdb04aaad80aca918d)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Dan McGregor
7e6902963f gzip: Avoid host contamination during build
On systems with /bin and /usr/bin merged the gzip recipe may find grep
in /usr/bin, while OE puts it in /bin. Force the recipe to find grep in
the correct place.

(From OE-Core rev: 8ae714bb59c67433ded1efe6a8750e0e9c126dab)

(From OE-Core rev: 26e46f935cc98845225c41d954b34b3312a4c37d)

Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Richard Purdie
c166a5add3 classextend: Fix crosssdk remapping for multilib
Multilib builds only require one crosssdk toolchain. We therefore shouldn't
be remapping crosssdk names. This resolves build failures looking for
weird multilib crosssdk toolchains.

(From OE-Core rev: aa8b93e2db06866529d20939452f81fb9e18aaab)

(From OE-Core rev: d5a9290649fb493b6ac8b585d82ee9f02d138147)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
João Henrique Ferreira de Freitas
303d17ac3c combo-layer: fix revlist taking into account file_filter
If file_filter is set, git format-patch takes account but git rev-list
does not. So revlist is going to get with wrong revisions. And last_revision
will be updated with wrong revision. The next time that user run
combo-layer it complain about applying patches.

So ensure that 'git rev-list' are using file_filter as 'git format-patch'.

(From OE-Core rev: c22e40900d8e33c2c884e714c11ddb771b86923f)

(From OE-Core rev: 7ad5b4dece1d8fba6f1b6b530830384e6c8fb74f)

Signed-off-by: João Henrique Ferreira de Freitas <joaohf@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Chen Qi
28938930ba update-rc.d: fix to handle priority numbers correctly
The update-rc.d treated priority numbers begin with '0' as octal
numbers. This led to problems of update-rc.d being unable to handle
priorities like '08' or '09' correctly.

This patch fixes the above problem.

[YOCTO #6376]

(From OE-Core rev: 675fd834b9ed696cd87809830d57d3da083580d3)

(From OE-Core rev: b59efa053d1396efd3d5a9c7f88fb5088b063686)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-10 17:12:18 +01:00
Khem Raj
bff6db6712 eglibc: Fix configure when re-building with gold
(From OE-Core rev: 2a36a02c2444551579b8498468debfaff0faa6d8)

(From OE-Core rev: 1e2aa57d621fa816fa7fc652a3b7d2920844c74d)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-core/eglibc/eglibc_2.19.bb
2014-06-10 17:12:18 +01:00
Valentin Popa
62b1fef787 gnutls: patch for CVE-2014-3466 backported
Backported patch for CVE-2014-3466.
This patch is for daisy.

(From OE-Core rev: ca2773b19db4881abe5244c373d94ff05cd2684f)

Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-06 10:27:50 +01:00
Saul Wold
fc9229e4ba fontconfig: enable 64 bit file support
When running 32bit code on a large filessytem with 64bit inodes, the
fontcache was not being created correctly because an EOVERFLOW was being
returned from the fstat when reading the 64 inode on a 32bit system.

The fontcache is created at rootfs time on the host system via qemu.

[YOCTO #6338]

(From OE-Core rev: ca220681f1ba0fedeab68e96df58f36c4fbc7473)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-06 09:32:31 +01:00
Saul Wold
8509c1a7e5 freetype: enable 64 bit file support
When running 32bit code on a large filessytem with 64bit inodes, the
fontcache was not being created correctly because an EOVERFLOW was being
returned from the fstat when reading the 64 inode on a 32bit system.

The fontcache is created at rootfs time on the host system via qemu.

[YOCTO #6338]

(From OE-Core rev: bf6fcfa17d73171623a4d27089c32031705c2591)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-06 09:32:31 +01:00
Saul Wold
05d751c23a busybox: fix meta-yocto's bbappend's FILESEXTRAPATH
The FILESEXTRAPATH was not getting used correctly since our distro
OVERRIDE is for poky-tiny, not poky, so just remove it, also we are
not using a version directory so ensure we get correct BPN (Base Package
Name).

[YOCTO #6353]

(From meta-yocto rev: 34b3fde299faa47cf6330cefa46b0e54ddcbbc42)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-06 09:27:34 +01:00
Richard Purdie
b8f6c7c794 qemu/local.conf.sample: Add sdl PACKAGECONFIG
Currently the SDL configuration option for qemu floats. This is confusing to new users
and makes the build non-determinstic. This patch adds a PACKAGECONFIG option, defaulting
to off and adds documentation to local.conf.sample leaving it on by default since this
is the configuration our quick start assumes.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 15:15:26 +01:00
Khem Raj
474ea6b826 binutils: Fix building nativesdk binutils with gcc 4.9
Patches explain the issue in detail but this is exposed
with gcc 4.9 in binutils 2.24

(From OE-Core rev: fc5c467b680fc5aef4b0f689e6988e17a9322ae0)

(From OE-Core rev: 4dfb8847ebf8aab90ad8888933468e2899c96998)

(From OE-Core rev: af347d3298e15552d502d5b2ce497bbda9705bc7)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:31 +01:00
Denys Dmytriyenko
21d15fac0e cryptodev-tests: recipe for cryptodev test suite based on OpenSSL
(From OE-Core rev: c54fa061da6195081cd29817a351a36377b58e53)

(From OE-Core rev: 7c58b852f21588b2763a1b90d8f3cf2f31a868e2)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:31 +01:00
Denys Dmytriyenko
e98512e1e3 cryptodev-module: recipe for out-of-tree cryptodev device driver
Depends on cryptodev-linux for providing a header file

(From OE-Core rev: b7587d2ef7642dcc248744ade8f85f815185e78c)

(From OE-Core rev: a0930e6dfabc32a0f1f116a9de05c2b4b3b3a216)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:31 +01:00
Denys Dmytriyenko
1f80e7f675 cryptodev-linux: create common .inc file to be shared by module and tests
(From OE-Core rev: a3a834cf9f35682655661a7c6ba66c1de3491320)

(From OE-Core rev: d069595deb434cb6a0e8caf6f156cb20630dff97)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Denys Dmytriyenko
6a4a66aabb cryptodev-linux: move to recipes-kernel to be shared with module and tests
(From OE-Core rev: e7aace7658fabe41839a3ec1b596bf28c6a4c02e)

(From OE-Core rev: 421e8aa969135097fcc2da0625ad74c1934297a2)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
c03bb4d0c7 gst-ffmpeg: fix for Security Advisory CVE-2013-0849
The roq_decode_init function in libavcodec/roqvideodec.c in FFmpeg
before 1.1 allows remote attackers to have an unspecified impact via a
crafted (1) width or (2) height dimension that is not a multiple of
sixteen in id RoQ video data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0849

(From OE-Core rev: 1a43a8054f51fbd542f3f037dc35f8b501e455bf)

(From OE-Core rev: 2a6b495d9f6017874057942b1ba42ab220c7c517)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
f91b780b1a gst-ffmpeg: fix for Security Advisory CVE-2013-0850
The decode_slice_header function in libavcodec/h264.c in FFmpeg before
1.1 allows remote attackers to have an unspecified impact via crafted
H.264 data, which triggers an out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0850

(From OE-Core rev: 69f3f0f94f4fd224e5a6b275207adf0539d085c3)

(From OE-Core rev: bf7b08d94c1d8282ca7ea584254d5c0d1fd7e469)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
938e925356 gst-ffmpeg: fix for Security Advisory CVE-2013-0856
The lpc_prediction function in libavcodec/alac.c in FFmpeg before 1.1
allows remote attackers to have an unspecified impact via crafted Apple
Lossless Audio Codec (ALAC) data, related to a large nb_samples value.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0856

(From OE-Core rev: 571ccce77859435ff8010785e11627b20d8b31f4)

(From OE-Core rev: a51eb5fc4c5c2da67219bdd0d84c6fab8ed2343e)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
c899777010 gst-ffmpeg: fix for Security Advisory CVE-2013-0854
The mjpeg_decode_scan_progressive_ac function in libavcodec/mjpegdec.c
in FFmpeg before 1.1 allows remote attackers to have an unspecified
impact via crafted MJPEG data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0854

(From OE-Core rev: b3d9c8f603ebdbc21cb2ba7e62f8b5ebb57c40c1)

(From OE-Core rev: ed928b72dcc9a7eca01abb41aabca3553c47ffe3)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
afb6a3688f gst-ffmpeg: fix for Security Advisory CVE-2013-0851
The decode_frame function in libavcodec/eamad.c in FFmpeg before 1.1
allows remote attackers to have an unspecified impact via crafted
Electronic Arts Madcow video data, which triggers an out-of-bounds array
access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0851

(From OE-Core rev: 8c9868d074f5d09022efc9419ee09eb805f68394)

(From OE-Core rev: ae619444026ebfa0dd7e87a37571d56d558f37d6)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
4209379cc8 gst-ffmpeg: fix for Security Advisory CVE-2013-0858
The atrac3_decode_init function in libavcodec/atrac3.c in FFmpeg before
1.0.4 allows remote attackers to have an unspecified impact via ATRAC3
data with the joint stereo coding mode set and fewer than two channels.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0858

(From OE-Core rev: 0ee8754c973f5eff3ba4d00319a5308888c12b17)

(From OE-Core rev: 58aaf7ef101efb046a03e65fb084e9dfe871c648)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
6add5ac648 gst-ffmpeg: fix for Security Advisory CVE-2013-0852
The parse_picture_segment function in libavcodec/pgssubdec.c in FFmpeg
before 1.1 allows remote attackers to have an unspecified impact via
crafted RLE data, which triggers an out-of-bounds array access.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0852

(From OE-Core rev: 37f9371b44bd914fdd64e4c4e4448a2908512203)

(From OE-Core rev: e7fc2b61bc44df58a23d02775847015a52ea8fcb)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
af515ca686 gst-ffmpeg: fix for Security Advisory CVE-2013-0845
libavcodec/alsdec.c in FFmpeg before 1.0.4 allows remote attackers to
have an unspecified impact via a crafted block length, which triggers an
out-of-bounds write.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0845

(From OE-Core rev: cc6e2ee53c49206aa3377c512c3bd1de2e14a7b7)

(From OE-Core rev: 0cfba084a543bc928de8da2ea95ed6aa11a05fa3)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:30 +01:00
Yue Tao
f9f97a1fed gst-ffmpeg: fix for Security Advisory CVE-2013-0868
libavcodec/huffyuvdec.c in FFmpeg before 1.1.2 allows remote attackers
to have an unspecified impact via crafted Huffyuv data, related to an
out-of-bounds write and (1) unchecked return codes from the init_vlc
function and (2) len==0 cases.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0868

(From OE-Core rev: 29dcc2c8e834cf43e415eedefb8fce9667b3aa40)

(From OE-Core rev: 8229523ea86e9545cc0ee9e34af12a2f84d0809e)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
48169ac9bc gst-ffmpeg: fix for Security Advisory CVE-2014-2099
The msrle_decode_frame function in libavcodec/msrle.c in FFmpeg before
2.1.4 does not properly calculate line sizes, which allows remote
attackers to cause a denial of service (out-of-bounds array access) or
possibly have unspecified other impact via crafted Microsoft RLE video
data.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2099

(From OE-Core rev: 3e27099f9aad1eb48412b07a18dcea398c18245b)

(From OE-Core rev: 5898f20bb2f38a91b2dd1b4cc4798fd960331a14)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
f091b8a3cf gst-ffmpeg: fix for Security Advisory CVE-2013-0865
The vqa_decode_chunk function in libavcodec/vqavideo.c in FFmpeg before
1.0.4 and 1.1.x before 1.1.2 allows remote attackers to have an
unspecified impact via a large (1) cbp0 or (2) cbpz chunk in Westwood
Studios VQA Video file, which triggers an out-of-bounds write.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0865

(From OE-Core rev: 4a93fc0a63cedbebfdc9577e2f1deb3598fb5851)

(From OE-Core rev: 62854105de72f09dcffa08dbdc975e8f306a4a39)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
38083d01e7 gst-ffmpeg: fix for Security Advisory CVE-2014-2263
The mpegts_write_pmt function in the MPEG2 transport stream (aka DVB)
muxer (libavformat/mpegtsenc.c) in FFmpeg, possibly 2.1 and earlier,
allows remote attackers to have unspecified impact and vectors, which
trigger an out-of-bounds write.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2263

(From OE-Core rev: 70bf8c8dea82e914a6dcf67aefb6386dbc7706cd)

(From OE-Core rev: 408581d744221a1dc723ed6bf4985b1021aa52c4)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
278c551168 openssl: fix for CVE-2010-5298
Race condition in the ssl3_read_bytes function in s3_pkt.c in OpenSSL
through 1.0.1g, when SSL_MODE_RELEASE_BUFFERS is enabled, allows remote
attackers to inject data across sessions or cause a denial of service
(use-after-free and parsing error) via an SSL connection in a
multithreaded environment.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5298

(From OE-Core rev: 751f81ed8dc488c500837aeb3eb41ebf3237e10b)

(From OE-Core rev: da3ba2886c27ce222f8c394e8fa56bbf8a128de6)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
83d1ce9e27 tiff: fix for Security Advisory CVE-2013-4231
Multiple buffer overflows in libtiff before 4.0.3 allow remote attackers
to cause a denial of service (out-of-bounds write) via a crafted (1)
extension block in a GIF image or (2) GIF raster image to
tools/gif2tiff.c or (3) a long filename for a TIFF image to
tools/rgb2ycbcr.c. NOTE: vectors 1 and 3 are disputed by Red Hat, which
states that the input cannot exceed the allocated buffer size.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4231Multiple
buffer overflows in libtiff before 4.0.3 allow remote attackers to cause
a denial of service (out-of-bounds write) via a crafted (1) extension
block in a GIF image or (2) GIF raster image to tools/gif2tiff.c or (3)
a long filename for a TIFF image to tools/rgb2ycbcr.c. NOTE: vectors 1
and 3 are disputed by Red Hat, which states that the input cannot exceed
the allocated buffer size.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4231

(From OE-Core rev: 19e6d05161ef9f4e5f7277f6eb35eb5d94ecf629)

(From OE-Core rev: c21a6b18001801532c459579b9ebfc8ae824dace)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Li Wang
d44881fecc nss: CVE-2013-1740
the patch comes from:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1740
https://bugzilla.mozilla.org/show_bug.cgi?id=919877
https://bugzilla.mozilla.org/show_bug.cgi?id=713933

changeset:   10946:f28426e944ae
user:        Wan-Teh Chang <wtc@google.com>
date:        Tue Nov 26 16:44:39 2013 -0800
summary:     Bug 713933: Handle the return value of both ssl3_HandleRecord calls

changeset:   10945:774c7dec7565
user:        Wan-Teh Chang <wtc@google.com>
date:        Mon Nov 25 19:16:23 2013 -0800
summary:     Bug 713933: Declare the |falseStart| local variable in the smallest

changeset:   10848:141fae8fb2e8
user:        Wan-Teh Chang <wtc@google.com>
date:        Mon Sep 23 11:25:41 2013 -0700
summary:     Bug 681839: Allow SSL_HandshakeNegotiatedExtension to be called before the handshake is finished, r=brian@briansmith.org

changeset:   10898:1b9c43d28713
user:        Brian Smith <brian@briansmith.org>
date:        Thu Oct 31 15:40:42 2013 -0700
summary:     Bug 713933: Make SSL False Start work with asynchronous certificate validation, r=wtc

(From OE-Core rev: 11e728e64e37eec72ed0cb3fb4d5a49ddeb88666)

(From OE-Core rev: 9f5402d5e40b82213fdfc09fcfc71d22f8bf5a0e)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Li Wang
948b8461e8 nss: CVE-2014-1492
the patch comes from:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1492
https://bugzilla.mozilla.org/show_bug.cgi?id=903885

changeset:   11063:709d4e597979
user:        Kai Engert <kaie@kuix.de>
date:        Wed Mar 05 18:38:55 2014 +0100
summary:     Bug 903885, address requests to clarify comments from wtc

changeset:   11046:2ffa40a3ff55
tag:         tip
user:        Wan-Teh Chang <wtc@google.com>
date:        Tue Feb 25 18:17:08 2014 +0100
summary:     Bug 903885, fix IDNA wildcard handling v4, r=kaie

changeset:   11045:15ea62260c21
user:        Christian Heimes <sites@cheimes.de>
date:        Mon Feb 24 17:50:25 2014 +0100
summary:     Bug 903885, fix IDNA wildcard handling, r=kaie

(From OE-Core rev: a83a1b26704f1f3aadaa235bf38094f03b3610fd)

(From OE-Core rev: 65ebe470a8d69073d0ebce3111abdb0c2e2ebe3c)

Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
7bcc609bf0 subversion: fix for Security Advisory CVE-2013-4277
Svnserve in Apache Subversion 1.4.0 through 1.7.12 and 1.8.0 through
1.8.1 allows local users to overwrite arbitrary files or kill arbitrary
processes via a symlink attack on the file specified by the --pid-file
option.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4277

(From OE-Core rev: e0e483c5b2f481240e590ebb7d6189a211450a7e)

(From OE-Core rev: 0517d47172c68097e30a5063cd09c1da6158c71d)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
f372806546 subversion: fix for Security Advisory CVE-2013-1847 and CVE-2013-1846
The mod_dav_svn Apache HTTPD server module in Subversion 1.6.x before 1.6.21
and 1.7.0 through 1.7.8 allows remote authenticated users to cause a denial of
service (NULL pointer dereference and crash) via a LOCK on an activity URL.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1846

The mod_dav_svn Apache HTTPD server module in Subversion 1.6.0 through 1.6.20
and 1.7.0 through 1.7.8 allows remote attackers to cause a denial of service
(NULL pointer dereference and crash) via an anonymous LOCK for a URL that does
not exist.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1847

(From OE-Core rev: 3962b76185194fa56be7f1689204a1188ea44737)

(From OE-Core rev: 8d52c071e66ff02a9f5ea9d4a60f3e06905b01db)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:29 +01:00
Yue Tao
2361a8171b subversion: fix for Security Advisory CVE-2013-1845
The mod_dav_svn Apache HTTPD server module in Subversion 1.6.x before
1.6.21 and 1.7.0 through 1.7.8 allows remote authenticated users to
cause a denial of service (memory consumption) by (1) setting or (2)
deleting a large number of properties for a file or directory.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1845

(From OE-Core rev: 432666b84b80f8b0d13672aa94855369f577c56d)

(From OE-Core rev: 890cbced4c2bc45db3b5ec493d5f390f2de70bc2)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:28 +01:00
Yue Tao
ee4d106987 subversion: fix for Security Advisory CVE-2013-4131
The mod_dav_svn Apache HTTPD server module in Subversion 1.7.0 through
1.7.10 and 1.8.x before 1.8.1 allows remote authenticated users to cause
a denial of service (assertion failure or out-of-bounds read) via a
certain (1) COPY, (2) DELETE, or (3) MOVE request against a revision
root.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4131

(From OE-Core rev: ce41ed3ca5b6ef06c02c5ca65f285e5ee8c04e7f)

(From OE-Core rev: 0cb67304f5b124d21468fcbc2928c7cb1f37c5f6)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:28 +01:00
Yue Tao
896511d564 subversion: fix for Security Advisory CVE-2013-4505
The is_this_legal function in mod_dontdothat for Apache Subversion 1.4.0
through 1.7.13 and 1.8.0 through 1.8.4 allows remote attackers to bypass
intended access restrictions and possibly cause a denial of service
(resource consumption) via a relative URL in a REPORT request.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4505

(From OE-Core rev: 02314673619f44e5838ddb65bbe22f9342ee6167)

(From OE-Core rev: d245459306939aef078a89e671ec093e3d6321cd)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:28 +01:00
Yue Tao
01c613e4bc subversion: fix for Security Advisory CVE-2013-1849
Reject operations on getcontentlength and getcontenttype properties
if the resource is an activity.

(From OE-Core rev: 94e8b503e8a5ae476037d4aa86f8e27d4a8c23ea)

(From OE-Core rev: 4a67bb2a27c1c32b2a912b603e1c543db9e1810e)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:28 +01:00
Yue Tao
295dd76931 screen: fix for Security Advisory CVE-2009-1215
Race condition in GNU screen 4.0.3 allows local users to create or
overwrite arbitrary files via a symlink attack on the
/tmp/screen-exchange temporary file.

(From OE-Core rev: be8693bf151987f59c9622b8fd8b659ee203cefc)

(From OE-Core rev: 6874667333d83960d03f1b30030fe42b747b5972)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-extended/screen/screen_4.0.3.bb
2014-05-29 13:43:28 +01:00
Yue Tao
cd7e7addd7 Screen: fix for Security Advisory CVE-2009-1214
GNU screen 4.0.3 creates the /tmp/screen-exchange temporary file with
world-readable permissions, which might allow local users to obtain
sensitive session information.

(From OE-Core rev: 25a212d0154906e7a05075d015dbc1cfdfabb73a)

(From OE-Core rev: f61238b9431e6470d7e76f8c37c51cebe069514a)

Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-extended/screen/screen_4.0.3.bb
2014-05-29 13:43:28 +01:00
Chen Qi
ac9725acc5 openssh: fix for CVE-2014-2653
The verify_host_key function in sshconnect.c in the client in OpenSSH 6.6 and
earlier allows remote servers to trigger the skipping of SSHFP DNS RR checking
by presenting an unacceptable HostCertificate.

(From OE-Core rev: 7b2fff61b3d1c0566429793ee348fa8978ef0cba)

(From OE-Core rev: 6a8a9903de24cc7e1f27b1f7202bd4157719327c)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-connectivity/openssh/openssh_6.5p1.bb
2014-05-29 13:43:28 +01:00
Chen Qi
b6124bdbfb openssh: fix for CVE-2014-2532
sshd in OpenSSH before 6.6 does not properly support wildcards on
AcceptEnv lines in sshd_config, which allows remote attackers to
bypass intended environment restrictions by using a substring located
before a wildcard character.

(From OE-Core rev: a8d3b8979c27a8dc87971b66a1d9d9282f660596)

(From OE-Core rev: e5786afbfa79e1288d1df2401684c4c151c60406)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-connectivity/openssh/openssh_6.5p1.bb
2014-05-29 13:43:28 +01:00
Drew Moseley
989013222e mesa-demos: Specify the lib dir properly.
Use STAGING_EXECPREFIXDIR to specify the location of glut
header files and libs rather than STAGING_LIBDIR.

Also revert the previous unneeded change to glut.patch.

(From OE-Core rev: f38c1846184722180d9091a7a5c1e6e20eed7f2c)

(From OE-Core rev: 1a965b2ecca07d231a8058e453cbeafacc5b6c69)

Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:28 +01:00
Drew Moseley
87eaf4cf4a mesa-demos: Specify the lib dir to locate glut libraries
(From OE-Core rev: 55ecbebdf13ef46f0fb4d87ef11651fe692be33d)

(From OE-Core rev: 359a3317684cdd61b35bf569b0b65148e89abe12)

Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:27 +01:00
Joe Slater
8e22337e22 qemu: define PACKAGECONFIG[] for ssh2
qemu configure will search for libssh2 if we do not enable or
disable it's use, resulting in non-deterministic builds.  We
define PACKAGECONFIG[] to avoid this.

(From OE-Core rev: ecb819b12a89e4e944974068d2e20ed226979317)

(From OE-Core rev: f9f2f347571b0c15813354de1a2ce275c878b7fb)

Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:43:26 +01:00
Chen Qi
e130d2c8eb gdb: add PACKAGECONFIG for babeltrace
Add PACKAGECONFIG for 'babeltrace' so that we don't have the implicit
dependency which might lead to problems when building images.

As an example of showing what problem we might have without this patch,
see the following steps which would lead to a failure.
1. IMAGE_INSTALL_append = " gdb"
2. bitbake babeltrace
3. bitbake gdb
4. bitbake babeltrace -ccleansstate
5. bitbake core-image-minimal

The rootfs process would fail with the following error message.
error: Can't install gdb-7.7-r0@i586: no package provides babeltrace >= 1.2.1+git0+66c2a20b43

(From OE-Core rev: 3c34d9391136b09bc2e7b0bda6cdc96507845c4b)

(From OE-Core rev: ebe73f25c68780d1a5f593e7b842312ac738b324)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Richard Purdie
a692a9182a rt-tests: Fix warning flag typo
As per the comment, this makes it match the Makefile

(From OE-Core rev: 6fce92430e6e837d068eb8531dcd432f38adca3a)

(From OE-Core rev: be4aef60e6da08b77a5c1fbbf783305bee9f96ae)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Mark Hatle
44fddc9ba1 rpm: Fix rpm -V usage
[YOCTO #6309]

It appears a logic issue has caused rpm -V to no longer
verify the files on the filesystem match what was installed.

(From OE-Core rev: 117862cd0eebf6887c2ea6cc353432caee2653aa)

(From OE-Core rev: 0fe6974b3a4bd4d4fc1d8d4398650c1313840f01)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Laurentiu Palcu
8bbd5958b0 adt_installer: run autoreconf before configuring opkg
opkg fails to build on hosts with older autotools versions.

[YOCTO #6293]

(From OE-Core rev: 01f3afece8917a5f965f463b79e04693b0d2932a)

(From OE-Core rev: 41da4686404e130ac844ac7ea3553b38cff6aa88)

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Richard Purdie
6d898aef4c git: Fix various makefile flags
We need to pass CFLAGS and LDFLAGS to the makefile correctly so we
need to list them as part of EXTRA_OEMAKE.

We also have a problem where git hardlinks binaries in bindir with
those in its libexecdir. If we change the RPATH in one of them, it
breaks the other. We therefore set the no cross dir hardlinking flag
git already has for this kind of issue. This ensures the RPATHS for
the git-core binaries works correctly. Its pure luck this has
sometimes worked so far.

(From OE-Core rev: 64c6ae6a69215b659b82c67e238bc0fbc09a3eab)

(From OE-Core rev: 9b2e7dcb8cbf00670954d8314f4a8f97b674274d)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Koen Kooi
412cb58083 ca-certificates: generate CAfile for -native in do_install
Git-replacement-native needs the generated files in place for https:// URIs:

WARNING: Failed to fetch URL git://github.com/kernelslacker/trinity.git;protocol=https, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository '/build/linaro/build/build/downloads/git2/github.com.kernelslacker.trinity.git'...
fatal: unable to access 'https://github.com/kernelslacker/trinity.git/': error setting certificate verify locations:
 CAfile: /build/linaro/build/build/tmp-eglibc/sysroots/x86_64-linux/etc/ssl/certs/ca-certificates.crt
 CApath: none

ERROR: Function failed: Fetcher failure for URL: 'git://github.com/kernelslacker/trinity.git;protocol=https'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /build/linaro/build/build/tmp-eglibc/work/aarch64-oe-linux/trinity/1.3-r0/temp/log.do_fetch.7843
ERROR: Task 1378 (/build/linaro/build/meta-linaro/meta-linaro/recipes-extra/trinity/trinity_1.3.bb, do_fetch) failed with exit code '1'

(From OE-Core rev: 74a772727cbf4d76d2ef314041acafb3086e4ff9)

(From OE-Core rev: 90c97c32d982ede16297c2cd5a5fb9d6794f5401)

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Tudor Florea
57ccbc4c15 curl: remove inapporpriate file from curl release
This is the adaptation for the a bugfix upstream
The inappropriate file src/tool_hugehelp.c presence in the curl 7.36 release
interfered with the upstream fix for
https://sourceforge.net/p/curl/bugs/1350/

(From OE-Core rev: c5a52f5b5ae7c5528bc59ee7fb69a2f460a89b81)

(From OE-Core rev: 59c390885d9a6562c02cca0a6193a88aa2a72e78)

Signed-off-by: Tudor Florea <tudor.florea@enea.com>

[sgw - rebased patch for daisy]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Koen Kooi
5d3c54a318 curl: make PACKAGES match with FILES/RRECOMMENDS
Mostly cosmetic, but entries in PACKAGES should be specified the exact same way as FILES/RRECOMMENDS entries to avoid problems.

(From OE-Core rev: 4d2a7f47a9830788455afe00a7c6a857cebbcb81)

(From OE-Core rev: 66ba1d0e800b67399028d0f164f8f39b1a9fbe88)

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Ross Burton
e5727ad31a freetype: disable harfbuzz
Freetype has an automatically detected dependency on Harfbuzz, which has a
dependency on Freetype.

To produce deterministic builds and avoid link failures when rebuilding freetype
with harfbuzz present add a PACKAGECONFIG for Harfbuzz and disable it by
default.

(From OE-Core rev: 17131d42c02b591e1b6d547852cb09b004b8d609)

(From OE-Core rev: 4bb76f0e21e699bd70e52b8cbd7c6986d179bd8a)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:24 +01:00
Chong Lu
0cafa0eafe syslinux-native: fix parallel building issue
There might be an error when parallel build:

[snip]
cp: cannot create directory `tmp/sysroots/x86_64-linux/usr/share/
syslinux/com32/include/gplinclude': No such file or directory
make[4]: *** [install] Error 1
make[3]: *** [gpllib] Error 2
[snip]

This is a potential issue. In ${S}/com32/gpllib/Makefile file,
install target wants to copy $(SRC)/../gplinclude to
$(INSTALLROOT)$(COM32DIR)/include/ directory, but in ${S}/com32/lib/Makefile
file, the install target will remove $(INSTALLROOT)$(COM32DIR)/include
directory. We need to do com32/lib first.

The patch make com32/gpllib depends on com32/lib to fix this issue.

(From OE-Core rev: cae1a039658cfb47390650ad5b56536ff19e1217)

(From OE-Core rev: fa97064172a2191fbb778565475a074d08d54f9a)

Signed-off-by: Chong Lu <Chong.Lu@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Chen Qi
bea6067392 runqemu-internal: add "console=ttyS0" to ramfs image kernel parameters
We need this kernel command parameter so that when we start a ramfs
image, we can actually get some output. Although we can make this
happen by specifying the 'bootparams' for the 'runqemu' command, it's
better to make this the default behaviour.

(From OE-Core rev: 3d202594bb92fe75cd70f81345e64c2179b52c32)

(From OE-Core rev: 99162f2aef8715797bde98d9f9d4b52ddbca4996)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Sebastian Wiegand
c056b5e9a2 distro_features_check.bbclass: fix wrong indentation
To fix check of REQUIRED_DISTRO_FEATURES fix indentation in python code.

[YOCTO #6349]
Reported and written by: Sebastian Wiegand <sebastian.wiegand@gersys.de>
(From OE-Core rev: 986db87a3931edce8be79f309d07497e4179a810)

(From OE-Core rev: d56b29b251d94f16992726a0ed0192693265a20d)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Maxin B. John
7bb4692ead bzip2: fix ptest execution failure
This patch fixes the bzip2 ptest execution failure:

root@qemux86:/usr/lib/bzip2/ptest# ./run-ptest
make: *** No rule to make target 'runtest'.

(This is also applicable for daisy branch)

(From OE-Core rev: a8157ba1682c650962150f941b2db775156bbde6)

(From OE-Core rev: 0927dbf7183574fc17f3684fff39a74385b971a5)

Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Martin Jansa
dea4a69cfc lttng-modules: Fix build with older kernels for 2.3.3 as 2.4.0
Apply the change "lttng-modules: Fix 3.14 bio tracepoints" to
2.3.3 as well as 2.4.0.

(From OE-Core rev: a419ad43a5b3aa5bc3aa095af4d79abe4c24b0d7)

(From OE-Core rev: d02b69b622d0900add7a30879b82281be2cfd88a)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Chen Qi
53d2def225 tcf-agent: add systemd support
Add systemd unit file tcf-agent.service.

(From OE-Core rev: 1a4feebf98780f586bf2e81cf9844e6805a50799)

(From OE-Core rev: 22f99c2aca4af26520ad75b33bb48f2a248ab7af)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Martin Jansa
94e2a1793e defaultsetup: enable blacklist by default
(From OE-Core rev: 2e88b0b7f4cca7829f5ac3e9190084cc88b0a1b8)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Martin Jansa
b20ba9c4e5 gtk+: Add PACKAGECONFIG for directfb
* building without x11 doesn't work, because it sets default
  gdkbackend to x11 and then requires cairo-xlib to be available
* checking for CAIRO_BACKEND... no
  configure: error: Package requirements (cairo-xlib >= 1.6) were not met:

  No package 'cairo-xlib' found

(From OE-Core rev: 345b27ac4f7439f8676b4506540b0c1ced75c0db)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Khem Raj
7f4ff1a5c5 lttng-modules_2.3.3.bb: Fix build on ARM/gcc-4.9
Update the structure to work with immutable bio_vecs

(From OE-Core rev: 09d3d8f97d6c60707b8dfb3fa5b04fa2efe6f6f6)

(From OE-Core rev: b32d57e5a807a634c411628af1688aec960ac6e7)

(From OE-Core rev: 4fac143f83532fc1cd4d2bed13c8d7a7663d78dc)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:23 +01:00
Martin Jansa
8fd7098318 gst-plugins-good: add PACKAGECONFIG for x11
* fixes following issues from test-dependencies report:
  gst-plugins-good/gst-plugins-good-ximagesrc/latest lost dependency on libxdamage

(From OE-Core rev: 8da4462b04bdce101efd989ed6b41d88d213baa0)

(From OE-Core rev: f4336262ca16621255591355a1f2156f098a50bd)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:
	meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.31.bb
2014-05-29 13:42:23 +01:00
Martin Jansa
9662a47204 gst-plugins-bad: add PACKAGECONFIG for schro, dc1394 and faac
* resolve following issues from test-dependencies issues:
  gst-plugins-bad/gst-plugins-bad-meta/latest lost dependency on
    gst-plugins-bad-dc1394 gst-plugins-bad-faac gst-plugins-bad-schro
  Found errors:
  gst-plugins-bad/gst-plugins-bad-dc1394/latest doesn't exist
  gst-plugins-bad/gst-plugins-bad-dc1394-dev/latest doesn't exist
  gst-plugins-bad/gst-plugins-bad-faac/latest doesn't exist
  gst-plugins-bad/gst-plugins-bad-faac-dev/latest doesn't exist
  gst-plugins-bad/gst-plugins-bad-schro/latest doesn't exist
  gst-plugins-bad/gst-plugins-bad-schro-dev/latest doesn't exist

(From OE-Core rev: 6e12dcd3a98417099f961eb9574d0d6f261afa42)

(From OE-Core rev: 38189ffa8851bc1c324189b10501a07b84809f61)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Martin Jansa
78366c7e2c gstreamer1.0-plugins-good: add libxfixes and libxdamange to x11 depends
* fixes following issue in test-dependencies report:
  gstreamer1.0-plugins-good/gstreamer1.0-plugins-good-ximagesrc/latest lost dependency on  libxdamage

(From OE-Core rev: 23521fccb122b64f3469d46176f73fe476b0dfc5)

(From OE-Core rev: c7b5001dfa178e1ad8042624cf8e0aaf79e9eb13)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Richard Purdie
287c3bec51 attr: Fix uclibc builds
attr needs libintl headers and libs. Add in the missing dependency and
ensure the linker flag gets passed in multilib builds by replacing the
PN == BPN check with a class-target override instead.

(From OE-Core rev: c19fb913006eb53025e5db1574d973c8d7ceec76)

(From OE-Core rev: 240d25d0fbcbedbdea82a7a103e672e2aad74ba8)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Richard Purdie
80f625a364 gcc: Handle uclibc linker relocation for multilib support
We need to handle the UCLIBC_* linker variables in the same way
as we do the GLIBC_* ones to allow uclibc multilib to work properly.

(From OE-Core rev: 025ec5958b7e1fd71caa0079ec3c573126b30886)

(From OE-Core rev: 6e437160ac3aa79d132e16430849e21a98fcafd1)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Saul Wold
978c6c00d6 openssh: add /var/log/lastlog to volatile list
The /var/log/messages reports /var/log/lastlog as missing, since openssh
needs this file, create it as a volatile.

[YOCTO #6172]

(From OE-Core rev: a29af8c20187a65fbdbbedd0b7158c07d3e713cf)

(From OE-Core rev: 219804c682344a934821c6b23bc9f7cf9cc94cd4)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Maxin B. John
090cb60d49 libxml2: fix CVE-2014-0191
It was discovered that libxml2, a library providing support to read,
modify and write XML files, incorrectly performs entity substituton in
the doctype prolog, even if the application using libxml2 disabled any
entity substitution. A remote attacker could provide a
specially-crafted XML file that, when processed, would lead to the
exhaustion of CPU and memory resources or file descriptors.

Reference: https://access.redhat.com/security/cve/CVE-2014-0191

(From OE-Core rev: 674bd59d5e357a4aba18c472ac21712a660a84af)

(From OE-Core rev: 51f674ab1f7dac049060c58f89e84c5d1275a87b)

Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Ricardo Ribalda Delgado
2784c08229 package_manager: Fix NoneType Object on do_populate_sdk
PACKAGE_EXCLUDE can be not defined or empty, leading to a build error.

File: '/var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/meta/lib/oe/package_manager.py', lineno: 1649, function: _create_configs
     1645:                    "Pin-Priority: %d\n\n" % (arch, priority))
     1646:
     1647:                priority += 5
     1648:
 *** 1649:            for pkg in self.d.getVar('PACKAGE_EXCLUDE', True).split():
     1650:                prefs_file.write(
     1651:                    "Package: %s\n"
     1652:                    "Pin: release *\n"
     1653:                    "Pin-Priority: -1\n\n" % pkg)
Exception: AttributeError: 'NoneType' object has no attribute 'split'

ERROR: Function failed: do_populate_sdk
ERROR: Logfile of failure stored in: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/bobcat_64-poky-linux/meta-toolchain/1.0-r7/temp/log.do_populate_sdk.21363
NOTE: recipe meta-toolchain-1.0-r7: task do_populate_sdk: Failed
(From OE-Core rev: 26314886c3712f980ccc589b014a8f1802193b56)

(From OE-Core rev: f1f97c61281158432a98279a2f7b4931173f406e)

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Ricardo Ribalda Delgado
b1ab59a8d0 package_manager: Fix Argument list too long
Function buildhistory_list_installed_image fails with error "Argument
list too long". This patch uses a temporal file to pass the package list
to opkg-query-helper.py

File: '/var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/meta/lib/oe/package_manager.py', lineno: 421, function: list
     0417:            try:
     0418:                output = subprocess.check_output("echo -e '%s' | %s" %
     0419:                                                 (output, opkg_query_cmd),
     0420:                                                 stderr=subprocess.STDOUT,
 *** 0421:                                                 shell=True)
     0422:            except subprocess.CalledProcessError as e:
     0423:                bb.fatal("Cannot compute packages dependencies. Command '%s' "
     0424:                         "returned %d:\n%s" % (e.cmd, e.returncode, e.output))
     0425:
Exception: OSError: [Errno 7] Argument list too long

ERROR: Function failed: buildhistory_list_installed_image
ERROR: Logfile of failure stored in: /var/lib/jenkins/jobs/qt5022-cesium/workspace/build/tmp/work/qt5022-poky-linux/qimage-dev/1.0-r0/temp/log.do_rootfs.16747
NOTE: recipe qimage-dev-1.0-r0: task do_rootfs: Failed
ERROR: Task 7 (/var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/../qtec/meta-qt5022/recipes-core/images/qimage-dev.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4999 tasks of which 30 didn't need to be rerun and 1 failed.
NOTE: Writing buildhistory
Auto packing the repository for optimum performance.

Summary: 1 task failed:
  /var/lib/jenkins/jobs/qt5022-cesium/workspace/repo/yocto/../qtec/meta-qt5022/recipes-core/images/qimage-dev.bb, do_rootfs
Summary: There were 74 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

(From OE-Core rev: 36cba6e00d76462e4ae314dd2af0b47472835538)

(From OE-Core rev: 9e984913318ea8c7199300ed2336902aaf2cd8a5)

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Richard Purdie
3141bc16a5 uclibc: Set MULTILIB_DIR based on baselib
baselib contains the current "lib" value so pass this into
uclibc's configration to allow multilib builds to work correctly.

(From OE-Core rev: 665b03b338d8d710250bd92d6b9a227255f808f8)

(From OE-Core rev: b2fb0f9584f9655321c007f0340e510477176681)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Richard Purdie
b057375f77 libiconv: Fix B != S with uclibc builds
Without this, uclibc builds fail with libtool version mismatches. The issue
is that we need to remove the files in ${S}, not ${B} which is now
the default after the B != S change.

(From OE-Core rev: 054151c77dae51e2826eeac9b9ae2de3a08f0bb6)

(From OE-Core rev: cb11b05beb2821d34c4ef9da32d5900b544d2135)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:22 +01:00
Chen Qi
4f0c5e5b32 mmc-utils: fix compilation failure for mips64 target.
This patch fixes mmc-utils compilation failure for qemumips64.
Remove the 'include <asm-generic/int-ll64.h>' line from mmc.h,
because this file is automatically included if _MIPS_SZLONG
is not 64, otherwise, <asm-generic/int-l64.h> is included.

Expicitly including <asm-generic/int-ll64.h> will cause the
compilation failure for mips64 target.

[YOCTO #6267]

(From OE-Core rev: 5477cc86015be24cc5b232ac1f8c67cd8b65a740)

(From OE-Core rev: 4512882dd819b76901a7ad39c130d85a8d7dd848)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Tim Orling
9fb409bcc5 perl: fix missing Module::Metadata
Module::Build depends on Module::Metadata (since perl 5.13.9).
Module::Metainfo is only a wrapper for Module::Metadata.

See discussion in http://patches.openembedded.org/patch/66233/

(From OE-Core rev: 3babe5704fbda62920ec17a910d0f3fe9f468229)

(From OE-Core rev: 963be07f2be3962375d4049f5cd84b90d07c054e)

Signed-off-by: Tim Orling <TicoTimo@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Maxin B. John
3d95a1cce5 openssl: fix CVE-2014-0198
A null pointer dereference bug was discovered in do_ssl3_write().
An attacker could possibly use this to cause OpenSSL to crash, resulting
in a denial of service.

https://access.redhat.com/security/cve/CVE-2014-0198

(From OE-Core rev: 580033721abbbb4302bc803ebc70c90e331e4587)

(From OE-Core rev: c3f6cea0b8f1de1e2042087c26ebe42ff909c1ed)

Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Tyler Hall
361ddb10de python3: Revert python-config to distutils.sysconfig
The newer sysconfig module shares some code with distutils.sysconfig,
but the same modifications as in

12-distutils-prefix-is-inside-staging-area.patch

makes distutils.sysconfig affect the native runtime as well as cross
building.  Use the old, patched implementation which returns paths in
the staging directory and for the target, as appropriate.

This change reverts this upstream patch
http://hg.python.org/cpython/diff/712970b019f7/Misc/python-config.in

(From OE-Core rev: 7b2ffd68ae8235dcc3ddff9cbe8525e61f3b3d28)

(From OE-Core rev: de5797b27a358954eb15318d0d77ad1981981861)

Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Tyler Hall
133472e7aa python3: Substitute correct python version in shebang
If python2 and python3 are both available, scripts that are subject to
this substitution can possibly run with the wrong python version.
python3-config is one such script.

(From OE-Core rev: 23849347d0fe60a01578efdd6c6e23ebb444dcd6)

(From OE-Core rev: ae49adc13db10cb39eeb9377eb4c60a4db436e00)

Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Radek Dostal
e4b9dabfbb distutils.bbclass: only modify *.py file if it contains path to be removed
Currently sed command touches every single *.py file. This modifies the
timestamp of the file. All *.pyo files will be recompiled during the first
boot, because timestamp will not match. This should be only necessary if
sed command changes the file.

(From OE-Core rev: 2d01c5a4989dcf03a202c27730a2a8f334e0c37a)

(From OE-Core rev: 0903469ffd41c8e6a5ed8ba09817c004a16a477e)

Signed-off-by: Radek Dostal <radek.dostal@streamunlimited.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Martin Jansa
45dbb4a080 qt4: Explicitly disable sqlite2
* notice that this disables only sqlite2 (sqlite dependency),
  sqlite (sqlite3 dependency) stays enabled

* fixes these errors detected by test-dependencies.sh:
  qt4-embedded/qt4-embedded-plugin-sqldriver-sqlite2/latest doesn't exist
  qt4-embedded/qt4-embedded-plugin-sqldriver-sqlite2-dbg/latest doesn't exist
  qt4-x11-free/qt4-plugin-sqldriver-sqlite2/latest doesn't exist
  qt4-x11-free/qt4-plugin-sqldriver-sqlite2-dbg/latest doesn't exist

(From OE-Core rev: 279c221d9dfce43254ed1f03cf84ea454cc7b485)

(From OE-Core rev: 33890920730802c29deda1506018cb837a16d6e5)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Ming Liu
517c2cc88d ldconfig-native: also default to lib32 and lib64 directories
make ldconfig default to /lib+/usr/lib, /lib32+/usr/lib32 and
/lib64+/usr/lib64 on bi-ABI architectures.

(From OE-Core rev: c90bb98d4ac14562ef4882691daed3aaa9d08504)

(From OE-Core rev: 44202d78102fa58ba99040a79d5a61c44033f57d)

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Joel Fernandes
a1958d47c6 serial-getty service: Add xterm as default TERM
In poky with systemd enabled, vt102 is selected for getty
causing user to experience a very crappy terminal. Default
TERM to xterm.

Reviewed-by: Jonathan Liu <net147@gmail.com>
(From OE-Core rev: 473ff65c2f69de4ece3204fadfae7c5cb992149a)

(From OE-Core rev: 3d7191d5e8d7edbfa3c0b0833811957629d99102)

Signed-off-by: Joel Fernandes <joelf@ti.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:21 +01:00
Valentin Popa
6547137fa3 wpa-supplicant: add libgcrypt as a dependencie
gnutls doesn't depend on libgcrypt anymore but
wpa-supplicant does. So add it as a dependencie.

(From OE-Core rev: b5e0e0589dba0e3eb6fa070594c904fec6e6c3a8)

(From OE-Core rev: ddcc8445247618b980bc82acd3bfa73fe3336d39)

Signed-off-by: Valentin Popa <valentin.popa@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Koen Kooi
651f3dc078 xinput-calibrator: fix XDG launch
In the move from meta-oe to OE-core XDG based launched was dropped
without noting it in the commit message, so fix that regression.

Gnome-session will now launch the calibrator again.

(From OE-Core rev: 64e0c8a7585a36964988f2f00ac89eda514d5f7b)

(From OE-Core rev: 956b39c3d01141402af7d98a2c60097b2db0030f)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Koen Kooi
8333887235 xdg-utils: reinstall xdg-terminal
It's being used by e.g. gnome-session when Terminal=true is set in
.desktop files, like xinput-calibrator does.

(From OE-Core rev: 9a821d80b732a52574ac5c20b323966811828852)

(From OE-Core rev: 896be25e1480bbfd815e2cd58a50729413663397)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Khem Raj
33a8687635 procps: Do not detect 32/64 bit compiler options
It gets its wrong in detecting 64bit options
and OE we already pass the right options as compiler
defaults

(From OE-Core rev: ec3add1752a410fada04b4788c142b91ef63ffa3)

(From OE-Core rev: 32b826720626ec2d426ff7dbfe5607bc0dbd8082)

(From OE-Core rev: fc1839d8a54a97b695396b507b53949b7a7dee74)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Tudor Florea
7fee883b8b curl: Backport a fix for a build issue
mkhelp: generate code for --disable-manual as well

This allows configure --disable-manual to run and build without having
to regenerate the src/tool_hugehelp.c file which otherwise is necessary
since we ship tarballs with that file present.

(From OE-Core rev: 544a96255203a6779d1f0022d003c6680f330511)

(From OE-Core rev: 4176809145037aed3d009c3ab96ef9ace519ca46)

Signed-off-by: Tudor Florea <tudor.florea@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Drew Moseley
e6ea60b131 systemd: Check for HAVE_POSIX_FALLOCATE
The check for the config variable is using the wrong define
resulting in the #else always being used.

(From OE-Core rev: 7e498c4c17e2c1b6928d4c1fd127977bb588991f)

(From OE-Core rev: 3d48c3e5a91d38242be1aa4ad5ed2a50cc4f3b9d)

Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:20 +01:00
Irina Patru
342eff6b38 distrodata.bbclass: Fix checkpkg functionality
Currently it wasn't working because *COMMAND variables were removed
from fetcher.
Now checkpkg sets the command internally and sends it as a parameter
to _runwget() function from wget fetch.

(From OE-Core rev: b9a51fc1901c378375cca041da27ddbd450c0412)

(From OE-Core rev: 724656a399745fc1e3d270f4af5a85336cd062e7)

Signed-off-by: Irina Patru <irina.patru@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Jacob Kroon
8e5103a026 sstate-cache-management: Minor cleanup of help text
(From OE-Core rev: a039ef9d116f0bab0bbb6d25867666b10057f2ad)

(From OE-Core rev: 2f22c098c3ada8c0952c7711f7a7f5b6421e6aea)

(From OE-Core rev: dee8a612ef7cc5f789a46fc550448deb1b369c8a)

Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Richard Purdie
52fa8b8582 initscripts: Fix PR reversal
(From OE-Core rev: 343f1c49ed223cd188287d4815f9dd956376c94d)

(From OE-Core rev: a31baa540f93f808fbb3cd7f311ac0607f47141f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Ming Liu
7892063223 kernel: don't populate source symbolic link
/usr/src/kernel/source deployed by kernel-dev package is symbolically
linking to a build-time kernel source folder, which make no sense when
cross-compiling.

Fixed by not populating it at install stage.

(From OE-Core rev: edb85a9589be54a1e9c980aa669a380222a76cf4)

(From OE-Core rev: 4d04d4e6063b1a9dcd8f929e8abfa403ce87eef1)

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Chen Qi
5f4a75f904 bind: add support for read-only rootfs
This patch adds support for read-only rootfs to the bind service.
Basically it just bind mounts several directories so that the bind
service could start correctly without reporting any error.

(From OE-Core rev: 99cc96eaee28bfde89096689b1296d28937ead88)

(From OE-Core rev: 5e62ed2e5684e4791199604d75e6ab3caae5875a)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Mike Crowe
b4e7ebe227 native.bbclass: Override TARGET_ flags too
TARGET_LDFLAGS is currently defined in bitbake.conf to contain
${TARGET_LINK_HASH_STYLE} which differs between MIPS and other
targets. Since TARGET_LDFLAGS is an exported variable it affects the hash
of every shell task even if it is not used.

We don't want native recipe tasks to have different hashes purely because
they happen to have been built in order to satisfy dependencies for
different MACHINEs since this causes lots of churn in the native sysroot
when switching between MACHINEs.

Making native.bbclass override TARGET_LDFLAGS to use BUILD_LDFLAGS ensures
consistent hashes and is a sensible thing to be doing anyway.

Although they don't appear to have the same detrimental affect on task
hashes TARGET_CPPFLAGS, TARGET_CFLAGS and TARGET_CXXFLAGS should be
overridden too.

(From OE-Core rev: 05a70ac30b37cab0952f1b9df501993a9dec70da)

(From OE-Core rev: ac14407182fe1dec2e53179177344833d20eb2db)

Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Saul Wold
9ac13c344b report-error: Add posting in the public note
(From OE-Core rev: c2eb5cd1aa4632f7ee8c261414e599dcb6f40a8b)

(From OE-Core rev: cfb4539b932e9f6c686206840e0cd60d0af86adb)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Martin Jansa
9b6c56a07d gsettings-desktop-schemas: add missing dependency on intltool-native
* do_configure fails with:
  | NOTE: Executing intltoolize --copy --force --automake
  | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gsettings-desktop-schemas/3.10.1-r1/temp/run.do_configure.1111: 180:
  /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gsettings-desktop-schemas/3.10.1-r1/temp/run.do_configure.1111:
   intltoolize: not found
  | WARNING: exit code 127 from a shell command.
  | ERROR: Function failed: do_configure (log file is located at
  /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/gsettings-desktop-schemas/3.10.1-r1/temp/log.do_configure.1111)
  NOTE: recipe gsettings-desktop-schemas-3.10.1-r1: task do_configure:

* introduced in:
  commit 1138976f7bdcd24ef57451a2c2ceffa43666610f
  Author: Alexandru Palalau <alexandrux.palalau@linux.intel.com>
  Date:   Tue Mar 11 13:27:46 2014 +0000

    gsettings-desktop-schemas: removed unneeded class inheritance

(From OE-Core rev: 4a159a086db42467c310b1fa80fee13c53168729)

(From OE-Core rev: 7966f087d05dab9b64daaa8b7564f2c9e86d0ab9)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Jacob Kroon
02faddb5ca console-tools: Remove floating runtime dependency on flex
The 'loadkeys' program defines its own yywrap()/yylex() functions,
there is no need to link with flex shared library.

(From OE-Core rev: 69a7c9345360b61eda79f818775656fc1aa9932c)

(From OE-Core rev: 44173771cdfb9015c0f6be28e9e025e65230b4ad)

Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Adrian Calianu
77439dafd0 oprofileui-server_git: add avahi-daemon to RDEPENDS list
oprofileui-server recipe depends on avahi recipe. But avahi recipe
generates more packages and one of those packages(avahi-daemon) which
oprofileui-server expected to be available is not found into image.
A runtime dependency of oprofileui-server on avahi-daemon is required.

Upstream-Status: Pending

(From OE-Core rev: 1163b6e619102bea08c429e49a4792abfa234c1c)

(From OE-Core rev: fb418d0848ae1772f68fc72d97222ae8f2cd192d)

Signed-off-by: Adrian Calianu <adrian.calianu@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:19 +01:00
Joe Slater
5709daae36 pixbufcache: add error exit in pixbufcache_sstate_postinst
In order to attempt recovery of a failed populate_sysroot_setscene,
we need to explicitly error exit an SSTATEPOSTINSTFUNC.  So, we test
the return value of gdk-pixbuf-query-loaders.

(From OE-Core rev: 17bdb2538e6b723e11afb1079c71363603dba63d)

(From OE-Core rev: 90492efeacc7645592bbd5c4518f519f732e5f95)

Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Philip Tricca
f0a153a7f6 grub-efi: Use a variable to specify built-in grub modules.
The previous behavior defines a static set of modules that are built
into the grub efi executable. This works fine for a limited set of boot
environments namely the standard linux/initrd. This patch conditionally
 assigns the same modules to a variable. This allows other meta layers
to add additional modules or completely override the defaults. The use
case driving this patch is the use of multiboot2 and related modules.

(From OE-Core rev: 597f8e0040ba3135220000b23767858c64b5c9b8)

(From OE-Core rev: 63ce29a48b608f34dd378285a54c24ee83a3a1c7)

Signed-off-by: Philip Tricca <flihp@twobit.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Matthieu Crapet
f2103de785 openssh-sshd: host contamination fix
If you do a readelf -x .rodata /path/.../to/openssh/6.5p1-r0/packages-split/openssh-sshd/usr/sbin/sshd

You'll see two references to OE's sysroots/${BUILD_SYS} login and passwd binaries.
First one can be overridden with LOGIN_PROGRAM environment variable (see configure.ac),
second needs a cached variable definition.

(From OE-Core rev: 2127c80d0cc2a3a4d676bd3c0890454a175fba8e)

(From OE-Core rev: 8f5a97d6ed8b4e2f85a834b641f19ad843522aa1)

Signed-off-by: Matthieu Crapet <Matthieu.Crapet@ingenico.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Koen Kooi
ec984f1697 grub git: workaround debugedit problems
Debugedit errors out on bare metal binaries. The first version of this patch limited it to 64 bit targets, but the problem now shows up on 32 bit targets (minnowboard) as well.

(From OE-Core rev: f95c7611007ddda3fe36db90168c7d5de096f9cd)

(From OE-Core rev: 98491d69c573bc113995075331cabef7f9d1a675)

Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Andreas Müller
619c449b68 make menuconfig work for recent xfce environment
xfce terminal was renamed 'Terminal' -> 'xfce4-teminal' mainline end of 2012,
so the distros supporting 'Terminal' will dissapear. The distros not
mentionied in  __init__ do (e.g fedora 19 - tested) fail - or will fail
sooner or later.

(From OE-Core rev: d07f3812ec371da6f18fa1dd920cdde470bd89ad)

(From OE-Core rev: 9f29399dcb9eea02efbda14cc3d5bcf2e91323f6)

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Bruce Ashfield
8bd20eb128 linux-yocto/3.14: aufs, edgerouter config and -rt
Updating the 3.14 SRCREVs to import the following changes:

  - enable AUFS: a missing Kbuild patch was preventing aufs from compiling
  - edgerouter: remove RTC configuration options
  - preempt-rt recipe. The patch for 3.14 is availble, so we populate the recipe.

(From OE-Core rev: 8e38a24a9d9cd44733a25d3de307907a788d643d)

(From OE-Core rev: 6d2dcba210ac60ec709eb6956c34474a021ab425)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Andreas Oberritter
2645411074 recipe_sanity.bbclass: avoid error when running 'bitbake -e'
Running 'bitbake -e' without further arguments causes a stack trace on stderr:

| ERROR: Command execution failed: Traceback (most recent call last):
|   File "[...]/bitbake/lib/bb/command.py", line 99, in runAsyncCommand
|     commandmethod(self.cmds_async, self, options)
|   File "[...]/bitbake/lib/bb/command.py", line 405, in showEnvironment
|     command.cooker.showEnvironment(bfile)
|   File "[...]/bitbake/lib/bb/cooker.py", line 453, in showEnvironment
|     logger.plain("\npython %s () {\n%s}\n", e, data.getVar(e, envdata, 1))
|   File "[...]/bitbake/lib/bb/data.py", line 89, in getVar
|     return d.getVar(var, exp)
|   File "[...]/bitbake/lib/bb/data_smart.py", line 522, in getVar
|     return self.getVarFlag(var, "_content", expand, noweakdefault)
|   File "[...]/bitbake/lib/bb/data_smart.py", line 612, in getVarFlag
|     value = self.expand(value, cachename)
|   File "[...]/bitbake/lib/bb/data_smart.py", line 350, in expand
|     return self.expandWithRefs(s, varname).value
|   File "[...]/bitbake/lib/bb/data_smart.py", line 340, in expandWithRefs
|     raise ExpansionError(varname, s, exc)
| ExpansionError: Failure expanding variable can_delete_FILESPATH, expression was def can_delete_FILESPATH(cfgdata, d):
|     expected = cfgdata.get("FILESPATH")
|     #expected = "${@':'.join([os.path.normpath(os.path.join(fp, p, o)) for fp in d.getVar('FILESPATHBASE', True).split(':') for p in d.getVar('FILESPATHPKG', True).split(':') for o in (d.getVar('OVERRIDES', True) + ':').split(':') if os.path.exists(os.path.join(fp, p, o))])}:${FILESDIR}"
|     expectedpaths = d.expand(expected)
|     unexpanded = d.getVar("FILESPATH", 0)
|     filespath = d.getVar("FILESPATH", True).split(":")
|     filespath = [os.path.normpath(f) for f in filespath if os.path.exists(f)]
|     for fp in filespath:
|         if not fp in expectedpaths:
|             # __note("Path %s in FILESPATH not in the expected paths %s" %
|             # (fp, expectedpaths), d)
|             return False
|     return expected != unexpanded
|  which triggered exception AttributeError: 'NoneType' object has no attribute 'split'

Removing the commented second line in can_delete_FILESPATH() hides the error.

(From OE-Core rev: a84c36e0e5e8332ddc5a6c34e1f598d5cb87cee2)

(From OE-Core rev: ef5892a2cd8eb85ba8de47a970122a8a6d5724ad)

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Stefan Stanacar
d8b564530e scripts/send-error-report: simple hack to use proxy from the enviroment
People behind a proxy couldn't send an error report to an upstream server,
this should fix the issue if they use a proxy that doesn't require authentication,
or one that uses basic http authentication and it's correctly exported in the enviroment.

(From OE-Core rev: a8511ee80246b4e2caa353b87f4b586f1539e6d4)

(From OE-Core rev: 3550355391a8920911e0dc68f01690afff7003b2)

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Martin Jansa
af91e98e32 icecc: don't create unnecessary 'ice' dirs in sysroots when disabled
* parsing ICE_PATH="${@icc_path(bb, d)}" causes "ice" directories
  to be created in every sysroot, that could be a bit confusing for
  people who inherit icecc.bbclass, but disabled it
* shorten ICECC_VERSION="${@icc_version(bb, d)}" path a bit
  by returning sooner when disabled
* remove ICECC_PATH and ICECC_ENV_EXEC from signatures, we assume that
  using icecc doesn't influence the output, so it shouldn't matter when
  user supplies own version of icecc or env script
* always compare ICECC_DISABLED with "1", boolean typed_value isn't used
  because documentation already mentions using empty value to keep icecc
  enabled and that's not valid boolean value when oe.data.typed_value is
  used:
  ERROR: ICECC_DISABLED: Invalid boolean value ''

(From OE-Core rev: c3e8bfe30685e2357a6eb3ba8f4a014c7dc9f58e)

(From OE-Core rev: 41aeb447de70b5fb3e1d0ef4aa90376ad5caef4c)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Andreas Müller
46c39b60c5 shadow: fix building systemd with useradd-staticids.bbclass enabled
| groupadd: 'systemd-journal-gateway' is not a valid group name

Without useradd-staticids enabled, group 'systemd-journal-gateway' is created
by useradd and that seems not to care for GROUP_NAME_MAX_LENGTH which has 16 by
default.

(From OE-Core rev: 33c7892326de296cc6d143577be5b395ac887d91)

(From OE-Core rev: 103a270d2c094c810faf3bbafb2a429ee08e22f7)

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:18 +01:00
Khem Raj
9153d11e6c libav: Add libsdl to DEPENDS only when x11 is enabled
When we have opengl in distro features but not x11 and try to
build libav then it calls out to build libsdl which inturn has depependency on libglu
and libglu fails to build

ld: error: cannot find -lGL
| collect2: error: ld returned 1 exit status
| make: *** [libGLU.la] Error 1
| ERROR: oe_runmake failed

since libglu wants glx enabled in mesa and glx in mesa is (righly) enabled only when x11
is in distro features.

This breaks the dependency chain leading to this problem

(From OE-Core rev: fe9fe5ca5039743fc80d14f0518b95929c458b1a)

(From OE-Core rev: 740deb02b653d1c5174be99c3093dac5af73f6ff)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:17 +01:00
Martin Jansa
de20bf01e4 libnotify: add dbus-glib dependency
* | No package 'dbus-glib-1' found
  | configure:11865: error: Package requirements (gtk+-2.0 >= 2.18, glib-2.0 >= 2.6,
    dbus-1 >= 0.76, dbus-glib-1 >= 0.76 gmodule-2.0) were not met:

* introduced in:
  commit 5c1eeb5d16566521e45947b07fdcd9f552fec45b
  Author: Alexandru Palalau <alexandrux.palalau@intel.com>
  Date:   Thu Feb 27 12:05:41 2014 +0200

      libnotify: don't use gnome.bbclass

  because gnome.bbclass was adding gconf->dbus-glib dependency

* it was also causing other recipes to fail when they were depending
  on libnotify which has dbus-glib in pkg-config and dbus-glib was
  missing, e.g. firefox:
  | checking for libnotify >= 0.4... Package dbus-glib-1 was not found
  in the pkg-config search path. Perhaps you should add the directory
  containing `dbus-glib-1.pc' to the PKG_CONFIG_PATH environment
  variable Package 'dbus-glib-1', required by 'libnotify', not found
  | configure: error: Library requirements (libnotify >= 0.4) not met;
  consider adjusting the PKG_CONFIG_PATH environment variable if your
  libraries are in a nonstandard prefix so pkg-config can find them.

(From OE-Core rev: abb2571a6352fc33a8b78ab0886d443894cda3b6)

(From OE-Core rev: 63281707f0360e97e43d08f022e8aa2c1df131fa)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:17 +01:00
Hongxu Jia
56aaa6450b apr: remove the use of ${SHELL} to avoid bash/dash confliction
While multible hosts sharing a common sstate cache, the fist host using
bash as default shell and build apr, the second host using dash as
default shell and build apr-util, there was a failure in apr-util:
...
| /bin/sh: 0: Can't open i586-poky-linux-libtool
| make[1]: *** [dbm/apr_dbm_gdbm.lo] Error 127
| make[1]: *** Waiting for unfinished jobs....
| make[1]: Leaving directory
`tmp/work/i586-poky-linux/apr-util/1.5.2-r0/apr-util-1.5.2'
...

The quick way to reproduce the defect in Ubuntu 1204:
1. Create a new build
2. sudo dpkg-reconfigure dash <set bash as /bin/sh>
3. bitbake apr
4. sudo dpkg-reconfigure dash <set dash as /bin/sh>
5. bitbake apr-util

Remove the use of $(SHELL) in the apr could avoid this issue.

(From OE-Core rev: 53af71200b6f6d117e1e7dc2e7a7d21c6faab8f9)

(From OE-Core rev: f33a9060ef10322ac1c0e8e5ca05678ce93860f1)

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:42:17 +01:00
Volker Vogelhuber
5ca9285434 bitbake: fetch2/hg: Fix missing proto param for hg checkout with user and pw
A fix for the former patch when checking out a repository with
username and password using HG

(Bitbake rev: 6e7f7cdc0d533911046741817be1cfffde23f125)

Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Richard Purdie
7631f6bbfc bitbake: data_smart: Fix an unusual variable reference bug
If you try:

Y = ""
Y_remove = "X"

in OE-Core, bitbake will crash with a KeyError during expansion. The reason
is that no expansion of the empty value is attempted but removal from is it
and hence no varparse data is present for it in the expand_cache.

If the value is empty, there is nothing to remove so the best fix is simply
not to check for None but check it has any value.

Also add a test for this error so it doesn't get reintroduced.

(Bitbake rev: af3ce0fc0280e6642fa35de400f75fdbabf329b1)

(Bitbake rev: 2d3478c97b7c7a2f5b12a8be302d8ea5ba4e1277)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Richard Purdie
08e2f06d36 bitbake: fetch2/perforce: Ensure command has a default
Ensure there is default command available if FETCHCMD_p4 isn't set.

Also clean up the getVar references whilst here.

(Bitbake rev: d150226d11d5f041f78c8c3ce4abc5465dbc81d8)

(Bitbake rev: d865692e8b76a1da80c80788946978f150f2c34b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Volker Vogelhuber
424643f463 bitbake: fix cloning of mercurial repository with username and password specified in url
(Bitbake rev: 9a328262e047562a6edf7b2ec7b8a1949e287cbe)

(Bitbake rev: 410372783b22cf3ff2d8bbd80a5c3f4a1694e9a4)

Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Nick Lewis
84396ed610 bitbake: Fix refetch of local files when they are read only
(Bitbake rev: 42b7be1a6c5ff559f4a213eed04b370ca955460d)

(Bitbake rev: ad2f373fa29fcaf03934d96f7d69440254a259f0)

Signed-off-by: Nick Lewis <nick.lewis@usa.g4s.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Volker Vogelhuber
b28a902253 bitbake: HG Fetch with username and password in url
Following up a previous patch for mercurial fetcher, I just fixed a
problem when calling update on a repository with subrepositories enabled.

Attached a patch that fixes this problem

>From caae519a2bd64bf7c729bb26aff344827def47fb Mon Sep 17 00:00:00 2001
From: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Date: Tue, 29 Apr 2014 15:29:47 +0200
Subject: [PATCH] bitbake: bitbake: - fixed authentication issues in case of using sub
 repositories

(Bitbake rev: dfa041c940caad12da50126a559afc8de089eeda)

(Bitbake rev: 8b9e8a19dbee56f1012966b77d7f7bd595af55ff)

Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Jacob Kroon
b94ebc582f bitbake: bitbake-diffsigs: Fix runtime error when no arguments are given
If bitbake-diffsigs is run without arguments it will error:

    Traceback (most recent call last):
      File "./bin/bitbake-diffsigs", line 121, in <module>
        if output:
    NameError: name 'output' is not defined

Fix this by moving the check for output into the inner else-clause.

(Bitbake rev: 7d3545a66863ad7183a7650b2af57eee091c45ae)

(Bitbake rev: 8df9bf87fc67633c2be0ac21eec24a356b3d63ba)

Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:24 +01:00
Richard Purdie
07600df4cb bitbake: runqueue: Fix task weighting algorithm
When looking at a list of tasks, do_patch and do_unpack were being
given equal priority when one clearly depends on another. The
reason for this was the default task weights of 0 being to tasks.
This is therefore changed to 1 to allow correct weighting of dependencies
which means the scheduler has better information available to it about
tasks.

Weight endpoints differently (10) for clearer debugging of priorities.

(Bitbake rev: 12dc1d17fac3e8ec420fcafb06186d32fd847d89)

(Bitbake rev: f19f3bf10af52b1610a35bfb47308ff48a5038b1)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:23 +01:00
Richard Purdie
00d8024741 bitbake: runqueue: Fix handling of zero priority task
The zero priority task should be run first but was being confused with
the None value the priority field defaulted to. Check for None
explicitly to avoid this error.

In the real world this doesn't change much but it confused the debug
output from the schedulers.

(Bitbake rev: 49c9d8c9400f74c804c2f36462639236e0841ff0)

(Bitbake rev: 5c3b0c139143ffd68033afa93421164f89703426)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29 13:18:23 +01:00
Richard Purdie
aa39d9a2df lib/oe/sdk: Ensure target directory exists before creating the link
(From OE-Core rev: 03a11d3cecc977b23bdf7b8510bf80dbe408b135)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-22 16:31:48 +01:00
Scott Rifenbark
98ad3cb2c0 mega-manual.sed: changed 1.6 to 1.6.1 for support of that release.
(From yocto-docs rev: 97a821bd39447a9cd569f8d3f569f68d803d0f3c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-12 20:31:58 +01:00
Scott Rifenbark
88b7b1a88a documentation: Updated Manual Revision Tables for 1.6.1 point release.
I put in the "Sometime in 2014" string for when this point
release would be available.

(From yocto-docs rev: 82d14a71db7e033e8cc58d2b4cc470792275be8f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-12 20:31:58 +01:00
Scott Rifenbark
ec1f93c50c poky.ent: Updated variables to support a 1.6.1 release.
(From yocto-docs rev: 34b80491296535421ab3c9dad2fb6bc9d30ec32c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-12 20:31:57 +01:00
Scott Rifenbark
6157ab451b dev-manual: Added "Properly Versioning Pre-Release Recipes" section.
Fixes [YOCTO #6243]

This section addresses situations when working with recipe
file names of recipes that have not been released (e.g.
recipe-name_1.0.3.rc1).  When the recipe is released the system
has difficulty recognizing the new recipe name as a later version.
So the work-around is to use PV to set the recipe version in
the recipe.  The section describes this.

(From yocto-docs rev: a98754620e0285d28f20fd507a68496e8a4364dc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-12 20:31:57 +01:00
Scott Rifenbark
5306aaab07 ref-manual: Added new section to the 1.6 migration section plus some 1.5 edits.
Added a new section on "Matching Branch Requirement for Git Fetching"
into the BitBake section.  Plus, made some minor corrections to
some of the 1.5 sections.

(From yocto-docs rev: 326a8009ca0bef0a4686510bb521010d8f58ac81)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-23 21:11:03 +01:00
Richard Purdie
31ab5dafa8 build-appliance-image: Update to head revision
(From OE-Core rev: 82bd5fc58229df73d7aca93f41b13392f9fdc3dc)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-22 22:53:45 +01:00
Beth Flanagan
84d524c938 distro_alias.inc: update/sort alias information.
Added new package data and resorted per
http://article.gmane.org/gmane.linux.embedded.poky/9253

Removed -native packages as distrodata handles them in OVERRIDES.

However, meta packages and grub-efi are special and needs some
handling within distrodata. I have a patch for this but for the
release I'm leaving them within distro-alias.

(From meta-yocto rev: 6b1685c90b4def4a4b4ca862b7e915a953782b6e)

Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-22 22:51:42 +01:00
Scott Rifenbark
7bbc4b8a77 ref-manual: Pulled the item for forked packages out.
Fixes [YOCTO #4958]

I pulled the change I put in to warn users about forked packages
based on further review from Paul Eggleton.  This pretty much
means the bug is back to square one.

(From yocto-docs rev: fec630e4d1c464865d85e824ec684ef3cee55b42)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-22 16:16:05 +01:00
Scott Rifenbark
33dfe60c35 bitbake: bitbake-user-manual-hello.xml: Edits to the "Hello World" Appendix.
Fixes [YOCTO #1973]

These are review changes applied from Paul Eggleton.

(Bitbake rev: fe083b674b20b254877a6d8249b11c9a7373866e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:15 +01:00
Scott Rifenbark
78217d37d2 bitbake: bitbake-user-manual-hello.xml: First draft of "Hello World" appendix
Fixes [YOCTO #1973]

Added the complete "Hello World" appendix first draft beyond
what Bill Traynor had supplied.

(Bitbake rev: 3a618a0c8efd04d24a3569c32431ac2732fb4876)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:15 +01:00
Scott Rifenbark
69d4c63428 bitbake: bitbake-user-manual-hello.xml: Edits to environment for hello world.
Some general edits to the sections that get you set up to run
the "Hello World" example.

(Bitbake rev: dc3ef99ddbbdd1ab0d1675b350a25ca970286248)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:15 +01:00
Scott Rifenbark
1eb75407ae bitbake: bitbake-user-manual-metadata.xml: Added section on pathname syntax
Added a brief subsection to the "Basic Syntax" section that
describes the issue using the tilde character (~) when providing
a pathname as part of a statement.  BitBake does not expand
this character like the shell does.  We recommend to not use
it in pathnames.

(Bitbake rev: a98ee7b67127a18bb8a81b1e7840c386134812c6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
2c79d57ded bitbake: bitbake-user-manual-ref-variables.xml: Edits to the BBPATH variable.
I took the stuff about running bitbake outside the build
directory and removed the note syntax.

(Bitbake rev: 0fa37e4ba864620972854e8405ed68bb8e8b1560)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
de87ba4b37 bitbake: bitbake-user-manual-ref-variables.xml: Fixed BBPATH example
The example used in the note in the BBPATH variable description
had incorrect syntax.  Spaces existed in the BBPATH = statement.
I have removed them.

(Bitbake rev: 67f5f536b022293ad3f5c5f176e33b7896bde89f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
14a666b094 bitbake: user-manual-hello.xml: General edits
I worked through the chapter and made some minor edits based
on my user experience.  Part of what I did was to update
the console output for the examples.

(Bitbake rev: 1b5b714d72676adad0469d7c0713e87e3b10e5e6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
84bcf66436 bitbake: bitbake-user-manual-hello.xml: Fixed two broken links.
(Bitbake rev: 5e9b8a1434eeab6b9750491242552240f836d90c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
cba4a8b80d bitbake: bitbake-user-manual-metadata.xml: New section on anonymous Python functions
Per Paul Eggleton's suggestion, I added a new section on
anonymous Python functions into the "Functions" section.
I also updated the intro text to account for the added
type of functions.

(Bitbake rev: ea0c6d0a47b4b8e399554fbf719e563cc63e2775)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Scott Rifenbark
c23e7052fb bitbake: bitbake-user-manual-metadata.xml: Edits to flexible inheritance section.
Fixes [YOCTO #5472]

Applied review edits from Paul Eggleton to this section.
Minor edits and some re-writing.

(Bitbake rev: 91c4913c0ecdf4e61817687095d0ca4086dfee8a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:05:14 +01:00
Richard Purdie
7253253972 bitbake: doc: Rename user-manual -> bitbake-user-manual
This manual gets combined with other manuals and in that context, it helps
a lot if its seen as the Bitbake User Manual. Renames are a pain but
this is worthwhile so that other docs can correctly be combined with this
one. This also clarifies things like google search results which is helpful.

(Bitbake rev: 452a62ae0c2793e281d6769fd3e45500a74898d6)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 23:04:51 +01:00
Scott Rifenbark
cddb415f72 ref-manual: Added package change info to the migration section.
The package architecture for armv7a packages with the thumb optimization
enabled will now get a "t2" suffix as it should; this was not the case in the
1.5 release. Architecture names will change within package feeds as a result.

(From yocto-docs rev: 1ce59f6911dd67835266aa3b0e29f404a487fd6e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 22:47:23 +01:00
Scott Rifenbark
6aed9f819d dev-manual: Fixed some "systemd" capitalization issues.
I was using this term inconsistently.  I have cleaned it up so
that no initial capital is used.

(From yocto-docs rev: 7dea2c5ef067d81b8350cd54ba4082c35d7077b1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 22:47:23 +01:00
Scott Rifenbark
30ac79c16d ref-manual: Updated the list of supported distributions.
I get this list from meta-yocto/conf/distro/poky.conf.

(From yocto-docs rev: 796d4eced50d14203f1a791ff557a4016f4dd031)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 22:47:23 +01:00
Scott Rifenbark
3f00873a8a documentation: Updated all the manual revision history tables.
Set the release date to April 2014.

(From yocto-docs rev: 2592bc968edeea941a92e6bdd321dd872745b78c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-21 22:47:23 +01:00
Scott Rifenbark
4f6fb8c362 dev-manual: Updates to "Performing Automated Runtime Testing"
Fixes [YOCTO #5554]

I worked with Stefan here to update the section on running tests.
We are good now with it all.

(From yocto-docs rev: 806a89f1ddd3efc39d15d3f7e1a01e8fd69af7c1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:46 +01:00
Scott Rifenbark
a3dcfa6a6a dev-manual: Changed GummiBootTarget to GummibootTarget.
(From yocto-docs rev: 0d870778d87dcbb38d1ce577f38b84c8fca0e464)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:46 +01:00
Scott Rifenbark
e0999660a8 ref-manual: Added review comments to core-image-testmaster image.
(From yocto-docs rev: 064a49648b2333dede612642a9a6621470b603ed)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:46 +01:00
Scott Rifenbark
897b87195c dev-manual: Edits to "Using the Error Reporting Tool"
Created some sub-section structure to better organize this
section.

(From yocto-docs rev: 61b15f579c4c21378277051bb5905baa4e9741b5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
1dfcb8968c ref-manual: Added core-image-testmaster to the list of images.
Fixes [YOCTO #5614]

(From yocto-docs rev: 5df086664b858423d6e7054b451942feb73047e9)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
3f7bfb38a2 dev-manual: Edits to "Using the Error Reporting Tool"
Added Information about setting up your own server.  Paul
Eggleton provided the information.

(From yocto-docs rev: 655bba9b91283dac502658dd72d866a7af4eacce)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
5b09536d38 ref-manual: Fixed typo
(From yocto-docs rev: 28577b94d14be63df7ac00a89b774992055c94fe)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
21cd3d6212 ref-manual: Re-ordered the insane.bbclass tests list.
I ordered these 39 tests by alphebetical ordering.

(From yocto-docs rev: 3a7ef1c149ee1f8f0ac4709e906f5c84ed7ab642)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
4dc19ba0a9 ref-manual: Added symlink-to-sysroot insane.bbclass tests.
(From yocto-docs rev: 6152a64ffaab638cffc952be70707d5e9aedbf88)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
bbaf0c65f1 dev-manual: Fixed typo for AUTOREV.
(From yocto-docs rev: a1fd83f0aeaab95693335150f330bbc7c5af18f8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Scott Rifenbark
0cb01121eb dev-manual, ref-manual: Removed VIRTUAL-RUNTIME note from most places.
Fixes [YOCTO #5159]

Edits to fix the occurrences of VIRTUAL-RUNTIME_initscripts = "".
I removed it from all places in the manuals except under
"Selecting an Initialization Manager".  Note that it still
needed removed from "Using Systemd for the Main Image and
Using SysVinit for the Rescue Image".

Also, in the "Using Systemd Exclusively" section I made some
edits as suggested by Paul Eggleton's review.

(From yocto-docs rev: 28b2e3eba3acff17f165899a7f4a65c98263e201)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 16:24:45 +01:00
Stefan Stanacar
f9c2b9083e scripts/send-error-report: use a real server as the default
Now that there is a public instance [1] of the error report web interface [2],
we should set it as the default.

[1] http://errors.yoctoproject.org/
[2] http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/

(From OE-Core rev: 346c3cbd7987044279267ec9c987887099cafe48)

Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 11:04:44 +01:00
Alexandru DAMIAN
3c8da7d5bc toaster.bbclass: do not fail on non-existent files
Toaster may look up inexistent file paths in the build history
for packages that have been referenced but not built.

This triggers a failure, and this patch recovers by deleting
the reference to the non-built packages.

[YOCTO #6063]

(From OE-Core rev: 5413e56205a9f48d8c3e419d8da468c60f5aa348)

Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 11:04:44 +01:00
Denys Dmytriyenko
3e49cee7e8 u-boot: fix beaglebone boot issue with large kernel images
Fix beaglebone boot issue with large kernel images overwriting Device Tree.
See very detailed comments inside the patch.

The original patch is being reviewed upstream and is targeting mainline U-boot
version 2014.07. This is the adaptation of the patch for 2013.07 version we use

(From OE-Core rev: c18b8fb9a625b5fb760c3ba53708155d3294ac6c)

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-19 11:04:44 +01:00
Scott Rifenbark
0ba2239abb poky.ent: Changed the YOCTO_DOCS_BB_URL location.
We changed the folder name of the BitBake User Manual from
"user-manual" to "bitbake-user-manual".  This means the
URL for the variable used in poky-ent for the manual needed
to be updated.

(From yocto-docs rev: 16a616b4a6f8237c8ba220e74f38235ca78c10ac)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-13 12:04:17 +01:00
Scott Rifenbark
87a71c5017 dev-manual: typo fixed.
(From yocto-docs rev: 1bae90e7eb4d53cb0899b2a7b701d525587863d4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-13 12:04:17 +01:00
Scott Rifenbark
761c6172f6 ref-manual, dev-manual: Edits to running tests on hardware
Fixes [YOCTO #5554]

Applied edits to the section in the dev-manual on running tests
on hardware.

Edited the TEST_TARGET and TEST_IMAGE variables.

(From yocto-docs rev: a26ba11c739aabab4009a944d9b622e2814c7fca)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-13 12:04:17 +01:00
Scott Rifenbark
b958f2e6dc ref-manual: Edits to DISK_SIGNATURE variable.
Fixes [YOCTO 5766]

I removed the note about the "live" IMAGE_TYPES.  Turns out I
was wrong on this information.  It does not create a "directdisk"
image.  That is accomplished through a .bbclass.

(From yocto-docs rev: a3b762be9933178e9cecdac3fa9e110c031a64d0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:33 +01:00
Scott Rifenbark
4123b4e575 ref-manual: Added warning about forking packages when upgrading YP
Fixes [YOCTO #4958]

Added a bullet item to the packages section in the migration chapter
for upgrading to YP v1.6.  Item notes the issue and warns the
user to beware.

(From yocto-docs rev: f66ca39a65c2529ebc552d3a816e6565dae183f7)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:33 +01:00
Scott Rifenbark
9301072deb ref-manual: Updated the DISK_SIGNATURE description.
Fixes [YOCTO #6125]

Did some re-writing based on Jonathin Liu's feedback.

(From yocto-docs rev: bee4a584bcb1e70e9848324781c32d1d9e3d1fc2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:33 +01:00
Scott Rifenbark
6d3e061287 ref-manual: Removed note limiting tests to QEMU.
Fixes [YOCTO #5554]

Removed the note limiting this to QEMU tests.

(From yocto-docs rev: c91d058514832aacfb74fd4480e0a2dba95b4921)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:33 +01:00
Scott Rifenbark
3ff180c173 ref-manual: Edits to the module_autoload and module_conf variables.
Minor re-wording edits as suggested by Paul Eggleton.

(From yocto-docs rev: 699eec0b691a19b4ae2f05c7774f559898e952da)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:33 +01:00
Scott Rifenbark
19b9fde3b2 ref-manual: Updates to deal with installing packages in initramfs
Fixes [YOCTO #4961]

Documented the user requirement to use PACKAGE_INSTALL to specify
packages for installation into an initramfs image.  Normally,
you use IMAGE_INSTALL.  To account for this user model, I updated
the PACKAGE_INSTALL and IMAGE_INSTALL variables.  I also added
a bit more information to the "Images" chapter item that
talks about the core-image-minimal-initramfs image.

(From yocto-docs rev: a1ad649cf310f281a7de584d5b9a1820ca99d4eb)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
bdc27cc405 ref-manual: Edits to module_autoload and module_conf variables.
Fixes [YOCTO #5888]

Applied some feedback to the variables based on Paul's comments.
Needed a caveat on how you can use these variables.

(From yocto-docs rev: ef8fac4b36089d3162ee16c93866a39bcd31701c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
7e30874db2 ref-manual: added module_autoload and module_conf variables.
Fixes [YOCTO #5888]

Two new variables added to the glossary.  These help with
specifying kernel modules that need to auto-load on boot and
with specifying module.d syntax in the modname.conf file.

(From yocto-docs rev: 1ac544c4f6129faafea10691b426cd510ff56a69)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
f9d0fd9bb1 bsp-guide: Updated the yocto-bsp example.
Ran the tool and provided the actual machine branch output
choices.

(From yocto-docs rev: 5b78e70079e2c621221187d4419de2a2427efbc1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
3353d6bcce bsp-guide: Updated the yocto-bsp example.
This example does not run as described.  It said that the
setup script was run and the user would be in the top-level
Source Directory (e.g. poky).  The script errors out unless
run from the poky/build directory.  So I took out the requirement
of being in the top directory.

(From yocto-docs rev: 800e4001319cde3e665c0271fd5a19646fb2bd7a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
904c35e049 ref-manual: Updated KBRANCH to fix a reference to the linux kernel.
(From yocto-docs rev: 59aab89f2c1ff5e0ab43fe9ba25f929500b94d5f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
9ff3a1de42 ref-manual: Updated KBRANCH variable description.
I replaced the v3.4 version example with the v3.10 version.
It is more up-to-date.

(From yocto-docs rev: 2e7f5d4fbe24a8248686c9ca7cf870204966beec)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
9ab4d1f5e6 bsp-guide: Updates to "Linux Kernel Configuration" section.
This section was using an out-dated version of the
linux-yocto_3.10.bbappend file.  The new version accounts for
both emgd and non-emgd configurations.  I had to insert the new
listing and update some supporting text describing it.

(From yocto-docs rev: 97329a154e3dee44cb393d4a289fdcbb9f8adf07)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
a0f9efe7d6 bsp-guide: Updated the "Hardware Configuration Options" section.
The "require" statements changed from four to three.

(From yocto-docs rev: 36f4fe004e69cb7715d41787d4c22b39371f63b6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Scott Rifenbark
a6193f3822 bsp-guide: Updated the "Example Filesystem Layout" section.
The recipes-kernel structure had changed for the Crown Bay
BSP.

(From yocto-docs rev: 14ecfc7e676901a6d422f49b0170f27f6b46837f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:32 +01:00
Dennis Meier
f0cbff052e ref-manual: Extended the D variable description.
Applied this patch from Dennis and then removed some whitespace,
used the 5-space indentation convention for the literal, formatted
the task name and did some other minor fixes.

(From yocto-docs rev: 477a9ecb2f91681ee401478189a424793381bfcb)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Dennis Meier
1929766ed5 Extended description of the ${D} variable to better explain its purpose.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
bd1e9a6a3a dev-manual: Grammar fix to the Toaster section.
(From yocto-docs rev: 36e7ec1a7e01e9f57d670527f6889ea1aa3099cf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
409d3cb7a2 dev-manual: Applied Toaster section review edits.
(From yocto-docs rev: 362ac25d3fc98268d49f71aae9d477a2a2256c8a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
49efe23169 ref-manual: Added TEST_EXPORT_DIR to glossary.
Fixes [YOCTO #5554]

New variable description.

(From yocto-docs rev: 9c245950faba53abc79f01d174e0f88e87d85430)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
46c0518279 ref-manual: Added TEST_EXPORT_ONLY to glossary.
Fixes [YOCTO #5554]

New variable description.

(From yocto-docs rev: 6be2edb9ff994c7e952c6b1c9fca7357549afd90)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
40396bee2b ref-manual: Added TEST_LOG_DIR to glossary.
Fixes [YOCTO #5554]

New variable description.

(From yocto-docs rev: f6ae7dc4fd29af0befd35ba15390eeec8d905487)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
cdbe3b5cee ref-manual: Added TEST_SERVER_IP to the variable glossary.
Fixes [YOCTO #5554]

New variable description.

(From yocto-docs rev: e12134c93661a827787ec878a94d3d2c8a280f83)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
aba074edbf ref-manual: Added TEST_TARGET_IP to the variable glossary.
Fixes [YOCTO #5554]

New variable description.

(From yocto-docs rev: 8c673542769a1a1aaef58100be15fc735a19adbe)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
f11e51056d ref-manual: Added TEST_TARGET variable description.
Fixes [YOCTO #5554]

New description.

(From yocto-docs rev: b81e056f8ef1a7ba0868857be71d46250382ffa3)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:31 +01:00
Scott Rifenbark
9a178b6016 dev-manual: Added new "Exporting Tests" section.
Fixes [YOCTO #5554]

New section added on exporting tests.

(From yocto-docs rev: b4a818e769acca5559a8e174414c4e214379e292)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
d8ee1658de dev-manual: Added new "Hardware" section for running tests.
Fixes [YOCTO #5554]

This is the section that describes how to enable tests for
actual hardware.

(From yocto-docs rev: fd33b19e7fa32797ab2abd2b506b0d63209fbfc6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
b5c29e15f4 dev-manual: Moved list of qemu-specific run information
Fixes [YOCTO #5554]

The list of items that described what happens when you run
tests is really specific to qemu.  Consequently, it is better
located in the section describing how to enable and get
set up for those tests.

(From yocto-docs rev: 1f0606f1c5c03c873a295819adcfb6fb51c196bd)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
21da2dbb78 dev-manual: Updates to the "target" class attribute
Fixes [YOCTO #5554]

In the "Class Attributes" section I updated several items.

(From yocto-docs rev: 8f97671319c4751885e5ec89423a061dd45c6684)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
520b36fe41 dev-manual: Updated the "Class Methods" section.
Fixes [YOCTO #5554]

Removed the final bulleted item.  Changed the wording on the
first to account for the manifest file.

(From yocto-docs rev: 50e7557032a0dbf4bc2144e9d4f9a4e1a1726d6d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
82733c9f71 dev-manual: Removed note about rm_work
Fixes [YOCTO #5554]

Removed the (second) note  about rm_work builds, that bug
was fixed. (#5072)

(From yocto-docs rev: f1223a67caae17db1abfd6b7465bfc71d295ab7f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
32857c5596 ref-manual: Added DISK_SIGNATURE variable description to glossary.
Fixes [YOCTO #6125]

(From yocto-docs rev: 5ee5433cc7799a240dd18aa20ce44b3ae978b592)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Scott Rifenbark
1d6146e0b1 yocto-project-qs: Substituting Beaglebone for Beagleboard.
Fixes [YOCTO #2444]

I swapped out the hardware names for the example in the
"Super User" section.  Beagleboard is no longer shipped with the
YP.  It has been replaced by Beaglebone.

(From yocto-docs rev: b71ecd4f24dd4c1804c9e8c26aedacbdfaa694a3)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-11 18:15:30 +01:00
Richard Purdie
a095826126 build-appliance-image: Set branch to daisy for release
(From OE-Core rev: dca1b4f073fff740364f066f6a68bb3c8697b7a6)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-10 20:25:40 +01:00
Richard Purdie
fd435cbfc5 build-appliance-image: Update to head revision
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-10 18:04:41 +01:00
Richard Purdie
6ca67b3288 poky: Branch for 1.6 daisy release
(From meta-yocto rev: 9e8ff9d7f0e80cf91983256e98cbb1f49213e61c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-10 18:03:00 +01:00
7933 changed files with 629225 additions and 515025 deletions

21
.gitignore vendored
View File

@@ -1,34 +1,23 @@
*.pyc
*.pyo
/*.patch
/.repo/
/build*/
build*/
pyshtables.py
pstage/
scripts/oe-git-proxy-socks
sources/
meta-*/
buildtools/
!meta-skeleton
!meta-selftest
!meta-hob
hob-image-*.bb
*.swp
*.orig
*.rej
*~
!meta-poky
!meta-yocto
!meta-yocto-bsp
!meta-yocto-imported
/documentation/*/eclipse/
/documentation/*/*.html
/documentation/*/*.pdf
/documentation/*/*.tgz
/bitbake/doc/bitbake-user-manual/bitbake-user-manual.html
/bitbake/doc/bitbake-user-manual/bitbake-user-manual.pdf
/bitbake/doc/bitbake-user-manual/bitbake-user-manual.tgz
documentation/user-manual/user-manual.html
documentation/user-manual/user-manual.pdf
documentation/user-manual/user-manual.tgz
pull-*/
bitbake/lib/toaster/contrib/tts/backlog.txt
bitbake/lib/toaster/contrib/tts/log/*
bitbake/lib/toaster/contrib/tts/.cache/*
bitbake/lib/bb/tests/runqueue-tests/bitbake-cookerdaemon.log

View File

@@ -1,2 +1,2 @@
# Template settings
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}

24
LICENSE
View File

@@ -1,20 +1,14 @@
Different components of OpenEmbedded are under different licenses (a mix
of MIT and GPLv2). See LICENSE.GPL-2.0-only and LICENSE.MIT for further
details of the individual licenses.
of MIT and GPLv2). Please see:
meta/COPYING.GPLv2 (GPLv2)
meta/COPYING.MIT (MIT)
meta-selftest/COPYING.MIT (MIT)
meta-skeleton/COPYING.MIT (MIT)
All metadata is MIT licensed unless otherwise stated. Source code
included in tree for individual recipes (e.g. patches) are under
the LICENSE stated in the associated recipe (.bb file) unless
otherwise stated.
included in tree for individual recipes is under the LICENSE stated in
the associated recipe (.bb file) unless otherwise stated.
License information for any other files is either explicitly stated
or defaults to GPL version 2 only.
Individual files contain the following style tags instead of the full license
text to identify their license:
SPDX-License-Identifier: GPL-2.0-only
SPDX-License-Identifier: MIT
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/
or defaults to GPL version 2.

View File

@@ -1,288 +0,0 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Note:
Individual files contain the following tag instead of the full license text.
SPDX-License-Identifier: GPL-2.0-only
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/

View File

@@ -1,25 +0,0 @@
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Note:
Individual files contain the following tag instead of the full license text.
SPDX-License-Identifier: MIT
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/

View File

@@ -1,72 +0,0 @@
OpenEmbedded-Core and Yocto Project Maintainer Information
==========================================================
OpenEmbedded and Yocto Project work jointly together to maintain the metadata,
layers, tools and sub-projects that make up their ecosystems.
The projects operate through collaborative development. This currently takes
place on mailing lists for many components as the "pull request on github"
workflow works well for single or small numbers of maintainers but we have
a large number, all with different specialisms and benefit from the mailing
list review process. Changes therefore undergo peer review through mailing
lists in many cases.
This file aims to acknowledge people with specific skills/knowledge/interest
both to recognise their contributions but also empower them to help lead and
curate those components. Where we have people with specialist knowledge in
particular areas, during review patches/feedback from these people in these
areas would generally carry weight.
This file is maintained in OE-Core but may refer to components that are separate
to it if that makes sense in the context of maintainership. The README of specific
layers and components should ultimately be definitive about the patch process and
maintainership for the component.
Recipe Maintainers
------------------
See meta/conf/distro/include/maintainers.inc
Component/Subsystem Maintainers
-------------------------------
* Kernel (inc. linux-yocto, perf): Bruce Ashfield
* Reproducible Builds: Joshua Watt
* Toaster: David Reyna
* Hash-Equivalence: Joshua Watt
* Recipe upgrade infrastructure: Alex Kanavin
* Toolchain: Khem Raj
* ptest-runner: Aníbal Limón
* opkg: Alex Stewart
* devtool: Saul Wold
* eSDK: Saul Wold
* overlayfs: Vyacheslav Yurkov
Maintainers needed
------------------
* Pseudo
* Layer Index
* recipetool
* QA framework/automated testing
* error reporting system/web UI
* wic
* Patchwork
* Patchtest
* Prelink-cross
* Matchbox
* Sato
* Autobuilder
Layer Maintainers needed
------------------------
* meta-gplv2 (ideally new strategy but active maintainer welcome)
Shadow maintainers/development needed
--------------------------------------
* toaster
* bitbake

View File

@@ -1,5 +0,0 @@
Some project contributors who are sadly no longer with us:
Greg Gilbert (treke) - Ahead of his time with licensing
Thomas Wood (thos) - Creator of the original sato
Scott Rifenbark (scottrif) - Our long standing techwriter whose words live on

View File

@@ -1,35 +0,0 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line, and also
# from the environment for the first two.
SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
SOURCEDIR = .
BUILDDIR = _build
DESTDIR = final
ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
endif
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile.sphinx clean publish
publish: Makefile.sphinx html singlehtml
rm -rf $(BUILDDIR)/$(DESTDIR)/
mkdir -p $(BUILDDIR)/$(DESTDIR)/
cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
clean:
@rm -rf $(BUILDDIR)
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile.sphinx
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

49
README Normal file
View File

@@ -0,0 +1,49 @@
Poky
====
Poky is an integration of various components to form a complete prepackaged
build system and development environment. It features support for building
customised embedded device style images. There are reference demo images
featuring a X11/Matchbox/GTK themed UI called Sato. The system supports
cross-architecture application development using QEMU emulation and a
standalone toolchain and SDK with IDE integration.
Additional information on the specifics of hardware that Poky supports
is available in README.hardware. Further hardware support can easily be added
in the form of layers which extend the systems capabilities in a modular way.
As an integration layer Poky consists of several upstream projects such as
BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information
e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
The Yocto Project has extensive documentation about the system including a
reference manual which can be found at:
http://yoctoproject.org/documentation
OpenEmbedded-Core is a layer containing the core metadata for current versions
of OpenEmbedded. It is distro-less (can build a functional image with
DISTRO = "nodistro") and contains only emulated machine support.
For information about OpenEmbedded, see the OpenEmbedded website:
http://www.openembedded.org/
Where to Send Patches
=====================
As Poky is an integration repository, patches against the various components
should be sent to their respective upstreams.
bitbake:
bitbake-devel@lists.openembedded.org
meta-yocto:
poky@yoctoproject.org
Most everything else should be sent to the OpenEmbedded Core mailing list. If
in doubt, check the oe-core git repository for the content you intend to modify.
Before sending, be sure the patches apply cleanly to the current oe-core git
repository.
openembedded-core@lists.openembedded.org
Note: The scripts directory should be treated with extra care as it is a mix
of oe-core and poky-specific files.

View File

@@ -1,29 +0,0 @@
OpenEmbedded-Core
=================
OpenEmbedded-Core is a layer containing the core metadata for current versions
of OpenEmbedded. It is distro-less (can build a functional image with
DISTRO = "nodistro") and contains only emulated machine support.
For information about OpenEmbedded, see the OpenEmbedded website:
https://www.openembedded.org/
The Yocto Project has extensive documentation about OE including a reference manual
which can be found at:
https://docs.yoctoproject.org/
Contributing
------------
Please refer to
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
for guidelines on how to submit patches.
Mailing list:
https://lists.openembedded.org/g/openembedded-core
Source code:
https://git.openembedded.org/openembedded-core/

476
README.hardware Normal file
View File

@@ -0,0 +1,476 @@
Poky Hardware README
====================
This file gives details about using Poky with the reference machines
supported out of the box. A full list of supported reference target machines
can be found by looking in the following directories:
meta/conf/machine/
meta-yocto-bsp/conf/machine/
If you are in doubt about using Poky/OpenEmbedded with your hardware, consult
the documentation for your board/device.
Support for additional devices is normally added by creating BSP layers - for
more information please see the Yocto Board Support Package (BSP) Developer's
Guide - documentation source is in documentation/bspguide or download the PDF
from:
http://yoctoproject.org/documentation
Support for physical reference hardware has now been split out into a
meta-yocto-bsp layer which can be removed separately from other layers if not
needed.
QEMU Emulation Targets
======================
To simplify development, the build system supports building images to
work with the QEMU emulator in system emulation mode. Several architectures
are currently supported:
* ARM (qemuarm)
* x86 (qemux86)
* x86-64 (qemux86-64)
* PowerPC (qemuppc)
* MIPS (qemumips)
Use of the QEMU images is covered in the Yocto Project Reference Manual.
The appropriate MACHINE variable value corresponding to the target is given
in brackets.
Hardware Reference Boards
=========================
The following boards are supported by the meta-yocto-bsp layer:
* Texas Instruments Beaglebone (beaglebone)
* Freescale MPC8315E-RDB (mpc8315e-rdb)
For more information see the board's section below. The appropriate MACHINE
variable value corresponding to the board is given in brackets.
Consumer Devices
================
The following consumer devices are supported by the meta-yocto-bsp layer:
* Intel x86 based PCs and devices (genericx86)
* Ubiquiti Networks EdgeRouter Lite (edgerouter)
For more information see the device's section below. The appropriate MACHINE
variable value corresponding to the device is given in brackets.
Specific Hardware Documentation
===============================
Intel x86 based PCs and devices (genericx86)
==========================================
The genericx86 MACHINE is tested on the following platforms:
Intel Xeon/Core i-Series:
+ Intel Romley Server: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Canoe Pass CRB)
+ Intel Romley Server: Ivy Bridge Xeon processor, C600 PCH (Patsburg), (Intel SDP S2R3)
+ Intel Crystal Forest Server: Sandy Bridge Xeon processor, DH89xx PCH (Cave Creek), (Stargo CRB)
+ Intel Chief River Mobile: Ivy Bridge Mobile processor, QM77 PCH (Panther Point-M), (Emerald Lake II CRB, Sabino Canyon CRB)
+ Intel Huron River Mobile: Sandy Bridge processor, QM67 PCH (Cougar Point), (Emerald Lake CRB, EVOC EC7-1817LNAR board)
+ Intel Calpella Platform: Core i7 processor, QM57 PCH (Ibex Peak-M), (Red Fort CRB, Emerson MATXM CORE-411-B)
+ Intel Nehalem/Westmere-EP Server: Xeon 56xx/55xx processors, 5520 chipset, ICH10R IOH (82801), (Hanlan Creek CRB)
+ Intel Nehalem Workstation: Xeon 56xx/55xx processors, System SC5650SCWS (Greencity CRB)
+ Intel Picket Post Server: Xeon 56xx/55xx processors (Jasper Forest), 3420 chipset (Ibex Peak), (Osage CRB)
+ Intel Storage Platform: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Oak Creek Canyon CRB)
+ Intel Shark Bay Client Platform: Haswell processor, LynxPoint PCH, (Walnut Canyon CRB, Lava Canyon CRB, Basking Ridge CRB, Flathead Creek CRB)
+ Intel Shark Bay Ultrabook Platform: Haswell ULT processor, Lynx Point-LP PCH, (WhiteTip Mountain 1 CRB)
Intel Atom platforms:
+ Intel embedded Menlow: Intel Atom Z510/530 CPU, System Controller Hub US15W (Portwell NANO-8044)
+ Intel Luna Pier: Intel Atom N4xx/D5xx series CPU (aka: Pineview-D & -M), 82801HM I/O Hub (ICH8M), (Advantech AIMB-212, Moon Creek CRB)
+ Intel Queens Bay platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Emerson NITX-315, Crown Bay CRB, Minnow Board)
+ Intel Fish River Island platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Kontron KM2M806)
+ Intel Cedar Trail platform: Intel Atom N2000 & D2000 series CPU (aka: Cedarview), NM10 Express Chipset (Norco kit BIS-6630, Cedar Rock CRB)
and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE
type supports ethernet, wifi, sound, and Intel/vesa graphics by default in
addition to common PC input devices, busses, and so on. Note that it does not
included the binary-only graphic drivers used on some Atom platforms, for
accelerated graphics on these machines please refer to meta-intel.
Depending on the device, it can boot from a traditional hard-disk, a USB device,
or over the network. Writing generated images to physical media is
straightforward with a caveat for USB devices. The following examples assume the
target boot device is /dev/sdb, be sure to verify this and use the correct
device as the following commands are run as root and are not reversable.
USB Device:
1. Build a live image. This image type consists of a simple filesystem
without a partition table, which is suitable for USB keys, and with the
default setup for the genericx86 machine, this image type is built
automatically for any image you build. For example:
$ bitbake core-image-minimal
2. Use the "dd" utility to write the image to the raw block device. For
example:
# dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb
If the device fails to boot with "Boot error" displayed, or apparently
stops just after the SYSLINUX version banner, it is likely the BIOS cannot
understand the physical layout of the disk (or rather it expects a
particular layout and cannot handle anything else). There are two possible
solutions to this problem:
1. Change the BIOS USB Device setting to HDD mode. The label will vary by
device, but the idea is to force BIOS to read the Cylinder/Head/Sector
geometry from the device.
2. Without such an option, the BIOS generally boots the device in USB-ZIP
mode. To write an image to a USB device that will be bootable in
USB-ZIP mode, carry out the following actions:
a. Determine the geometry of your USB device using fdisk:
# fdisk /dev/sdb
Command (m for help): p
Disk /dev/sdb: 4011 MB, 4011491328 bytes
124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors
...
Command (m for help): q
b. Configure the USB device for USB-ZIP mode:
# mkdiskimage -4 /dev/sdb 1019 124 62
Where 1019, 124 and 62 are the cylinder, head and sectors/track counts
as reported by fdisk (substitute the values reported for your device).
When the operation has finished and the access LED (if any) on the
device stops flashing, remove and reinsert the device to allow the
kernel to detect the new partition layout.
c. Copy the contents of the image to the USB-ZIP mode device:
# mkdir /tmp/image
# mkdir /tmp/usbkey
# mount -o loop core-image-minimal-genericx86.hddimg /tmp/image
# mount /dev/sdb4 /tmp/usbkey
# cp -rf /tmp/image/* /tmp/usbkey
d. Install the syslinux boot loader:
# syslinux /dev/sdb4
e. Unmount everything:
# umount /tmp/image
# umount /tmp/usbkey
Install the boot device in the target board and configure the BIOS to boot
from it.
For more details on the USB-ZIP scenario, see the syslinux documentation:
http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob_plain;f=doc/usbkey.txt;hb=HEAD
Texas Instruments Beaglebone (beaglebone)
=========================================
The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D
accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster
CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is
tested on the following platforms:
o Beaglebone Black A6
o Beaglebone A6 (the original "White" model)
The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT
button when powering on will temporarily change the boot order. But for the sake
of simplicity, these instructions assume you have erased the eMMC on the Black,
so its boot behavior matches that of the White and boots off of SD card. To do
this, issue the following commands from the u-boot prompt:
# mmc dev 1
# mmc erase 0 512
To further tailor these instructions for your board, please refer to the
documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black
From a Linux system with access to the image files perform the following steps
as root, replacing mmcblk0* with the SD card device on your machine (such as sdc
if used via a usb card reader):
1. Partition and format an SD card:
# fdisk -lu /dev/mmcblk0
Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes
255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 63 144584 72261 c Win95 FAT32 (LBA)
/dev/mmcblk0p2 144585 465884 160650 83 Linux
# mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
# mke2fs -j -L "root" /dev/mmcblk0p2
The following assumes the SD card partitions 1 and 2 are mounted at
/media/boot and /media/root respectively. Removing the card and reinserting
it will do just that on most modern Linux desktop environments.
The files referenced below are made available after the build in
build/tmp/deploy/images.
2. Install the boot loaders
# cp MLO-beaglebone /media/boot/MLO
# cp u-boot-beaglebone.img /media/boot/u-boot.img
3. Install the root filesystem
# tar x -C /media/root -f core-image-$IMAGE_TYPE-beaglebone.tar.bz2
4. If using core-image-base or core-image-sato images, the SD card is ready
and rootfs already contains the kernel, modules and device tree (DTB)
files necessary to be booted with U-boot's default configuration, so
skip directly to step 8.
For core-image-minimal, proceed through next steps.
5. If using core-image-minimal rootfs, install the modules
# tar x -C /media/root -f modules-beaglebone.tgz
6. If using core-image-minimal rootfs, install the kernel uImage into /boot
directory of rootfs
# cp uImage-beaglebone.bin /media/root/boot/uImage
7. If using core-image-minimal rootfs, also install device tree (DTB) files
into /boot directory of rootfs
# cp uImage-am335x-bone.dtb /media/root/boot/am335x-bone.dtb
# cp uImage-am335x-boneblack.dtb /media/root/boot/am335x-boneblack.dtb
8. Unmount the SD partitions, insert the SD card into the Beaglebone, and
boot the Beaglebone
Freescale MPC8315E-RDB (mpc8315e-rdb)
=====================================
The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and
software development of network attached storage (NAS) and digital media server
applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which
includes a built-in security accelerator.
(Note: you may find it easier to order MPC8315E-RDBA; this appears to be the
same board in an enclosure with accessories. In any case it is fully
compatible with the instructions given here.)
Setup instructions
------------------
You will need the following:
* NFS root setup on your workstation
* TFTP server installed on your workstation
* Straight-thru 9-conductor serial cable (DB9, M/F) connected from your
PC to UART1
* Ethernet connected to the first ethernet port on the board
--- Preparation ---
Note: if you have altered your board's ethernet MAC address(es) from the
defaults, or you need to do so because you want multiple boards on the same
network, then you will need to change the values in the dts file (patch
linux/arch/powerpc/boot/dts/mpc8315erdb.dts within the kernel source). If
you have left them at the factory default then you shouldn't need to do
anything here.
--- Booting from NFS root ---
Load the kernel and dtb (device tree blob), and boot the system as follows:
1. Get the kernel (uImage-mpc8315e-rdb.bin) and dtb (uImage-mpc8315e-rdb.dtb)
files from the tmp/deploy directory, and make them available on your TFTP
server.
2. Connect the board's first serial port to your workstation and then start up
your favourite serial terminal so that you will be able to interact with
the serial console. If you don't have a favourite, picocom is suggested:
$ picocom /dev/ttyUSB0 -b 115200
3. Power up or reset the board and press a key on the terminal when prompted
to get to the U-Boot command line
4. Set up the environment in U-Boot:
=> setenv ipaddr <board ip>
=> setenv serverip <tftp server ip>
=> setenv bootargs root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:255.255.255.0:mpc8315e:eth0:off console=ttyS0,115200
5. Download the kernel and dtb, and boot:
=> tftp 1000000 uImage-mpc8315e-rdb.bin
=> tftp 2000000 uImage-mpc8315e-rdb.dtb
=> bootm 1000000 - 2000000
Ubiquiti Networks EdgeRouter Lite (edgerouter)
==============================================
The EdgeRouter Lite is part of the EdgeMax series. It is a MIPS64 router
(based on the Cavium Octeon processor) with 512MB of RAM, which uses an
internal USB pendrive for storage.
Setup instructions
------------------
You will need the following:
* NFS root setup on your workstation
* TFTP server installed on your workstation
* RJ45 -> serial ("rollover") cable connected from your PC to the CONSOLE
port on the board
* Ethernet connected to the first ethernet port on the board
--- Preparation ---
Build an image (e.g. core-image-minimal) using "edgerouter" as the MACHINE.
In the following instruction it is based on core-image-minimal. Another target
may be similiar with it.
--- Booting from NFS root ---
Load the kernel, and boot the system as follows:
1. Get the kernel (vmlinux) file from the tmp/deploy/images/edgerouter
directory, and make them available on your TFTP server.
2. Connect the board's first serial port to your workstation and then start up
your favourite serial terminal so that you will be able to interact with
the serial console. If you don't have a favourite, picocom is suggested:
$ picocom /dev/ttyS0 -b 115200
3. Power up or reset the board and press a key on the terminal when prompted
to get to the U-Boot command line
4. Set up the environment in U-Boot:
=> setenv ipaddr <board ip>
=> setenv serverip <tftp server ip>
5. Download the kernel and boot:
=> tftp tftp $loadaddr vmlinux
=> bootoctlinux $loadaddr coremask=0x3 root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:<netmask>:edgerouter:eth0:off mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)
--- Booting from USB root ---
To boot from the USB disk, you either need to remove it from the edgerouter
box and populate it from another computer, or use a previously booted NFS
image and populate from the edgerouter itself.
Type 1: Mounted USB disk
------------------------
To boot from the USB disk there are two available partitions on the factory
USB storage. The rest of this guide assumes that these partitions are left
intact. If you change the partition scheme, you must update your boot method
appropriately.
The standard partitions are:
- 1: vfat partition containing factory kernels
- 2: ext3 partition for the root filesystem.
You can place the kernel on either partition 1, or partition 2, but the roofs
must go on partition 2 (due to its size).
Note: If you place the kernel on the ext3 partition, you must re-create the
ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and
cannot read the partition otherwise.
Steps:
1. Remove the USB disk from the edgerouter and insert it into a computer
that has access to your build artifacts.
2. Copy the kernel image to the USB storage (assuming discovered as 'sdb' on
the development machine):
2a) if booting from vfat
# mount /dev/sdb1 /mnt
# cp tmp/deploy/images/edgerouter/vmlinux /mnt
# umount /mnt
2b) if booting from ext3
# mkfs.ext3 -I 128 /dev/sdb2
# mount /dev/sdb2 /mnt
# mkdir /mnt/boot
# cp tmp/deploy/images/edgerouter/vmlinux /mnt/boot
# umount /mnt
3. Extract the rootfs to the USB storage ext3 partition
# mount /dev/sdb2 /mnt
# tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /mnt
# umount /mnt
4. Reboot the board and press a key on the terminal when prompted to get to the U-Boot
command line:
5. Load the kernel and boot:
5a) vfat boot
=> fatload usb 0:1 $loadaddr vmlinux
5b) ext3 boot
=> ext2load usb 0:2 $loadaddr boot/vmlinux
=> bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)
Type 2: NFS
-----------
Note: If you place the kernel on the ext3 partition, you must re-create the
ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and
cannot read the partition otherwise.
These boot instructions assume that you have recreated the ext3 filesystem with
128 byte inodes, you have an updated uboot or you are running and image capable
of making the filesystem on the board itself.
1. Boot from NFS root
2. Mount the USB disk partition 2 and then extract the contents of
tmp/deploy/core-image-XXXX.tar.bz2 into it.
Before starting, copy core-image-minimal-xxx.tar.bz2 and vmlinux into
rootfs path on your workstation.
and then,
# mount /dev/sda2 /media/sda2
# tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /media/sda2
# cp vmlinux /media/sda2/boot/vmlinux
# umount /media/sda2
# reboot
3. Reboot the board and press a key on the terminal when prompted to get to the U-Boot
command line:
# reboot
4. Load the kernel and boot:
=> ext2load usb 0:2 $loadaddr boot/vmlinux
=> bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)

View File

@@ -1 +0,0 @@
meta-yocto-bsp/README.hardware.md

View File

@@ -1 +0,0 @@
README.poky.md

View File

@@ -1 +0,0 @@
meta-poky/README.poky.md

View File

@@ -1,15 +0,0 @@
QEMU Emulation Targets
======================
To simplify development, the build system supports building images to
work with the QEMU emulator in system emulation mode. Several architectures
are currently supported in 32 and 64 bit variants:
* ARM (qemuarm + qemuarm64)
* x86 (qemux86 + qemux86-64)
* PowerPC (qemuppc only)
* MIPS (qemumips + qemumips64)
Use of the QEMU images is covered in the Yocto Project Reference Manual.
The appropriate MACHINE variable value corresponding to the target is given
in brackets.

View File

@@ -1,2 +0,0 @@
*min.js binary
*min.css binary

339
bitbake/COPYING Normal file
View File

@@ -0,0 +1,339 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.

19
bitbake/HEADER Normal file
View File

@@ -0,0 +1,19 @@
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# <one line to give the program's name and a brief idea of what it does.>
# Copyright (C) <year> <name of author>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

View File

@@ -1,29 +1,10 @@
BitBake is licensed under the GNU General Public License version 2.0. See
LICENSE.GPL-2.0-only for further details.
Individual files contain the following style tags instead of the full license text:
SPDX-License-Identifier: GPL-2.0-only
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/
BitBake is licensed under the GNU General Public License version 2.0. See COPYING for further details.
The following external components are distributed with this software:
* The Toaster Simple UI application is based upon the Django project template, the files of which are covered by the BSD license and are copyright (c) Django Software
Foundation and individual contributors.
* Twitter Bootstrap (including Glyphicons), redistributed under the MIT license
* Twitter Bootstrap (including Glyphicons), redistributed under the Apache License 2.0.
* jQuery is redistributed under the MIT license.
* Twitter typeahead.js redistributed under the MIT license. Note that the JS source has one small modification, so the full unminified file is currently included to make it obvious where this is.
* jsrender is redistributed under the MIT license.
* QUnit is redistributed under the MIT license.
* Font Awesome fonts redistributed under the SIL Open Font License 1.1
* simplediff is distributed under the zlib license.

View File

@@ -1,288 +0,0 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Note:
Individual files contain the following tag instead of the full license text.
SPDX-License-Identifier: GPL-2.0-only
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/

View File

@@ -1,25 +0,0 @@
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Note:
Individual files contain the following tag instead of the full license text.
SPDX-License-Identifier: MIT
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/

View File

@@ -1,43 +0,0 @@
Bitbake
=======
BitBake is a generic task execution engine that allows shell and Python tasks to be run
efficiently and in parallel while working within complex inter-task dependency constraints.
One of BitBake's main users, OpenEmbedded, takes this core and builds embedded Linux software
stacks using a task-oriented approach.
For information about Bitbake, see the OpenEmbedded website:
https://www.openembedded.org/
Bitbake plain documentation can be found under the doc directory or its integrated
html version at the Yocto Project website:
https://docs.yoctoproject.org
Contributing
------------
Please refer to
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
for guidelines on how to submit patches, just note that the latter documentation is intended
for OpenEmbedded (and its core) not bitbake patches (bitbake-devel@lists.openembedded.org)
but in general main guidelines apply. Once the commit(s) have been created, the way to send
the patch is through git-send-email. For example, to send the last commit (HEAD) on current
branch, type:
git send-email -M -1 --to bitbake-devel@lists.openembedded.org
Mailing list:
https://lists.openembedded.org/g/bitbake-devel
Source code:
https://git.openembedded.org/bitbake/
Testing:
Bitbake has a testsuite located in lib/bb/tests/ whichs aim to try and prevent regressions.
You can run this with "bitbake-selftest". In particular the fetcher is well covered since
it has so many corner cases. The datastore has many tests too. Testing with the testsuite is
recommended before submitting patches, particularly to the fetcher and datastore. We also
appreciate new test cases and may require them for more obscure issues.

View File

@@ -1,4 +1,6 @@
#!/usr/bin/env python3
#!/usr/bin/env python
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# Copyright (C) 2003, 2004 Chris Larson
# Copyright (C) 2003, 2004 Phil Blundell
@@ -7,40 +9,354 @@
# Copyright (C) 2005 ROAD GmbH
# Copyright (C) 2006 Richard Purdie
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import os
import sys
import warnings
warnings.simplefilter("default")
import sys, logging
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)),
'lib'))
import optparse
import warnings
from traceback import format_exception
try:
import bb
except RuntimeError as exc:
sys.exit(str(exc))
from bb import event
import bb.msg
from bb import cooker
from bb import ui
from bb import server
from bb import cookerdata
from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
if sys.getfilesystemencoding() != "utf-8":
sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
__version__ = "1.22.0"
logger = logging.getLogger("BitBake")
__version__ = "1.52.0"
# Python multiprocessing requires /dev/shm
if not os.access('/dev/shm', os.W_OK | os.X_OK):
sys.exit("FATAL: /dev/shm does not exist or is not writable")
# Unbuffer stdout to avoid log truncation in the event
# of an unorderly exit as well as to provide timely
# updates to log files for use with tail
try:
if sys.stdout.name == '<stdout>':
sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
except:
pass
def get_ui(config):
if not config.ui:
# modify 'ui' attribute because it is also read by cooker
config.ui = os.environ.get('BITBAKE_UI', 'knotty')
interface = config.ui
try:
# Dynamically load the UI based on the ui name. Although we
# suggest a fixed set this allows you to have flexibility in which
# ones are available.
module = __import__("bb.ui", fromlist = [interface])
return getattr(module, interface)
except AttributeError:
sys.exit("FATAL: Invalid user interface '%s' specified.\n"
"Valid interfaces: depexp, goggle, ncurses, hob, knotty [default]." % interface)
# Display bitbake/OE warnings via the BitBake.Warnings logger, ignoring others"""
warnlog = logging.getLogger("BitBake.Warnings")
_warnings_showwarning = warnings.showwarning
def _showwarning(message, category, filename, lineno, file=None, line=None):
if file is not None:
if _warnings_showwarning is not None:
_warnings_showwarning(message, category, filename, lineno, file, line)
else:
s = warnings.formatwarning(message, category, filename, lineno)
warnlog.warn(s)
warnings.showwarning = _showwarning
warnings.filterwarnings("ignore")
warnings.filterwarnings("default", module="(<string>$|(oe|bb)\.)")
warnings.filterwarnings("ignore", category=PendingDeprecationWarning)
warnings.filterwarnings("ignore", category=ImportWarning)
warnings.filterwarnings("ignore", category=DeprecationWarning, module="<string>$")
warnings.filterwarnings("ignore", message="With-statements now directly support multiple context managers")
class BitBakeConfigParameters(cookerdata.ConfigParameters):
def parseCommandLine(self):
parser = optparse.OptionParser(
version = "BitBake Build Tool Core version %s, %%prog version %s" % (bb.__version__, __version__),
usage = """%prog [options] [recipename/target ...]
Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
will provide the layer, BBFILES and other configuration information.""")
parser.add_option("-b", "--buildfile", help = "Execute tasks from a specific .bb recipe directly. WARNING: Does not handle any dependencies from other recipes.",
action = "store", dest = "buildfile", default = None)
parser.add_option("-k", "--continue", help = "Continue as much as possible after an error. While the target that failed and anything depending on it cannot be built, as much as possible will be built before stopping.",
action = "store_false", dest = "abort", default = True)
parser.add_option("-a", "--tryaltconfigs", help = "Continue with builds by trying to use alternative providers where possible.",
action = "store_true", dest = "tryaltconfigs", default = False)
parser.add_option("-f", "--force", help = "Force the specified targets/task to run (invalidating any existing stamp file).",
action = "store_true", dest = "force", default = False)
parser.add_option("-c", "--cmd", help = "Specify the task to execute. The exact options available depend on the metadata. Some examples might be 'compile' or 'populate_sysroot' or 'listtasks' may give a list of the tasks available.",
action = "store", dest = "cmd")
parser.add_option("-C", "--clear-stamp", help = "Invalidate the stamp for the specified task such as 'compile' and then run the default task for the specified target(s).",
action = "store", dest = "invalidate_stamp")
parser.add_option("-r", "--read", help = "Read the specified file before bitbake.conf.",
action = "append", dest = "prefile", default = [])
parser.add_option("-R", "--postread", help = "Read the specified file after bitbake.conf.",
action = "append", dest = "postfile", default = [])
parser.add_option("-v", "--verbose", help = "Output more log message data to the terminal.",
action = "store_true", dest = "verbose", default = False)
parser.add_option("-D", "--debug", help = "Increase the debug level. You can specify this more than once.",
action = "count", dest="debug", default = 0)
parser.add_option("-n", "--dry-run", help = "Don't execute, just go through the motions.",
action = "store_true", dest = "dry_run", default = False)
parser.add_option("-S", "--dump-signatures", help = "Dump out the signature construction information, with no task execution. Parameters are passed to the signature handling code, use 'none' if no specific handler is required.",
action = "append", dest = "dump_signatures", default = [])
parser.add_option("-p", "--parse-only", help = "Quit after parsing the BB recipes.",
action = "store_true", dest = "parse_only", default = False)
parser.add_option("-s", "--show-versions", help = "Show current and preferred versions of all recipes.",
action = "store_true", dest = "show_versions", default = False)
parser.add_option("-e", "--environment", help = "Show the global or per-package environment complete with information about where variables were set/changed.",
action = "store_true", dest = "show_environment", default = False)
parser.add_option("-g", "--graphviz", help = "Save dependency tree information for the specified targets in the dot syntax.",
action = "store_true", dest = "dot_graph", default = False)
parser.add_option("-I", "--ignore-deps", help = """Assume these dependencies don't exist and are already provided (equivalent to ASSUME_PROVIDED). Useful to make dependency graphs more appealing""",
action = "append", dest = "extra_assume_provided", default = [])
parser.add_option("-l", "--log-domains", help = """Show debug logging for the specified logging domains""",
action = "append", dest = "debug_domains", default = [])
parser.add_option("-P", "--profile", help = "Profile the command and save reports.",
action = "store_true", dest = "profile", default = False)
parser.add_option("-u", "--ui", help = "The user interface to use (e.g. knotty, hob, depexp).",
action = "store", dest = "ui")
parser.add_option("-t", "--servertype", help = "Choose which server to use, process or xmlrpc.",
action = "store", dest = "servertype")
parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not.",
action = "store_true", dest = "revisions_changed", default = False)
parser.add_option("", "--server-only", help = "Run bitbake without a UI, only starting a server (cooker) process.",
action = "store_true", dest = "server_only", default = False)
parser.add_option("-B", "--bind", help = "The name/address for the bitbake server to bind to.",
action = "store", dest = "bind", default = False)
parser.add_option("", "--no-setscene", help = "Do not run any setscene tasks. sstate will be ignored and everything needed, built.",
action = "store_true", dest = "nosetscene", default = False)
parser.add_option("", "--remote-server", help = "Connect to the specified server.",
action = "store", dest = "remote_server", default = False)
parser.add_option("-m", "--kill-server", help = "Terminate the remote server.",
action = "store_true", dest = "kill_server", default = False)
parser.add_option("", "--observe-only", help = "Connect to a server as an observing-only client.",
action = "store_true", dest = "observe_only", default = False)
parser.add_option("", "--status-only", help = "Check the status of the remote bitbake server.",
action = "store_true", dest = "status_only", default = False)
options, targets = parser.parse_args(sys.argv)
# some environmental variables set also configuration options
if "BBSERVER" in os.environ:
options.servertype = "xmlrpc"
options.remote_server = os.environ["BBSERVER"]
return options, targets[1:]
def start_server(servermodule, configParams, configuration, features):
server = servermodule.BitBakeServer()
if configParams.bind:
(host, port) = configParams.bind.split(':')
server.initServer((host, int(port)))
configuration.interface = [ server.serverImpl.host, server.serverImpl.port ]
else:
server.initServer()
configuration.interface = []
try:
configuration.setServerRegIdleCallback(server.getServerIdleCB())
cooker = bb.cooker.BBCooker(configuration, features)
server.addcooker(cooker)
server.saveConnectionDetails()
except Exception as e:
exc_info = sys.exc_info()
while hasattr(server, "event_queue"):
try:
import queue
except ImportError:
import Queue as queue
try:
event = server.event_queue.get(block=False)
except (queue.Empty, IOError):
break
if isinstance(event, logging.LogRecord):
logger.handle(event)
raise exc_info[1], None, exc_info[2]
server.detach()
return server
def main():
configParams = BitBakeConfigParameters()
configuration = cookerdata.CookerConfiguration()
configuration.setConfigParameters(configParams)
ui_module = get_ui(configParams)
# Server type can be xmlrpc or process currently, if nothing is specified,
# the default server is process
if configParams.servertype:
server_type = configParams.servertype
else:
server_type = 'process'
try:
module = __import__("bb.server", fromlist = [server_type])
servermodule = getattr(module, server_type)
except AttributeError:
sys.exit("FATAL: Invalid server type '%s' specified.\n"
"Valid interfaces: xmlrpc, process [default]." % server_type)
if configParams.server_only:
if configParams.servertype != "xmlrpc":
sys.exit("FATAL: If '--server-only' is defined, we must set the servertype as 'xmlrpc'.\n")
if not configParams.bind:
sys.exit("FATAL: The '--server-only' option requires a name/address to bind to with the -B option.\n")
if configParams.remote_server:
sys.exit("FATAL: The '--server-only' option conflicts with %s.\n" %
("the BBSERVER environment variable" if "BBSERVER" in os.environ else "the '--remote-server' option" ))
if configParams.bind and configParams.servertype != "xmlrpc":
sys.exit("FATAL: If '-B' or '--bind' is defined, we must set the servertype as 'xmlrpc'.\n")
if configParams.remote_server and configParams.servertype != "xmlrpc":
sys.exit("FATAL: If '--remote-server' is defined, we must set the servertype as 'xmlrpc'.\n")
if configParams.observe_only and (not configParams.remote_server or configParams.bind):
sys.exit("FATAL: '--observe-only' can only be used by UI clients connecting to a server.\n")
if "BBDEBUG" in os.environ:
level = int(os.environ["BBDEBUG"])
if level > configuration.debug:
configuration.debug = level
bb.msg.init_msgconfig(configParams.verbose, configuration.debug,
configuration.debug_domains)
# Ensure logging messages get sent to the UI as events
handler = bb.event.LogHandler()
if not configParams.status_only:
# In status only mode there are no logs and no UI
logger.addHandler(handler)
# Clear away any spurious environment variables while we stoke up the cooker
cleanedvars = bb.utils.clean_environment()
featureset = []
if not configParams.server_only:
# Collect the feature set for the UI
featureset = getattr(ui_module, "featureSet", [])
if not configParams.remote_server:
# we start a server with a given configuration
server = start_server(servermodule, configParams, configuration, featureset)
bb.event.ui_queue = []
else:
# we start a stub server that is actually a XMLRPClient that connects to a real server
server = servermodule.BitBakeXMLRPCClient(configParams.observe_only)
server.saveConnectionDetails(configParams.remote_server)
server.saveConnectionConfigParams(configParams)
if not configParams.server_only:
if configParams.status_only:
try:
server_connection = server.establishConnection(featureset)
except:
sys.exit(1)
if not server_connection:
sys.exit(1)
server_connection.terminate()
sys.exit(0)
# Setup a connection to the server (cooker)
server_connection = server.establishConnection(featureset)
if not server_connection:
if configParams.kill_server:
bb.fatal("Server already killed")
configParams.bind = configParams.remote_server
start_server(servermodule, configParams, configuration, featureset)
bb.event.ui_queue = []
server_connection = server.establishConnection(featureset)
# Restore the environment in case the UI needs it
for k in cleanedvars:
os.environ[k] = cleanedvars[k]
logger.removeHandler(handler)
try:
return ui_module.main(server_connection.connection, server_connection.events, configParams)
finally:
bb.event.ui_queue = []
server_connection.terminate()
else:
print("server address: %s, server port: %s" % (server.serverImpl.host, server.serverImpl.port))
return 0
return 1
if __name__ == "__main__":
if __version__ != bb.__version__:
sys.exit("Bitbake core version and program version mismatch!")
try:
sys.exit(bitbake_main(BitBakeConfigParameters(sys.argv),
cookerdata.CookerConfiguration()))
except BBMainException as err:
sys.exit(err)
ret = main()
except bb.BBHandledException:
sys.exit(1)
ret = 1
except Exception:
ret = 1
import traceback
traceback.print_exc()
sys.exit(1)
sys.exit(ret)

View File

@@ -1,199 +1,122 @@
#!/usr/bin/env python3
#!/usr/bin/env python
# bitbake-diffsigs / bitbake-dumpsig
# BitBake task signature data dump and comparison utility
# bitbake-diffsigs
# BitBake task signature data comparison utility
#
# Copyright (C) 2012-2013, 2017 Intel Corporation
# Copyright (C) 2012-2013 Intel Corporation
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import os
import sys
import warnings
warnings.simplefilter("default")
import argparse
import fnmatch
import optparse
import logging
import pickle
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
import bb.tinfoil
import bb.siggen
import bb.msg
myname = os.path.basename(sys.argv[0])
logger = bb.msg.logger_create(myname)
def logger_create(name, output=sys.stderr):
logger = logging.getLogger(name)
console = logging.StreamHandler(output)
format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
if output.isatty():
format.enable_color()
console.setFormatter(format)
logger.addHandler(console)
logger.setLevel(logging.INFO)
return logger
is_dump = myname == 'bitbake-dumpsig'
logger = logger_create('bitbake-diffsigs')
def find_siginfo(tinfoil, pn, taskname, sigs=None):
result = None
tinfoil.set_event_mask(['bb.event.FindSigInfoResult',
'logging.LogRecord',
'bb.command.CommandCompleted',
'bb.command.CommandFailed'])
ret = tinfoil.run_command('findSigInfo', pn, taskname, sigs)
if ret:
while True:
event = tinfoil.wait_event(1)
if event:
if isinstance(event, bb.command.CommandCompleted):
break
elif isinstance(event, bb.command.CommandFailed):
logger.error(str(event))
sys.exit(2)
elif isinstance(event, bb.event.FindSigInfoResult):
result = event.result
elif isinstance(event, logging.LogRecord):
logger.handle(event)
else:
logger.error('No result returned from findSigInfo command')
sys.exit(2)
return result
def find_compare_task(bbhandler, pn, taskname):
""" Find the most recent signature files for the specified PN/task and compare them """
def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
""" Find the most recent signature files for the specified PN/task """
if not hasattr(bb.siggen, 'find_siginfo'):
logger.error('Metadata does not support finding signature data files')
sys.exit(1)
if not taskname.startswith('do_'):
taskname = 'do_%s' % taskname
if sig1 and sig2:
sigfiles = find_siginfo(bbhandler, pn, taskname, [sig1, sig2])
if len(sigfiles) == 0:
logger.error('No sigdata files found matching %s %s matching either %s or %s' % (pn, taskname, sig1, sig2))
sys.exit(1)
elif not sig1 in sigfiles:
logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig1))
sys.exit(1)
elif not sig2 in sigfiles:
logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig2))
sys.exit(1)
latestfiles = [sigfiles[sig1], sigfiles[sig2]]
filedates = bb.siggen.find_siginfo(pn, taskname, None, bbhandler.config_data)
latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-2:]
if not latestfiles:
logger.error('No sigdata files found matching %s %s' % (pn, taskname))
sys.exit(1)
elif len(latestfiles) < 2:
logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (pn, taskname))
sys.exit(1)
else:
filedates = find_siginfo(bbhandler, pn, taskname)
latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-2:]
if not latestfiles:
logger.error('No sigdata files found matching %s %s' % (pn, taskname))
sys.exit(1)
# Define recursion callback
def recursecb(key, hash1, hash2):
hashes = [hash1, hash2]
hashfiles = bb.siggen.find_siginfo(key, None, hashes, bbhandler.config_data)
return latestfiles
recout = []
if len(hashfiles) == 2:
out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb)
recout.extend(list(' ' + l for l in out2))
else:
recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
return recout
# Recurse into signature comparison
output = bb.siggen.compare_sigfiles(latestfiles[0], latestfiles[1], recursecb)
if output:
print '\n'.join(output)
sys.exit(0)
# Define recursion callback
def recursecb(key, hash1, hash2):
hashes = [hash1, hash2]
hashfiles = find_siginfo(tinfoil, key, None, hashes)
recout = []
if len(hashfiles) == 0:
recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
elif not hash1 in hashfiles:
recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash1))
elif not hash2 in hashfiles:
recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash2))
else:
out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb, color=color)
for change in out2:
for line in change.splitlines():
recout.append(' ' + line)
parser = optparse.OptionParser(
description = "Compares siginfo/sigdata files written out by BitBake",
usage = """
%prog -t recipename taskname
%prog sigdatafile1 sigdatafile2
%prog sigdatafile1""")
return recout
parser.add_option("-t", "--task",
help = "find the signature data files for last two runs of the specified task and compare them",
action="store", dest="taskargs", nargs=2, metavar='recipename taskname')
parser = argparse.ArgumentParser(
description=("Dumps" if is_dump else "Compares") + " siginfo/sigdata files written out by BitBake")
parser.add_argument('-D', '--debug',
help='Enable debug output',
action='store_true')
if is_dump:
parser.add_argument("-t", "--task",
help="find the signature data file for the last run of the specified task",
action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
parser.add_argument("sigdatafile1",
help="Signature file to dump. Not used when using -t/--task.",
action="store", nargs='?', metavar="sigdatafile")
else:
parser.add_argument('-c', '--color',
help='Colorize the output (where %(metavar)s is %(choices)s)',
choices=['auto', 'always', 'never'], default='auto', metavar='color')
parser.add_argument('-d', '--dump',
help='Dump the last signature data instead of comparing (equivalent to using bitbake-dumpsig)',
action='store_true')
parser.add_argument("-t", "--task",
help="find the signature data files for the last two runs of the specified task and compare them",
action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
parser.add_argument("-s", "--signature",
help="With -t/--task, specify the signatures to look for instead of taking the last two",
action="store", dest="sigargs", nargs=2, metavar=('fromsig', 'tosig'))
parser.add_argument("sigdatafile1",
help="First signature file to compare (or signature file to dump, if second not specified). Not used when using -t/--task.",
action="store", nargs='?')
parser.add_argument("sigdatafile2",
help="Second signature file to compare",
action="store", nargs='?')
options = parser.parse_args()
if is_dump:
options.color = 'never'
options.dump = True
options.sigdatafile2 = None
options.sigargs = None
if options.debug:
logger.setLevel(logging.DEBUG)
color = (options.color == 'always' or (options.color == 'auto' and sys.stdout.isatty()))
options, args = parser.parse_args(sys.argv)
if options.taskargs:
with bb.tinfoil.Tinfoil() as tinfoil:
tinfoil.prepare(config_only=True)
if not options.dump and options.sigargs:
files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0], options.sigargs[1])
else:
files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
if options.dump:
logger.debug("Signature file: %s" % files[-1])
output = bb.siggen.dump_sigfile(files[-1])
else:
if len(files) < 2:
logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (options.taskargs[0], options.taskargs[1]))
sys.exit(1)
# Recurse into signature comparison
logger.debug("Signature file (previous): %s" % files[-2])
logger.debug("Signature file (latest): %s" % files[-1])
output = bb.siggen.compare_sigfiles(files[-2], files[-1], recursecb, color=color)
tinfoil = bb.tinfoil.Tinfoil()
tinfoil.prepare(config_only = True)
find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1])
else:
if options.sigargs:
logger.error('-s/--signature can only be used together with -t/--task')
sys.exit(1)
try:
if not options.dump and options.sigdatafile1 and options.sigdatafile2:
with bb.tinfoil.Tinfoil() as tinfoil:
tinfoil.prepare(config_only=True)
output = bb.siggen.compare_sigfiles(options.sigdatafile1, options.sigdatafile2, recursecb, color=color)
elif options.sigdatafile1:
output = bb.siggen.dump_sigfile(options.sigdatafile1)
else:
logger.error('Must specify signature file(s) or -t/--task')
parser.print_help()
if len(args) == 1:
parser.print_help()
else:
import cPickle
try:
if len(args) == 2:
output = bb.siggen.dump_sigfile(sys.argv[1])
else:
output = bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
except IOError as e:
logger.error(str(e))
sys.exit(1)
except cPickle.UnpicklingError, EOFError:
logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
sys.exit(1)
except IOError as e:
logger.error(str(e))
sys.exit(1)
except (pickle.UnpicklingError, EOFError):
logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
sys.exit(1)
if output:
print('\n'.join(output))
if output:
print '\n'.join(output)

View File

@@ -1 +0,0 @@
bitbake-diffsigs

65
bitbake/bin/bitbake-dumpsig Executable file
View File

@@ -0,0 +1,65 @@
#!/usr/bin/env python
# bitbake-dumpsig
# BitBake task signature dump utility
#
# Copyright (C) 2013 Intel Corporation
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import os
import sys
import warnings
import optparse
import logging
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
import bb.siggen
def logger_create(name, output=sys.stderr):
logger = logging.getLogger(name)
console = logging.StreamHandler(output)
format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
if output.isatty():
format.enable_color()
console.setFormatter(format)
logger.addHandler(console)
logger.setLevel(logging.INFO)
return logger
logger = logger_create('bitbake-dumpsig')
parser = optparse.OptionParser(
description = "Dumps siginfo/sigdata files written out by BitBake",
usage = """
%prog sigdatafile""")
options, args = parser.parse_args(sys.argv)
if len(args) == 1:
parser.print_help()
else:
import cPickle
try:
output = bb.siggen.dump_sigfile(args[1])
except IOError as e:
logger.error(str(e))
sys.exit(1)
except cPickle.UnpicklingError, EOFError:
logger.error('Invalid signature data - ensure you are specifying a sigdata/siginfo file')
sys.exit(1)
if output:
print '\n'.join(output)

View File

@@ -1,50 +0,0 @@
#! /usr/bin/env python3
#
# Copyright (C) 2021 Richard Purdie
#
# SPDX-License-Identifier: GPL-2.0-only
#
import argparse
import io
import os
import sys
import warnings
warnings.simplefilter("default")
bindir = os.path.dirname(__file__)
topdir = os.path.dirname(bindir)
sys.path[0:0] = [os.path.join(topdir, 'lib')]
import bb.tinfoil
if __name__ == "__main__":
parser = argparse.ArgumentParser(description="Bitbake Query Variable")
parser.add_argument("variable", help="variable name to query")
parser.add_argument("-r", "--recipe", help="Recipe name to query", default=None, required=False)
parser.add_argument('-u', '--unexpand', help='Do not expand the value (with --value)', action="store_true")
parser.add_argument('-f', '--flag', help='Specify a variable flag to query (with --value)', default=None)
parser.add_argument('--value', help='Only report the value, no history and no variable name', action="store_true")
args = parser.parse_args()
if args.unexpand and not args.value:
print("--unexpand only makes sense with --value")
sys.exit(1)
if args.flag and not args.value:
print("--flag only makes sense with --value")
sys.exit(1)
with bb.tinfoil.Tinfoil(tracking=True) as tinfoil:
if args.recipe:
tinfoil.prepare(quiet=2)
d = tinfoil.parse_recipe(args.recipe)
else:
tinfoil.prepare(quiet=2, config_only=True)
d = tinfoil.config_data
if args.flag:
print(str(d.getVarFlag(args.variable, args.flag, expand=(not args.unexpand))))
elif args.value:
print(str(d.getVar(args.variable, expand=(not args.unexpand))))
else:
bb.data.emit_var(args.variable, d=d, all=True)

View File

@@ -1,169 +0,0 @@
#! /usr/bin/env python3
#
# Copyright (C) 2019 Garmin Ltd.
#
# SPDX-License-Identifier: GPL-2.0-only
#
import argparse
import hashlib
import logging
import os
import pprint
import sys
import threading
import time
import warnings
warnings.simplefilter("default")
try:
import tqdm
ProgressBar = tqdm.tqdm
except ImportError:
class ProgressBar(object):
def __init__(self, *args, **kwargs):
pass
def __enter__(self):
return self
def __exit__(self, *args, **kwargs):
pass
def update(self):
pass
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)), 'lib'))
import hashserv
DEFAULT_ADDRESS = 'unix://./hashserve.sock'
METHOD = 'stress.test.method'
def main():
def handle_stats(args, client):
if args.reset:
s = client.reset_stats()
else:
s = client.get_stats()
pprint.pprint(s)
return 0
def handle_stress(args, client):
def thread_main(pbar, lock):
nonlocal found_hashes
nonlocal missed_hashes
nonlocal max_time
client = hashserv.create_client(args.address)
for i in range(args.requests):
taskhash = hashlib.sha256()
taskhash.update(args.taskhash_seed.encode('utf-8'))
taskhash.update(str(i).encode('utf-8'))
start_time = time.perf_counter()
l = client.get_unihash(METHOD, taskhash.hexdigest())
elapsed = time.perf_counter() - start_time
with lock:
if l:
found_hashes += 1
else:
missed_hashes += 1
max_time = max(elapsed, max_time)
pbar.update()
max_time = 0
found_hashes = 0
missed_hashes = 0
lock = threading.Lock()
total_requests = args.clients * args.requests
start_time = time.perf_counter()
with ProgressBar(total=total_requests) as pbar:
threads = [threading.Thread(target=thread_main, args=(pbar, lock), daemon=False) for _ in range(args.clients)]
for t in threads:
t.start()
for t in threads:
t.join()
elapsed = time.perf_counter() - start_time
with lock:
print("%d requests in %.1fs. %.1f requests per second" % (total_requests, elapsed, total_requests / elapsed))
print("Average request time %.8fs" % (elapsed / total_requests))
print("Max request time was %.8fs" % max_time)
print("Found %d hashes, missed %d" % (found_hashes, missed_hashes))
if args.report:
with ProgressBar(total=args.requests) as pbar:
for i in range(args.requests):
taskhash = hashlib.sha256()
taskhash.update(args.taskhash_seed.encode('utf-8'))
taskhash.update(str(i).encode('utf-8'))
outhash = hashlib.sha256()
outhash.update(args.outhash_seed.encode('utf-8'))
outhash.update(str(i).encode('utf-8'))
client.report_unihash(taskhash.hexdigest(), METHOD, outhash.hexdigest(), taskhash.hexdigest())
with lock:
pbar.update()
parser = argparse.ArgumentParser(description='Hash Equivalence Client')
parser.add_argument('--address', default=DEFAULT_ADDRESS, help='Server address (default "%(default)s")')
parser.add_argument('--log', default='WARNING', help='Set logging level')
subparsers = parser.add_subparsers()
stats_parser = subparsers.add_parser('stats', help='Show server stats')
stats_parser.add_argument('--reset', action='store_true',
help='Reset server stats')
stats_parser.set_defaults(func=handle_stats)
stress_parser = subparsers.add_parser('stress', help='Run stress test')
stress_parser.add_argument('--clients', type=int, default=10,
help='Number of simultaneous clients')
stress_parser.add_argument('--requests', type=int, default=1000,
help='Number of requests each client will perform')
stress_parser.add_argument('--report', action='store_true',
help='Report new hashes')
stress_parser.add_argument('--taskhash-seed', default='',
help='Include string in taskhash')
stress_parser.add_argument('--outhash-seed', default='',
help='Include string in outhash')
stress_parser.set_defaults(func=handle_stress)
args = parser.parse_args()
logger = logging.getLogger('hashserv')
level = getattr(logging, args.log.upper(), None)
if not isinstance(level, int):
raise ValueError('Invalid log level: %s' % args.log)
logger.setLevel(level)
console = logging.StreamHandler()
console.setLevel(level)
logger.addHandler(console)
func = getattr(args, 'func', None)
if func:
client = hashserv.create_client(args.address)
return func(args, client)
return 0
if __name__ == '__main__':
try:
ret = main()
except Exception:
ret = 1
import traceback
traceback.print_exc()
sys.exit(ret)

View File

@@ -1,66 +0,0 @@
#! /usr/bin/env python3
#
# Copyright (C) 2018 Garmin Ltd.
#
# SPDX-License-Identifier: GPL-2.0-only
#
import os
import sys
import logging
import argparse
import sqlite3
import warnings
warnings.simplefilter("default")
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)), 'lib'))
import hashserv
VERSION = "1.0.0"
DEFAULT_BIND = 'unix://./hashserve.sock'
def main():
parser = argparse.ArgumentParser(description='Hash Equivalence Reference Server. Version=%s' % VERSION,
epilog='''The bind address is the path to a unix domain socket if it is
prefixed with "unix://". Otherwise, it is an IP address
and port in form ADDRESS:PORT. To bind to all addresses, leave
the ADDRESS empty, e.g. "--bind :8686". To bind to a specific
IPv6 address, enclose the address in "[]", e.g.
"--bind [::1]:8686"'''
)
parser.add_argument('-b', '--bind', default=DEFAULT_BIND, help='Bind address (default "%(default)s")')
parser.add_argument('-d', '--database', default='./hashserv.db', help='Database file (default "%(default)s")')
parser.add_argument('-l', '--log', default='WARNING', help='Set logging level')
parser.add_argument('-u', '--upstream', help='Upstream hashserv to pull hashes from')
parser.add_argument('-r', '--read-only', action='store_true', help='Disallow write operations from clients')
args = parser.parse_args()
logger = logging.getLogger('hashserv')
level = getattr(logging, args.log.upper(), None)
if not isinstance(level, int):
raise ValueError('Invalid log level: %s' % args.log)
logger.setLevel(level)
console = logging.StreamHandler()
console.setLevel(level)
logger.addHandler(console)
server = hashserv.create_server(args.bind, args.database, upstream=args.upstream, read_only=args.read_only)
server.serve_forever()
return 0
if __name__ == '__main__':
try:
ret = main()
except Exception:
ret = 1
import traceback
traceback.print_exc()
sys.exit(ret)

View File

@@ -1,102 +1,726 @@
#!/usr/bin/env python3
#!/usr/bin/env python
# This script has subcommands which operate against your bitbake layers, either
# displaying useful information, or acting against them.
# See the help output for details on available commands.
# Copyright (C) 2011 Mentor Graphics Corporation
# Copyright (C) 2011-2015 Intel Corporation
# Copyright (C) 2012 Intel Corporation
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import cmd
import logging
import os
import sys
import argparse
import warnings
warnings.simplefilter("default")
import fnmatch
from collections import defaultdict
import re
bindir = os.path.dirname(__file__)
topdir = os.path.dirname(bindir)
sys.path[0:0] = [os.path.join(topdir, 'lib')]
import bb.cache
import bb.cooker
import bb.providers
import bb.utils
import bb.tinfoil
import bb.msg
logger = bb.msg.logger_create('bitbake-layers', sys.stdout)
def main():
parser = argparse.ArgumentParser(
description="BitBake layers utility",
epilog="Use %(prog)s <subcommand> --help to get help on a specific command",
add_help=False)
parser.add_argument('-d', '--debug', help='Enable debug output', action='store_true')
parser.add_argument('-q', '--quiet', help='Print only errors', action='store_true')
parser.add_argument('-F', '--force', help='Force add without recipe parse verification', action='store_true')
parser.add_argument('--color', choices=['auto', 'always', 'never'], default='auto', help='Colorize output (where %(metavar)s is %(choices)s)', metavar='COLOR')
global_args, unparsed_args = parser.parse_known_args()
# Help is added here rather than via add_help=True, as we don't want it to
# be handled by parse_known_args()
parser.add_argument('-h', '--help', action='help', default=argparse.SUPPRESS,
help='show this help message and exit')
subparsers = parser.add_subparsers(title='subcommands', metavar='<subcommand>')
subparsers.required = True
if global_args.debug:
logger.setLevel(logging.DEBUG)
elif global_args.quiet:
logger.setLevel(logging.ERROR)
# Need to re-run logger_create with color argument
# (will be the same logger since it has the same name)
bb.msg.logger_create('bitbake-layers', output=sys.stdout,
color=global_args.color,
level=logger.getEffectiveLevel())
plugins = []
tinfoil = bb.tinfoil.Tinfoil(tracking=True)
tinfoil.logger.setLevel(logger.getEffectiveLevel())
try:
tinfoil.prepare(True)
for path in ([topdir] +
tinfoil.config_data.getVar('BBPATH').split(':')):
pluginpath = os.path.join(path, 'lib', 'bblayers')
bb.utils.load_plugins(logger, plugins, pluginpath)
registered = False
for plugin in plugins:
if hasattr(plugin, 'register_commands'):
registered = True
plugin.register_commands(subparsers)
if hasattr(plugin, 'tinfoil_init'):
plugin.tinfoil_init(tinfoil)
if not registered:
logger.error("No commands registered - missing plugins?")
sys.exit(1)
args = parser.parse_args(unparsed_args, namespace=global_args)
if getattr(args, 'parserecipes', False):
tinfoil.config_data.disableTracking()
tinfoil.parse_recipes()
tinfoil.config_data.enableTracking()
return args.func(args)
finally:
tinfoil.shutdown()
if __name__ == "__main__":
try:
ret = main()
except bb.BBHandledException:
ret = 1
except Exception:
ret = 1
import traceback
traceback.print_exc()
sys.exit(ret)
logger = logging.getLogger('BitBake')
def main(args):
cmds = Commands()
if args:
# Allow user to specify e.g. show-layers instead of show_layers
args = [args[0].replace('-', '_')] + args[1:]
cmds.onecmd(' '.join(args))
else:
cmds.do_help('')
return cmds.returncode
class Commands(cmd.Cmd):
def __init__(self):
self.bbhandler = None
self.returncode = 0
self.bblayers = []
cmd.Cmd.__init__(self)
def init_bbhandler(self, config_only = False):
if not self.bbhandler:
self.bbhandler = bb.tinfoil.Tinfoil()
self.bblayers = (self.bbhandler.config_data.getVar('BBLAYERS', True) or "").split()
self.bbhandler.prepare(config_only)
def default(self, line):
"""Handle unrecognised commands"""
sys.stderr.write("Unrecognised command or option\n")
self.do_help('')
def do_help(self, topic):
"""display general help or help on a specified command"""
if topic:
sys.stdout.write('%s: ' % topic)
cmd.Cmd.do_help(self, topic.replace('-', '_'))
else:
sys.stdout.write("usage: bitbake-layers <command> [arguments]\n\n")
sys.stdout.write("Available commands:\n")
procnames = list(set(self.get_names()))
for procname in procnames:
if procname[:3] == 'do_':
sys.stdout.write(" %s\n" % procname[3:].replace('_', '-'))
doc = getattr(self, procname).__doc__
if doc:
sys.stdout.write(" %s\n" % doc.splitlines()[0])
def do_show_layers(self, args):
"""show current configured layers"""
self.init_bbhandler(config_only = True)
logger.plain("%s %s %s" % ("layer".ljust(20), "path".ljust(40), "priority"))
logger.plain('=' * 74)
for layerdir in self.bblayers:
layername = self.get_layer_name(layerdir)
layerpri = 0
for layer, _, regex, pri in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
if regex.match(os.path.join(layerdir, 'test')):
layerpri = pri
break
logger.plain("%s %s %d" % (layername.ljust(20), layerdir.ljust(40), layerpri))
def version_str(self, pe, pv, pr = None):
verstr = "%s" % pv
if pr:
verstr = "%s-%s" % (verstr, pr)
if pe:
verstr = "%s:%s" % (pe, verstr)
return verstr
def do_show_overlayed(self, args):
"""list overlayed recipes (where the same recipe exists in another layer)
usage: show-overlayed [-f] [-s]
Lists the names of overlayed recipes and the available versions in each
layer, with the preferred version first. Note that skipped recipes that
are overlayed will also be listed, with a " (skipped)" suffix.
Options:
-f instead of the default formatting, list filenames of higher priority
recipes with the ones they overlay indented underneath
-s only list overlayed recipes where the version is the same
"""
self.init_bbhandler()
show_filenames = False
show_same_ver_only = False
for arg in args.split():
if arg == '-f':
show_filenames = True
elif arg == '-s':
show_same_ver_only = True
else:
sys.stderr.write("show-overlayed: invalid option %s\n" % arg)
self.do_help('')
return
items_listed = self.list_recipes('Overlayed recipes', None, True, show_same_ver_only, show_filenames, True)
# Check for overlayed .bbclass files
classes = defaultdict(list)
for layerdir in self.bblayers:
classdir = os.path.join(layerdir, 'classes')
if os.path.exists(classdir):
for classfile in os.listdir(classdir):
if os.path.splitext(classfile)[1] == '.bbclass':
classes[classfile].append(classdir)
# Locating classes and other files is a bit more complicated than recipes -
# layer priority is not a factor; instead BitBake uses the first matching
# file in BBPATH, which is manipulated directly by each layer's
# conf/layer.conf in turn, thus the order of layers in bblayers.conf is a
# factor - however, each layer.conf is free to either prepend or append to
# BBPATH (or indeed do crazy stuff with it). Thus the order in BBPATH might
# not be exactly the order present in bblayers.conf either.
bbpath = str(self.bbhandler.config_data.getVar('BBPATH', True))
overlayed_class_found = False
for (classfile, classdirs) in classes.items():
if len(classdirs) > 1:
if not overlayed_class_found:
logger.plain('=== Overlayed classes ===')
overlayed_class_found = True
mainfile = bb.utils.which(bbpath, os.path.join('classes', classfile))
if show_filenames:
logger.plain('%s' % mainfile)
else:
# We effectively have to guess the layer here
logger.plain('%s:' % classfile)
mainlayername = '?'
for layerdir in self.bblayers:
classdir = os.path.join(layerdir, 'classes')
if mainfile.startswith(classdir):
mainlayername = self.get_layer_name(layerdir)
logger.plain(' %s' % mainlayername)
for classdir in classdirs:
fullpath = os.path.join(classdir, classfile)
if fullpath != mainfile:
if show_filenames:
print(' %s' % fullpath)
else:
print(' %s' % self.get_layer_name(os.path.dirname(classdir)))
if overlayed_class_found:
items_listed = True;
if not items_listed:
logger.plain('No overlayed files found.')
def do_show_recipes(self, args):
"""list available recipes, showing the layer they are provided by
usage: show-recipes [-f] [-m] [pnspec]
Lists the names of overlayed recipes and the available versions in each
layer, with the preferred version first. Optionally you may specify
pnspec to match a specified recipe name (supports wildcards). Note that
skipped recipes will also be listed, with a " (skipped)" suffix.
Options:
-f instead of the default formatting, list filenames of higher priority
recipes with other available recipes indented underneath
-m only list where multiple recipes (in the same layer or different
layers) exist for the same recipe name
"""
self.init_bbhandler()
show_filenames = False
show_multi_provider_only = False
pnspec = None
title = 'Available recipes:'
for arg in args.split():
if arg == '-f':
show_filenames = True
elif arg == '-m':
show_multi_provider_only = True
elif not arg.startswith('-'):
pnspec = arg
title = 'Available recipes matching %s:' % pnspec
else:
sys.stderr.write("show-recipes: invalid option %s\n" % arg)
self.do_help('')
return
self.list_recipes(title, pnspec, False, False, show_filenames, show_multi_provider_only)
def list_recipes(self, title, pnspec, show_overlayed_only, show_same_ver_only, show_filenames, show_multi_provider_only):
pkg_pn = self.bbhandler.cooker.recipecache.pkg_pn
(latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.config_data, self.bbhandler.cooker.recipecache, pkg_pn)
allproviders = bb.providers.allProviders(self.bbhandler.cooker.recipecache)
# Ensure we list skipped recipes
# We are largely guessing about PN, PV and the preferred version here,
# but we have no choice since skipped recipes are not fully parsed
skiplist = self.bbhandler.cooker.skiplist.keys()
skiplist.sort( key=lambda fileitem: self.bbhandler.cooker.collection.calc_bbfile_priority(fileitem) )
skiplist.reverse()
for fn in skiplist:
recipe_parts = os.path.splitext(os.path.basename(fn))[0].split('_')
p = recipe_parts[0]
if len(recipe_parts) > 1:
ver = (None, recipe_parts[1], None)
else:
ver = (None, 'unknown', None)
allproviders[p].append((ver, fn))
if not p in pkg_pn:
pkg_pn[p] = 'dummy'
preferred_versions[p] = (ver, fn)
def print_item(f, pn, ver, layer, ispref):
if f in skiplist:
skipped = ' (skipped)'
else:
skipped = ''
if show_filenames:
if ispref:
logger.plain("%s%s", f, skipped)
else:
logger.plain(" %s%s", f, skipped)
else:
if ispref:
logger.plain("%s:", pn)
logger.plain(" %s %s%s", layer.ljust(20), ver, skipped)
preffiles = []
items_listed = False
for p in sorted(pkg_pn):
if pnspec:
if not fnmatch.fnmatch(p, pnspec):
continue
if len(allproviders[p]) > 1 or not show_multi_provider_only:
pref = preferred_versions[p]
preffile = bb.cache.Cache.virtualfn2realfn(pref[1])[0]
if preffile not in preffiles:
preflayer = self.get_file_layer(preffile)
multilayer = False
same_ver = True
provs = []
for prov in allproviders[p]:
provfile = bb.cache.Cache.virtualfn2realfn(prov[1])[0]
provlayer = self.get_file_layer(provfile)
provs.append((provfile, provlayer, prov[0]))
if provlayer != preflayer:
multilayer = True
if prov[0] != pref[0]:
same_ver = False
if (multilayer or not show_overlayed_only) and (same_ver or not show_same_ver_only):
if not items_listed:
logger.plain('=== %s ===' % title)
items_listed = True
print_item(preffile, p, self.version_str(pref[0][0], pref[0][1]), preflayer, True)
for (provfile, provlayer, provver) in provs:
if provfile != preffile:
print_item(provfile, p, self.version_str(provver[0], provver[1]), provlayer, False)
# Ensure we don't show two entries for BBCLASSEXTENDed recipes
preffiles.append(preffile)
return items_listed
def do_flatten(self, args):
"""flattens layer configuration into a separate output directory.
usage: flatten [layer1 layer2 [layer3]...] <outputdir>
Takes the specified layers (or all layers in the current layer
configuration if none are specified) and builds a "flattened" directory
containing the contents of all layers, with any overlayed recipes removed
and bbappends appended to the corresponding recipes. Note that some manual
cleanup may still be necessary afterwards, in particular:
* where non-recipe files (such as patches) are overwritten (the flatten
command will show a warning for these)
* where anything beyond the normal layer setup has been added to
layer.conf (only the lowest priority number layer's layer.conf is used)
* overridden/appended items from bbappends will need to be tidied up
* when the flattened layers do not have the same directory structure (the
flatten command should show a warning when this will cause a problem)
Warning: if you flatten several layers where another layer is intended to
be used "inbetween" them (in layer priority order) such that recipes /
bbappends in the layers interact, and then attempt to use the new output
layer together with that other layer, you may no longer get the same
build results (as the layer priority order has effectively changed).
"""
arglist = args.split()
if len(arglist) < 1:
logger.error('Please specify an output directory')
self.do_help('flatten')
return
if len(arglist) == 2:
logger.error('If you specify layers to flatten you must specify at least two')
self.do_help('flatten')
return
outputdir = arglist[-1]
if os.path.exists(outputdir) and os.listdir(outputdir):
logger.error('Directory %s exists and is non-empty, please clear it out first' % outputdir)
return
self.init_bbhandler()
layers = self.bblayers
if len(arglist) > 2:
layernames = arglist[:-1]
found_layernames = []
found_layerdirs = []
for layerdir in layers:
layername = self.get_layer_name(layerdir)
if layername in layernames:
found_layerdirs.append(layerdir)
found_layernames.append(layername)
for layername in layernames:
if not layername in found_layernames:
logger.error('Unable to find layer %s in current configuration, please run "%s show-layers" to list configured layers' % (layername, os.path.basename(sys.argv[0])))
return
layers = found_layerdirs
else:
layernames = []
# Ensure a specified path matches our list of layers
def layer_path_match(path):
for layerdir in layers:
if path.startswith(os.path.join(layerdir, '')):
return layerdir
return None
appended_recipes = []
for layer in layers:
overlayed = []
for f in self.bbhandler.cooker.collection.overlayed.iterkeys():
for of in self.bbhandler.cooker.collection.overlayed[f]:
if of.startswith(layer):
overlayed.append(of)
logger.plain('Copying files from %s...' % layer )
for root, dirs, files in os.walk(layer):
for f1 in files:
f1full = os.sep.join([root, f1])
if f1full in overlayed:
logger.plain(' Skipping overlayed file %s' % f1full )
else:
ext = os.path.splitext(f1)[1]
if ext != '.bbappend':
fdest = f1full[len(layer):]
fdest = os.path.normpath(os.sep.join([outputdir,fdest]))
bb.utils.mkdirhier(os.path.dirname(fdest))
if os.path.exists(fdest):
if f1 == 'layer.conf' and root.endswith('/conf'):
logger.plain(' Skipping layer config file %s' % f1full )
continue
else:
logger.warn('Overwriting file %s', fdest)
bb.utils.copyfile(f1full, fdest)
if ext == '.bb':
if f1 in self.bbhandler.cooker.collection.appendlist:
appends = self.bbhandler.cooker.collection.appendlist[f1]
if appends:
logger.plain(' Applying appends to %s' % fdest )
for appendname in appends:
if layer_path_match(appendname):
self.apply_append(appendname, fdest)
appended_recipes.append(f1)
# Take care of when some layers are excluded and yet we have included bbappends for those recipes
for recipename in self.bbhandler.cooker.collection.appendlist.iterkeys():
if recipename not in appended_recipes:
appends = self.bbhandler.cooker.collection.appendlist[recipename]
first_append = None
for appendname in appends:
layer = layer_path_match(appendname)
if layer:
if first_append:
self.apply_append(appendname, first_append)
else:
fdest = appendname[len(layer):]
fdest = os.path.normpath(os.sep.join([outputdir,fdest]))
bb.utils.mkdirhier(os.path.dirname(fdest))
bb.utils.copyfile(appendname, fdest)
first_append = fdest
# Get the regex for the first layer in our list (which is where the conf/layer.conf file will
# have come from)
first_regex = None
layerdir = layers[0]
for layername, pattern, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
if regex.match(os.path.join(layerdir, 'test')):
first_regex = regex
break
if first_regex:
# Find the BBFILES entries that match (which will have come from this conf/layer.conf file)
bbfiles = str(self.bbhandler.config_data.getVar('BBFILES', True)).split()
bbfiles_layer = []
for item in bbfiles:
if first_regex.match(item):
newpath = os.path.join(outputdir, item[len(layerdir)+1:])
bbfiles_layer.append(newpath)
if bbfiles_layer:
# Check that all important layer files match BBFILES
for root, dirs, files in os.walk(outputdir):
for f1 in files:
ext = os.path.splitext(f1)[1]
if ext in ['.bb', '.bbappend']:
f1full = os.sep.join([root, f1])
entry_found = False
for item in bbfiles_layer:
if fnmatch.fnmatch(f1full, item):
entry_found = True
break
if not entry_found:
logger.warning("File %s does not match the flattened layer's BBFILES setting, you may need to edit conf/layer.conf or move the file elsewhere" % f1full)
def get_file_layer(self, filename):
for layer, _, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
if regex.match(filename):
for layerdir in self.bblayers:
if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
return self.get_layer_name(layerdir)
return "?"
def get_file_layerdir(self, filename):
for layer, _, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
if regex.match(filename):
for layerdir in self.bblayers:
if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
return layerdir
return "?"
def remove_layer_prefix(self, f):
"""Remove the layer_dir prefix, e.g., f = /path/to/layer_dir/foo/blah, the
return value will be: layer_dir/foo/blah"""
f_layerdir = self.get_file_layerdir(f)
prefix = os.path.join(os.path.dirname(f_layerdir), '')
return f[len(prefix):] if f.startswith(prefix) else f
def get_layer_name(self, layerdir):
return os.path.basename(layerdir.rstrip(os.sep))
def apply_append(self, appendname, recipename):
appendfile = open(appendname, 'r')
recipefile = open(recipename, 'a')
recipefile.write('\n')
recipefile.write('##### bbappended from %s #####\n' % self.get_file_layer(appendname))
recipefile.writelines(appendfile.readlines())
recipefile.close()
appendfile.close()
def do_show_appends(self, args):
"""list bbappend files and recipe files they apply to
usage: show-appends
Recipes are listed with the bbappends that apply to them as subitems.
"""
self.init_bbhandler()
if not self.bbhandler.cooker.collection.appendlist:
logger.plain('No append files found')
return
logger.plain('=== Appended recipes ===')
pnlist = list(self.bbhandler.cooker_data.pkg_pn.keys())
pnlist.sort()
for pn in pnlist:
self.show_appends_for_pn(pn)
self.show_appends_for_skipped()
def show_appends_for_pn(self, pn):
filenames = self.bbhandler.cooker_data.pkg_pn[pn]
best = bb.providers.findBestProvider(pn,
self.bbhandler.config_data,
self.bbhandler.cooker_data,
self.bbhandler.cooker_data.pkg_pn)
best_filename = os.path.basename(best[3])
self.show_appends_output(filenames, best_filename)
def show_appends_for_skipped(self):
filenames = [os.path.basename(f)
for f in self.bbhandler.cooker.skiplist.iterkeys()]
self.show_appends_output(filenames, None, " (skipped)")
def show_appends_output(self, filenames, best_filename, name_suffix = ''):
appended, missing = self.get_appends_for_files(filenames)
if appended:
for basename, appends in appended:
logger.plain('%s%s:', basename, name_suffix)
for append in appends:
logger.plain(' %s', append)
if best_filename:
if best_filename in missing:
logger.warn('%s: missing append for preferred version',
best_filename)
self.returncode |= 1
def get_appends_for_files(self, filenames):
appended, notappended = [], []
for filename in filenames:
_, cls = bb.cache.Cache.virtualfn2realfn(filename)
if cls:
continue
basename = os.path.basename(filename)
appends = self.bbhandler.cooker.collection.appendlist.get(basename)
if appends:
appended.append((basename, list(appends)))
else:
notappended.append(basename)
return appended, notappended
def do_show_cross_depends(self, args):
"""figure out the dependency between recipes that crosses a layer boundary.
usage: show-cross-depends [-f]
Figure out the dependency between recipes that crosses a layer boundary.
Options:
-f show full file path
NOTE:
The .bbappend file can impact the dependency.
"""
self.init_bbhandler()
show_filenames = False
for arg in args.split():
if arg == '-f':
show_filenames = True
else:
sys.stderr.write("show-cross-depends: invalid option %s\n" % arg)
self.do_help('')
return
pkg_fn = self.bbhandler.cooker_data.pkg_fn
bbpath = str(self.bbhandler.config_data.getVar('BBPATH', True))
self.require_re = re.compile(r"require\s+(.+)")
self.include_re = re.compile(r"include\s+(.+)")
self.inherit_re = re.compile(r"inherit\s+(.+)")
# The bb's DEPENDS and RDEPENDS
for f in pkg_fn:
f = bb.cache.Cache.virtualfn2realfn(f)[0]
# Get the layername that the file is in
layername = self.get_file_layer(f)
# The DEPENDS
deps = self.bbhandler.cooker_data.deps[f]
for pn in deps:
if pn in self.bbhandler.cooker_data.pkg_pn:
best = bb.providers.findBestProvider(pn,
self.bbhandler.config_data,
self.bbhandler.cooker_data,
self.bbhandler.cooker_data.pkg_pn)
self.check_cross_depends("DEPENDS", layername, f, best[3], show_filenames)
# The RDPENDS
all_rdeps = self.bbhandler.cooker_data.rundeps[f].values()
# Remove the duplicated or null one.
sorted_rdeps = {}
# The all_rdeps is the list in list, so we need two for loops
for k1 in all_rdeps:
for k2 in k1:
sorted_rdeps[k2] = 1
all_rdeps = sorted_rdeps.keys()
for rdep in all_rdeps:
all_p = bb.providers.getRuntimeProviders(self.bbhandler.cooker_data, rdep)
if all_p:
best = bb.providers.filterProvidersRunTime(all_p, rdep,
self.bbhandler.config_data,
self.bbhandler.cooker_data)[0][0]
self.check_cross_depends("RDEPENDS", layername, f, best, show_filenames)
# The inherit class
cls_re = re.compile('classes/')
if f in self.bbhandler.cooker_data.inherits:
inherits = self.bbhandler.cooker_data.inherits[f]
for cls in inherits:
# The inherits' format is [classes/cls, /path/to/classes/cls]
# ignore the classes/cls.
if not cls_re.match(cls):
inherit_layername = self.get_file_layer(cls)
if inherit_layername != layername:
if not show_filenames:
f_short = self.remove_layer_prefix(f)
cls = self.remove_layer_prefix(cls)
else:
f_short = f
logger.plain("%s inherits %s" % (f_short, cls))
# The 'require/include xxx' in the bb file
pv_re = re.compile(r"\${PV}")
fnfile = open(f, 'r')
line = fnfile.readline()
while line:
m, keyword = self.match_require_include(line)
# Found the 'require/include xxxx'
if m:
needed_file = m.group(1)
# Replace the ${PV} with the real PV
if pv_re.search(needed_file) and f in self.bbhandler.cooker_data.pkg_pepvpr:
pv = self.bbhandler.cooker_data.pkg_pepvpr[f][1]
needed_file = re.sub(r"\${PV}", pv, needed_file)
self.print_cross_files(bbpath, keyword, layername, f, needed_file, show_filenames)
line = fnfile.readline()
fnfile.close()
# The "require/include xxx" in conf/machine/*.conf, .inc and .bbclass
conf_re = re.compile(".*/conf/machine/[^\/]*\.conf$")
inc_re = re.compile(".*\.inc$")
# The "inherit xxx" in .bbclass
bbclass_re = re.compile(".*\.bbclass$")
for layerdir in self.bblayers:
layername = self.get_layer_name(layerdir)
for dirpath, dirnames, filenames in os.walk(layerdir):
for name in filenames:
f = os.path.join(dirpath, name)
s = conf_re.match(f) or inc_re.match(f) or bbclass_re.match(f)
if s:
ffile = open(f, 'r')
line = ffile.readline()
while line:
m, keyword = self.match_require_include(line)
# Only bbclass has the "inherit xxx" here.
bbclass=""
if not m and f.endswith(".bbclass"):
m, keyword = self.match_inherit(line)
bbclass=".bbclass"
# Find a 'require/include xxxx'
if m:
self.print_cross_files(bbpath, keyword, layername, f, m.group(1) + bbclass, show_filenames)
line = ffile.readline()
ffile.close()
def print_cross_files(self, bbpath, keyword, layername, f, needed_filename, show_filenames):
"""Print the depends that crosses a layer boundary"""
needed_file = bb.utils.which(bbpath, needed_filename)
if needed_file:
# Which layer is this file from
needed_layername = self.get_file_layer(needed_file)
if needed_layername != layername:
if not show_filenames:
f = self.remove_layer_prefix(f)
needed_file = self.remove_layer_prefix(needed_file)
logger.plain("%s %s %s" %(f, keyword, needed_file))
def match_inherit(self, line):
"""Match the inherit xxx line"""
return (self.inherit_re.match(line), "inherits")
def match_require_include(self, line):
"""Match the require/include xxx line"""
m = self.require_re.match(line)
keyword = "requires"
if not m:
m = self.include_re.match(line)
keyword = "includes"
return (m, keyword)
def check_cross_depends(self, keyword, layername, f, needed_file, show_filenames):
"""Print the DEPENDS/RDEPENDS file that crosses a layer boundary"""
best_realfn = bb.cache.Cache.virtualfn2realfn(needed_file)[0]
needed_layername = self.get_file_layer(best_realfn)
if needed_layername != layername:
if not show_filenames:
f = self.remove_layer_prefix(f)
best_realfn = self.remove_layer_prefix(best_realfn)
logger.plain("%s %s %s" % (f, keyword, best_realfn))
if __name__ == '__main__':
sys.exit(main(sys.argv[1:]) or 0)

View File

@@ -1,13 +1,7 @@
#!/usr/bin/env python3
#
# SPDX-License-Identifier: GPL-2.0-only
#
#!/usr/bin/env python
import os
import sys,logging
import optparse
import warnings
warnings.simplefilter("default")
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)),'lib'))
@@ -38,14 +32,12 @@ def main():
dest="host", type="string", default=PRHOST_DEFAULT)
parser.add_option("--port", help="port number(default: 8585)", action="store",
dest="port", type="int", default=PRPORT_DEFAULT)
parser.add_option("-r", "--read-only", help="open database in read-only mode",
action="store_true")
options, args = parser.parse_args(sys.argv)
prserv.init_logger(os.path.abspath(options.logfile),options.loglevel)
if options.start:
ret=prserv.serv.start_daemon(options.dbfile, options.host, options.port,os.path.abspath(options.logfile), options.read_only)
ret=prserv.serv.start_daemon(options.dbfile, options.host, options.port,os.path.abspath(options.logfile))
elif options.stop:
ret=prserv.serv.stop_daemon(options.host, options.port)
else:
@@ -58,6 +50,6 @@ if __name__ == "__main__":
except Exception:
ret = 1
import traceback
traceback.print_exc()
traceback.print_exc(5)
sys.exit(ret)

View File

@@ -1,77 +1,49 @@
#!/usr/bin/env python3
#!/usr/bin/env python
#
# Copyright (C) 2012 Richard Purdie
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import os
import sys, logging
import warnings
warnings.simplefilter("default")
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)), 'lib'))
import unittest
try:
import bb
import hashserv
import layerindexlib
except RuntimeError as exc:
sys.exit(str(exc))
tests = ["bb.tests.codeparser",
"bb.tests.color",
"bb.tests.cooker",
"bb.tests.cow",
"bb.tests.data",
"bb.tests.event",
"bb.tests.fetch",
"bb.tests.parse",
"bb.tests.persist_data",
"bb.tests.runqueue",
"bb.tests.siggen",
"bb.tests.utils",
"bb.tests.compression",
"hashserv.tests",
"layerindexlib.tests.layerindexobj",
"layerindexlib.tests.restapi",
"layerindexlib.tests.cooker"]
def usage():
print('usage: %s [testname1 [testname2]...]' % os.path.basename(sys.argv[0]))
if len(sys.argv) > 1:
if '--help' in sys.argv[1:]:
usage()
sys.exit(0)
tests = sys.argv[1:]
else:
tests = ["bb.tests.codeparser",
"bb.tests.cow",
"bb.tests.data",
"bb.tests.fetch",
"bb.tests.utils"]
for t in tests:
t = '.'.join(t.split('.')[:3])
__import__(t)
unittest.main(argv=["bitbake-selftest"] + tests)
# Set-up logging
class StdoutStreamHandler(logging.StreamHandler):
"""Special handler so that unittest is able to capture stdout"""
def __init__(self):
# Override __init__() because we don't want to set self.stream here
logging.Handler.__init__(self)
@property
def stream(self):
# We want to dynamically write wherever sys.stdout is pointing to
return sys.stdout
handler = StdoutStreamHandler()
bb.logger.addHandler(handler)
bb.logger.setLevel(logging.DEBUG)
ENV_HELP = """\
Environment variables:
BB_SKIP_NETTESTS set to 'yes' in order to skip tests using network
connection
BB_TMPDIR_NOCLEAN set to 'yes' to preserve test tmp directories
"""
class main(unittest.main):
def _print_help(self, *args, **kwargs):
super(main, self)._print_help(*args, **kwargs)
print(ENV_HELP)
if __name__ == '__main__':
main(defaultTest=tests, buffer=True)

View File

@@ -1,53 +0,0 @@
#!/usr/bin/env python3
#
# SPDX-License-Identifier: GPL-2.0-only
#
# Copyright (C) 2020 Richard Purdie
#
import os
import sys
import warnings
warnings.simplefilter("default")
import logging
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
if sys.getfilesystemencoding() != "utf-8":
sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
# Users shouldn't be running this code directly
if len(sys.argv) != 10 or not sys.argv[1].startswith("decafbad"):
print("bitbake-server is meant for internal execution by bitbake itself, please don't use it standalone.")
sys.exit(1)
import bb.server.process
lockfd = int(sys.argv[2])
readypipeinfd = int(sys.argv[3])
logfile = sys.argv[4]
lockname = sys.argv[5]
sockname = sys.argv[6]
timeout = float(sys.argv[7])
xmlrpcinterface = (sys.argv[8], int(sys.argv[9]))
if xmlrpcinterface[0] == "None":
xmlrpcinterface = (None, xmlrpcinterface[1])
# Replace standard fds with our own
with open('/dev/null', 'r') as si:
os.dup2(si.fileno(), sys.stdin.fileno())
so = open(logfile, 'a+')
os.dup2(so.fileno(), sys.stdout.fileno())
os.dup2(so.fileno(), sys.stderr.fileno())
# Have stdout and stderr be the same so log output matches chronologically
# and there aren't two seperate buffers
sys.stderr = sys.stdout
logger = logging.getLogger("BitBake")
# Ensure logging messages get sent to the UI as events
handler = bb.event.LogHandler()
logger.addHandler(handler)
bb.server.process.execServer(lockfd, readypipeinfd, lockname, sockname, timeout, xmlrpcinterface)

View File

@@ -1,12 +1,8 @@
#!/usr/bin/env python3
#
# SPDX-License-Identifier: GPL-2.0-only
#
#!/usr/bin/env python
import os
import sys
import warnings
warnings.simplefilter("default")
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
from bb import fetch2
import logging
@@ -14,50 +10,23 @@ import bb
import select
import errno
import signal
import pickle
import traceback
import queue
import shlex
import subprocess
from multiprocessing import Lock
from threading import Thread
if sys.getfilesystemencoding() != "utf-8":
sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
# Users shouldn't be running this code directly
if len(sys.argv) != 2 or not sys.argv[1].startswith("decafbad"):
if len(sys.argv) != 2 or sys.argv[1] != "decafbad":
print("bitbake-worker is meant for internal execution by bitbake itself, please don't use it standalone.")
sys.exit(1)
profiling = False
if sys.argv[1].startswith("decafbadbad"):
profiling = True
try:
import cProfile as profile
except:
import profile
# Unbuffer stdout to avoid log truncation in the event
# of an unorderly exit as well as to provide timely
# updates to log files for use with tail
try:
if sys.stdout.name == '<stdout>':
import fcntl
fl = fcntl.fcntl(sys.stdout.fileno(), fcntl.F_GETFL)
fl |= os.O_SYNC
fcntl.fcntl(sys.stdout.fileno(), fcntl.F_SETFL, fl)
#sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
except:
pass
logger = logging.getLogger("BitBake")
try:
import cPickle as pickle
except ImportError:
import pickle
bb.msg.note(1, bb.msg.domain.Cache, "Importing cPickle failed. Falling back to a very slow implementation.")
worker_pipe = sys.stdout.fileno()
bb.utils.nonblockingfd(worker_pipe)
# Need to guard against multiprocessing being used in child processes
# and multiple processes trying to write to the parent at the same time
worker_pipe_lock = None
handler = bb.event.LogHandler()
logger.addHandler(handler)
@@ -68,66 +37,40 @@ if 0:
format_str = "%(levelname)s: %(message)s"
conlogformat = bb.msg.BBLogFormatter(format_str)
consolelog = logging.FileHandler(logfilename)
bb.msg.addDefaultlogFilter(consolelog)
consolelog.setFormatter(conlogformat)
logger.addHandler(consolelog)
worker_queue = queue.Queue()
worker_queue = ""
def worker_fire(event, d):
data = b"<event>" + pickle.dumps(event) + b"</event>"
data = "<event>" + pickle.dumps(event) + "</event>"
worker_fire_prepickled(data)
def worker_fire_prepickled(event):
global worker_queue
worker_queue.put(event)
worker_queue = worker_queue + event
worker_flush()
#
# We can end up with write contention with the cooker, it can be trying to send commands
# and we can be trying to send event data back. Therefore use a separate thread for writing
# back data to cooker.
#
worker_thread_exit = False
def worker_flush():
global worker_queue, worker_pipe
def worker_flush(worker_queue):
worker_queue_int = b""
global worker_pipe, worker_thread_exit
if not worker_queue:
return
while True:
try:
worker_queue_int = worker_queue_int + worker_queue.get(True, 1)
except queue.Empty:
pass
while (worker_queue_int or not worker_queue.empty()):
try:
(_, ready, _) = select.select([], [worker_pipe], [], 1)
if not worker_queue.empty():
worker_queue_int = worker_queue_int + worker_queue.get()
written = os.write(worker_pipe, worker_queue_int)
worker_queue_int = worker_queue_int[written:]
except (IOError, OSError) as e:
if e.errno != errno.EAGAIN and e.errno != errno.EPIPE:
raise
if worker_thread_exit and worker_queue.empty() and not worker_queue_int:
return
worker_thread = Thread(target=worker_flush, args=(worker_queue,))
worker_thread.start()
try:
written = os.write(worker_pipe, worker_queue)
worker_queue = worker_queue[written:]
except (IOError, OSError) as e:
if e.errno != errno.EAGAIN:
raise
def worker_child_fire(event, d):
global worker_pipe
global worker_pipe_lock
data = b"<event>" + pickle.dumps(event) + b"</event>"
try:
worker_pipe_lock.acquire()
while(len(data)):
written = worker_pipe.write(data)
data = data[written:]
worker_pipe_lock.release()
except IOError:
sigterm_handler(None, None)
raise
data = "<event>" + pickle.dumps(event) + "</event>"
worker_pipe.write(data)
bb.event.worker_fire = worker_fire
@@ -138,37 +81,24 @@ def workerlog_write(msg):
lf.write(msg)
lf.flush()
def sigterm_handler(signum, frame):
signal.signal(signal.SIGTERM, signal.SIG_DFL)
os.killpg(0, signal.SIGTERM)
sys.exit()
def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, taskhash, unihash, appends, taskdepdata, extraconfigdata, quieterrors=False, dry_run_exec=False):
def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdata, quieterrors=False):
# We need to setup the environment BEFORE the fork, since
# a fork() or exec*() activates PSEUDO...
envbackup = {}
fakeroot = False
fakeenv = {}
umask = None
taskdep = workerdata["taskdeps"][fn]
if 'umask' in taskdep and taskname in taskdep['umask']:
umask = taskdep['umask'][taskname]
elif workerdata["umask"]:
umask = workerdata["umask"]
if umask:
# umask might come in as a number or text string..
try:
umask = int(umask, 8)
umask = int(taskdep['umask'][taskname],8)
except TypeError:
pass
dry_run = cfg.dry_run or dry_run_exec
umask = taskdep['umask'][taskname]
# We can't use the fakeroot environment in a dry run as it possibly hasn't been built
if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not dry_run:
fakeroot = True
if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not cfg.dry_run:
envvars = (workerdata["fakerootenv"][fn] or "").split()
for key, value in (var.split('=') for var in envvars):
envbackup[key] = os.environ.get(key)
@@ -178,7 +108,7 @@ def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, taskha
fakedirs = (workerdata["fakerootdirs"][fn] or "").split()
for p in fakedirs:
bb.utils.mkdirhier(p)
logger.debug2('Running %s:%s under fakeroot, fakedirs: %s' %
logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
(fn, taskname, ', '.join(fakedirs)))
else:
envvars = (workerdata["fakerootnoenv"][fn] or "").split()
@@ -196,34 +126,22 @@ def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, taskha
pipeout = os.fdopen(pipeout, 'wb', 0)
pid = os.fork()
except OSError as e:
logger.critical("fork failed: %d (%s)" % (e.errno, e.strerror))
sys.exit(1)
bb.msg.fatal("RunQueue", "fork failed: %d (%s)" % (e.errno, e.strerror))
if pid == 0:
def child():
global worker_pipe
global worker_pipe_lock
pipein.close()
bb.utils.signal_on_parent_exit("SIGTERM")
signal.signal(signal.SIGTERM, signal.SIG_DFL)
# Save out the PID so that the event can include it the
# events
bb.event.worker_pid = os.getpid()
bb.event.worker_fire = worker_child_fire
worker_pipe = pipeout
worker_pipe_lock = Lock()
# Make the child the process group leader and ensure no
# child process will be controlled by the current terminal
# This ensures signals sent to the controlling terminal like Ctrl+C
# don't stop the child processes.
os.setsid()
signal.signal(signal.SIGTERM, sigterm_handler)
# Let SIGHUP exit as SIGTERM
signal.signal(signal.SIGHUP, sigterm_handler)
# Make the child the process group leader
os.setpgid(0, 0)
# No stdin
newsi = os.open(os.devnull, os.O_RDWR)
os.dup2(newsi, sys.stdin.fileno())
@@ -231,84 +149,47 @@ def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, taskha
if umask:
os.umask(umask)
data.setVar("BB_WORKERCONTEXT", "1")
data.setVar("BB_TASKDEPDATA", taskdepdata)
data.setVar("BUILDNAME", workerdata["buildname"])
data.setVar("DATE", workerdata["date"])
data.setVar("TIME", workerdata["time"])
bb.parse.siggen.set_taskdata(workerdata["hashes"], workerdata["hash_deps"], workerdata["sigchecksums"])
ret = 0
try:
bb_cache = bb.cache.NoCache(databuilder)
(realfn, virtual, mc) = bb.cache.virtualfn2realfn(fn)
the_data = databuilder.mcdata[mc]
the_data.setVar("BB_WORKERCONTEXT", "1")
the_data.setVar("BB_TASKDEPDATA", taskdepdata)
if cfg.limited_deps:
the_data.setVar("BB_LIMITEDDEPS", "1")
the_data.setVar("BUILDNAME", workerdata["buildname"])
the_data.setVar("DATE", workerdata["date"])
the_data.setVar("TIME", workerdata["time"])
for varname, value in extraconfigdata.items():
the_data.setVar(varname, value)
bb.parse.siggen.set_taskdata(workerdata["sigdata"])
if "newhashes" in workerdata:
bb.parse.siggen.set_taskhashes(workerdata["newhashes"])
ret = 0
the_data = bb_cache.loadDataFull(fn, appends)
the_data.setVar('BB_TASKHASH', taskhash)
the_data.setVar('BB_UNIHASH', unihash)
bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", "")))
the_data = bb.cache.Cache.loadDataFull(fn, appends, data)
the_data.setVar('BB_TASKHASH', workerdata["runq_hash"][task])
for h in workerdata["hashes"]:
the_data.setVar("BBHASH_%s" % h, workerdata["hashes"][h])
for h in workerdata["hash_deps"]:
the_data.setVar("BBHASHDEPS_%s" % h, workerdata["hash_deps"][h])
# exported_vars() returns a generator which *cannot* be passed to os.environ.update()
# successfully. We also need to unset anything from the environment which shouldn't be there
exports = bb.data.exported_vars(the_data)
bb.utils.empty_environment()
for e, v in exports:
os.environ[e] = v
for e in fakeenv:
os.environ[e] = fakeenv[e]
the_data.setVar(e, fakeenv[e])
the_data.setVarFlag(e, 'export', "1")
task_exports = the_data.getVarFlag(taskname, 'exports')
if task_exports:
for e in task_exports.split():
the_data.setVarFlag(e, 'export', '1')
v = the_data.getVar(e)
if v is not None:
os.environ[e] = v
if quieterrors:
the_data.setVarFlag(taskname, "quieterrors", "1")
except Exception:
except Exception as exc:
if not quieterrors:
logger.critical(traceback.format_exc())
logger.critical(str(exc))
os._exit(1)
try:
if dry_run:
return 0
try:
if not cfg.dry_run:
ret = bb.build.exec_task(fn, taskname, the_data, cfg.profile)
finally:
if fakeroot:
fakerootcmd = shlex.split(the_data.getVar("FAKEROOTCMD"))
subprocess.run(fakerootcmd + ['-S'], check=True, stdout=subprocess.PIPE)
return ret
os._exit(ret)
except:
os._exit(1)
if not profiling:
os._exit(child())
else:
profname = "profile-%s.log" % (fn.replace("/", "-") + "-" + taskname)
prof = profile.Profile()
try:
ret = profile.Profile.runcall(prof, child)
finally:
prof.dump_stats(profname)
bb.utils.process_profilelog(profname)
os._exit(ret)
else:
for key, value in iter(envbackup.items()):
for key, value in envbackup.iteritems():
if value is None:
del os.environ[key]
else:
@@ -325,24 +206,22 @@ class runQueueWorkerPipe():
if pipeout:
pipeout.close()
bb.utils.nonblockingfd(self.input)
self.queue = b""
self.queue = ""
def read(self):
start = len(self.queue)
try:
self.queue = self.queue + (self.input.read(102400) or b"")
self.queue = self.queue + self.input.read(102400)
except (OSError, IOError) as e:
if e.errno != errno.EAGAIN:
raise
end = len(self.queue)
index = self.queue.find(b"</event>")
index = self.queue.find("</event>")
while index != -1:
msg = self.queue[:index+8]
assert msg.startswith(b"<event>") and msg.count(b"<event>") == 1
worker_fire_prepickled(msg)
worker_fire_prepickled(self.queue[:index+8])
self.queue = self.queue[index+8:]
index = self.queue.find(b"</event>")
index = self.queue.find("</event>")
return (end > start)
def close(self):
@@ -358,27 +237,17 @@ class BitbakeWorker(object):
def __init__(self, din):
self.input = din
bb.utils.nonblockingfd(self.input)
self.queue = b""
self.queue = ""
self.cookercfg = None
self.databuilder = None
self.data = None
self.extraconfigdata = None
self.build_pids = {}
self.build_pipes = {}
signal.signal(signal.SIGTERM, self.sigterm_exception)
# Let SIGHUP exit as SIGTERM
signal.signal(signal.SIGHUP, self.sigterm_exception)
if "beef" in sys.argv[1]:
bb.utils.set_process_name("Worker (Fakeroot)")
else:
bb.utils.set_process_name("Worker")
def sigterm_exception(self, signum, stackframe):
if signum == signal.SIGTERM:
bb.warn("Worker received SIGTERM, shutting down...")
elif signum == signal.SIGHUP:
bb.warn("Worker received SIGHUP, shutting down...")
bb.warn("Worker recieved SIGTERM, shutting down...")
self.handle_finishnow(None)
signal.signal(signal.SIGTERM, signal.SIG_DFL)
os.kill(os.getpid(), signal.SIGTERM)
@@ -386,44 +255,34 @@ class BitbakeWorker(object):
def serve(self):
while True:
(ready, _, _) = select.select([self.input] + [i.input for i in self.build_pipes.values()], [] , [], 1)
if self.input in ready:
if self.input in ready or len(self.queue):
start = len(self.queue)
try:
r = self.input.read()
if len(r) == 0:
# EOF on pipe, server must have terminated
self.sigterm_exception(signal.SIGTERM, None)
self.queue = self.queue + r
self.queue = self.queue + self.input.read()
except (OSError, IOError):
pass
if len(self.queue):
self.handle_item(b"cookerconfig", self.handle_cookercfg)
self.handle_item(b"extraconfigdata", self.handle_extraconfigdata)
self.handle_item(b"workerdata", self.handle_workerdata)
self.handle_item(b"newtaskhashes", self.handle_newtaskhashes)
self.handle_item(b"runtask", self.handle_runtask)
self.handle_item(b"finishnow", self.handle_finishnow)
self.handle_item(b"ping", self.handle_ping)
self.handle_item(b"quit", self.handle_quit)
end = len(self.queue)
self.handle_item("cookerconfig", self.handle_cookercfg)
self.handle_item("workerdata", self.handle_workerdata)
self.handle_item("runtask", self.handle_runtask)
self.handle_item("finishnow", self.handle_finishnow)
self.handle_item("ping", self.handle_ping)
self.handle_item("quit", self.handle_quit)
for pipe in self.build_pipes:
if self.build_pipes[pipe].input in ready:
self.build_pipes[pipe].read()
self.build_pipes[pipe].read()
if len(self.build_pids):
while self.process_waitpid():
continue
self.process_waitpid()
worker_flush()
def handle_item(self, item, func):
if self.queue.startswith(b"<" + item + b">"):
index = self.queue.find(b"</" + item + b">")
if self.queue.startswith("<" + item + ">"):
index = self.queue.find("</" + item + ">")
while index != -1:
try:
func(self.queue[(len(item) + 2):index])
except pickle.UnpicklingError:
workerlog_write("Unable to unpickle data: %s\n" % ":".join("{:02x}".format(c) for c in self.queue))
raise
func(self.queue[(len(item) + 2):index])
self.queue = self.queue[(index + len(item) + 3):]
index = self.queue.find(b"</" + item + b">")
index = self.queue.find("</" + item + ">")
def handle_cookercfg(self, data):
self.cookercfg = pickle.loads(data)
@@ -431,26 +290,18 @@ class BitbakeWorker(object):
self.databuilder.parseBaseConfiguration()
self.data = self.databuilder.data
def handle_extraconfigdata(self, data):
self.extraconfigdata = pickle.loads(data)
def handle_workerdata(self, data):
self.workerdata = pickle.loads(data)
bb.build.verboseShellLogging = self.workerdata["build_verbose_shell"]
bb.build.verboseStdoutLogging = self.workerdata["build_verbose_stdout"]
bb.msg.loggerDefaultLogLevel = self.workerdata["logdefaultlevel"]
bb.msg.loggerDefaultDebugLevel = self.workerdata["logdefaultdebug"]
bb.msg.loggerDefaultVerbose = self.workerdata["logdefaultverbose"]
bb.msg.loggerVerboseLogs = self.workerdata["logdefaultverboselogs"]
bb.msg.loggerDefaultDomains = self.workerdata["logdefaultdomain"]
for mc in self.databuilder.mcdata:
self.databuilder.mcdata[mc].setVar("PRSERV_HOST", self.workerdata["prhost"])
self.databuilder.mcdata[mc].setVar("BB_HASHSERVE", self.workerdata["hashservaddr"])
def handle_newtaskhashes(self, data):
self.workerdata["newhashes"] = pickle.loads(data)
self.data.setVar("PRSERV_HOST", self.workerdata["prhost"])
def handle_ping(self, _):
workerlog_write("Handling ping\n")
logger.warning("Pong from bitbake-worker!")
logger.warn("Pong from bitbake-worker!")
def handle_quit(self, data):
workerlog_write("Handling quit\n")
@@ -460,10 +311,10 @@ class BitbakeWorker(object):
sys.exit(0)
def handle_runtask(self, data):
fn, task, taskname, taskhash, unihash, quieterrors, appends, taskdepdata, dry_run_exec = pickle.loads(data)
fn, task, taskname, quieterrors, appends, taskdepdata = pickle.loads(data)
workerlog_write("Handling runtask %s %s %s\n" % (task, fn, taskname))
pid, pipein, pipeout = fork_off_task(self.cookercfg, self.data, self.databuilder, self.workerdata, fn, task, taskname, taskhash, unihash, appends, taskdepdata, self.extraconfigdata, quieterrors, dry_run_exec)
pid, pipein, pipeout = fork_off_task(self.cookercfg, self.data, self.workerdata, fn, task, taskname, appends, taskdepdata, quieterrors)
self.build_pids[pid] = task
self.build_pipes[pid] = runQueueWorkerPipe(pipein, pipeout)
@@ -476,9 +327,9 @@ class BitbakeWorker(object):
try:
pid, status = os.waitpid(-1, os.WNOHANG)
if pid == 0 or os.WIFSTOPPED(status):
return False
return None
except OSError:
return False
return None
workerlog_write("Exit code of %s for pid %s\n" % (status, pid))
@@ -495,14 +346,12 @@ class BitbakeWorker(object):
self.build_pipes[pid].close()
del self.build_pipes[pid]
worker_fire_prepickled(b"<exitcode>" + pickle.dumps((task, status)) + b"</exitcode>")
return True
worker_fire_prepickled("<exitcode>" + pickle.dumps((task, status)) + "</exitcode>")
def handle_finishnow(self, _):
if self.build_pids:
logger.info("Sending SIGTERM to remaining %s tasks", len(self.build_pids))
for k, v in iter(self.build_pids.items()):
for k, v in self.build_pids.iteritems():
try:
os.kill(-k, signal.SIGTERM)
os.waitpid(-1, 0)
@@ -512,27 +361,15 @@ class BitbakeWorker(object):
self.build_pipes[pipe].read()
try:
worker = BitbakeWorker(os.fdopen(sys.stdin.fileno(), 'rb'))
if not profiling:
worker.serve()
else:
profname = "profile-worker.log"
prof = profile.Profile()
try:
profile.Profile.runcall(prof, worker.serve)
finally:
prof.dump_stats(profname)
bb.utils.process_profilelog(profname)
worker = BitbakeWorker(sys.stdin)
worker.serve()
except BaseException as e:
if not normalexit:
import traceback
sys.stderr.write(traceback.format_exc())
sys.stderr.write(str(e))
finally:
worker_thread_exit = True
worker_thread.join()
workerlog_write("exiting")
if not normalexit:
sys.exit(1)
while len(worker_queue):
worker_flush()
workerlog_write("exitting")
sys.exit(0)

531
bitbake/bin/bitdoc Executable file
View File

@@ -0,0 +1,531 @@
#!/usr/bin/env python
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# Copyright (C) 2005 Holger Hans Peter Freyther
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import optparse, os, sys
# bitbake
sys.path.append(os.path.join(os.path.dirname(os.path.dirname(__file__), 'lib'))
import bb
import bb.parse
from string import split, join
__version__ = "0.0.2"
class HTMLFormatter:
"""
Simple class to help to generate some sort of HTML files. It is
quite inferior solution compared to docbook, gtkdoc, doxygen but it
should work for now.
We've a global introduction site (index.html) and then one site for
the list of keys (alphabetical sorted) and one for the list of groups,
one site for each key with links to the relations and groups.
index.html
all_keys.html
all_groups.html
groupNAME.html
keyNAME.html
"""
def replace(self, text, *pairs):
"""
From pydoc... almost identical at least
"""
while pairs:
(a, b) = pairs[0]
text = join(split(text, a), b)
pairs = pairs[1:]
return text
def escape(self, text):
"""
Escape string to be conform HTML
"""
return self.replace(text,
('&', '&amp;'),
('<', '&lt;' ),
('>', '&gt;' ) )
def createNavigator(self):
"""
Create the navgiator
"""
return """<table class="navigation" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2">
<tr valign="middle">
<td><a accesskey="g" href="index.html">Home</a></td>
<td><a accesskey="n" href="all_groups.html">Groups</a></td>
<td><a accesskey="u" href="all_keys.html">Keys</a></td>
</tr></table>
"""
def relatedKeys(self, item):
"""
Create HTML to link to foreign keys
"""
if len(item.related()) == 0:
return ""
txt = "<p><b>See also:</b><br>"
txts = []
for it in item.related():
txts.append("""<a href="key%(it)s.html">%(it)s</a>""" % vars() )
return txt + ",".join(txts)
def groups(self, item):
"""
Create HTML to link to related groups
"""
if len(item.groups()) == 0:
return ""
txt = "<p><b>See also:</b><br>"
txts = []
for group in item.groups():
txts.append( """<a href="group%s.html">%s</a> """ % (group, group) )
return txt + ",".join(txts)
def createKeySite(self, item):
"""
Create a site for a key. It contains the header/navigator, a heading,
the description, links to related keys and to the groups.
"""
return """<!doctype html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Key %s</title></head>
<link rel="stylesheet" href="style.css" type="text/css">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
%s
<h2><span class="refentrytitle">%s</span></h2>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<p>
%s
</p>
</div>
<div class="refsynopsisdiv">
<h2>Related Keys</h2>
<p>
%s
</p>
</div>
<div class="refsynopsisdiv">
<h2>Groups</h2>
<p>
%s
</p>
</div>
</body>
""" % (item.name(), self.createNavigator(), item.name(),
self.escape(item.description()), self.relatedKeys(item), self.groups(item))
def createGroupsSite(self, doc):
"""
Create the Group Overview site
"""
groups = ""
sorted_groups = sorted(doc.groups())
for group in sorted_groups:
groups += """<a href="group%s.html">%s</a><br>""" % (group, group)
return """<!doctype html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Group overview</title></head>
<link rel="stylesheet" href="style.css" type="text/css">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
%s
<h2>Available Groups</h2>
%s
</body>
""" % (self.createNavigator(), groups)
def createIndex(self):
"""
Create the index file
"""
return """<!doctype html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Bitbake Documentation</title></head>
<link rel="stylesheet" href="style.css" type="text/css">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
%s
<h2>Documentation Entrance</h2>
<a href="all_groups.html">All available groups</a><br>
<a href="all_keys.html">All available keys</a><br>
</body>
""" % self.createNavigator()
def createKeysSite(self, doc):
"""
Create Overview of all avilable keys
"""
keys = ""
sorted_keys = sorted(doc.doc_keys())
for key in sorted_keys:
keys += """<a href="key%s.html">%s</a><br>""" % (key, key)
return """<!doctype html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Key overview</title></head>
<link rel="stylesheet" href="style.css" type="text/css">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
%s
<h2>Available Keys</h2>
%s
</body>
""" % (self.createNavigator(), keys)
def createGroupSite(self, gr, items, _description = None):
"""
Create a site for a group:
Group the name of the group, items contain the name of the keys
inside this group
"""
groups = ""
description = ""
# create a section with the group descriptions
if _description:
description += "<h2 Description of Grozp %s</h2>" % gr
description += _description
items.sort(lambda x, y:cmp(x.name(), y.name()))
for group in items:
groups += """<a href="key%s.html">%s</a><br>""" % (group.name(), group.name())
return """<!doctype html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Group %s</title></head>
<link rel="stylesheet" href="style.css" type="text/css">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
%s
%s
<div class="refsynopsisdiv">
<h2>Keys in Group %s</h2>
<pre class="synopsis">
%s
</pre>
</div>
</body>
""" % (gr, self.createNavigator(), description, gr, groups)
def createCSS(self):
"""
Create the CSS file
"""
return """.synopsis, .classsynopsis
{
background: #eeeeee;
border: solid 1px #aaaaaa;
padding: 0.5em;
}
.programlisting
{
background: #eeeeff;
border: solid 1px #aaaaff;
padding: 0.5em;
}
.variablelist
{
padding: 4px;
margin-left: 3em;
}
.variablelist td:first-child
{
vertical-align: top;
}
table.navigation
{
background: #ffeeee;
border: solid 1px #ffaaaa;
margin-top: 0.5em;
margin-bottom: 0.5em;
}
.navigation a
{
color: #770000;
}
.navigation a:visited
{
color: #550000;
}
.navigation .title
{
font-size: 200%;
}
div.refnamediv
{
margin-top: 2em;
}
div.gallery-float
{
float: left;
padding: 10px;
}
div.gallery-float img
{
border-style: none;
}
div.gallery-spacer
{
clear: both;
}
a
{
text-decoration: none;
}
a:hover
{
text-decoration: underline;
color: #FF0000;
}
"""
class DocumentationItem:
"""
A class to hold information about a configuration
item. It contains the key name, description, a list of related names,
and the group this item is contained in.
"""
def __init__(self):
self._groups = []
self._related = []
self._name = ""
self._desc = ""
def groups(self):
return self._groups
def name(self):
return self._name
def description(self):
return self._desc
def related(self):
return self._related
def setName(self, name):
self._name = name
def setDescription(self, desc):
self._desc = desc
def addGroup(self, group):
self._groups.append(group)
def addRelation(self, relation):
self._related.append(relation)
def sort(self):
self._related.sort()
self._groups.sort()
class Documentation:
"""
Holds the documentation... with mappings from key to items...
"""
def __init__(self):
self.__keys = {}
self.__groups = {}
def insert_doc_item(self, item):
"""
Insert the Doc Item into the internal list
of representation
"""
item.sort()
self.__keys[item.name()] = item
for group in item.groups():
if not group in self.__groups:
self.__groups[group] = []
self.__groups[group].append(item)
self.__groups[group].sort()
def doc_item(self, key):
"""
Return the DocumentationInstance describing the key
"""
try:
return self.__keys[key]
except KeyError:
return None
def doc_keys(self):
"""
Return the documented KEYS (names)
"""
return self.__keys.keys()
def groups(self):
"""
Return the names of available groups
"""
return self.__groups.keys()
def group_content(self, group_name):
"""
Return a list of keys/names that are in a specefic
group or the empty list
"""
try:
return self.__groups[group_name]
except KeyError:
return []
def parse_cmdline(args):
"""
Parse the CMD line and return the result as a n-tuple
"""
parser = optparse.OptionParser( version = "Bitbake Documentation Tool Core version %s, %%prog version %s" % (bb.__version__, __version__))
usage = """%prog [options]
Create a set of html pages (documentation) for a bitbake.conf....
"""
# Add the needed options
parser.add_option( "-c", "--config", help = "Use the specified configuration file as source",
action = "store", dest = "config", default = os.path.join("conf", "documentation.conf") )
parser.add_option( "-o", "--output", help = "Output directory for html files",
action = "store", dest = "output", default = "html/" )
parser.add_option( "-D", "--debug", help = "Increase the debug level",
action = "count", dest = "debug", default = 0 )
parser.add_option( "-v", "--verbose", help = "output more chit-char to the terminal",
action = "store_true", dest = "verbose", default = False )
options, args = parser.parse_args( sys.argv )
bb.msg.init_msgconfig(options.verbose, options.debug)
return options.config, options.output
def main():
"""
The main Method
"""
(config_file, output_dir) = parse_cmdline( sys.argv )
# right to let us load the file now
try:
documentation = bb.parse.handle( config_file, bb.data.init() )
except IOError:
bb.fatal( "Unable to open %s" % config_file )
except bb.parse.ParseError:
bb.fatal( "Unable to parse %s" % config_file )
if isinstance(documentation, dict):
documentation = documentation[""]
# Assuming we've the file loaded now, we will initialize the 'tree'
doc = Documentation()
# defined states
state_begin = 0
state_see = 1
state_group = 2
for key in bb.data.keys(documentation):
data = documentation.getVarFlag(key, "doc")
if not data:
continue
# The Documentation now starts
doc_ins = DocumentationItem()
doc_ins.setName(key)
tokens = data.split(' ')
state = state_begin
string= ""
for token in tokens:
token = token.strip(',')
if not state == state_see and token == "@see":
state = state_see
continue
elif not state == state_group and token == "@group":
state = state_group
continue
if state == state_begin:
string += " %s" % token
elif state == state_see:
doc_ins.addRelation(token)
elif state == state_group:
doc_ins.addGroup(token)
# set the description
doc_ins.setDescription(string)
doc.insert_doc_item(doc_ins)
# let us create the HTML now
bb.utils.mkdirhier(output_dir)
os.chdir(output_dir)
# Let us create the sites now. We do it in the following order
# Start with the index.html. It will point to sites explaining all
# keys and groups
html_slave = HTMLFormatter()
f = file('style.css', 'w')
print >> f, html_slave.createCSS()
f = file('index.html', 'w')
print >> f, html_slave.createIndex()
f = file('all_groups.html', 'w')
print >> f, html_slave.createGroupsSite(doc)
f = file('all_keys.html', 'w')
print >> f, html_slave.createKeysSite(doc)
# now for each group create the site
for group in doc.groups():
f = file('group%s.html' % group, 'w')
print >> f, html_slave.createGroupSite(group, doc.group_content(group))
# now for the keys
for key in doc.doc_keys():
f = file('key%s.html' % doc.doc_item(key).name(), 'w')
print >> f, html_slave.createKeySite(doc.doc_item(key))
if __name__ == "__main__":
main()

View File

@@ -1,171 +0,0 @@
#!/usr/bin/env python3
#
# SPDX-License-Identifier: GPL-2.0-only
#
"""git-make-shallow: make the current git repository shallow
Remove the history of the specified revisions, then optionally filter the
available refs to those specified.
"""
import argparse
import collections
import errno
import itertools
import os
import subprocess
import sys
import warnings
warnings.simplefilter("default")
version = 1.0
def main():
if sys.version_info < (3, 4, 0):
sys.exit('Python 3.4 or greater is required')
git_dir = check_output(['git', 'rev-parse', '--git-dir']).rstrip()
shallow_file = os.path.join(git_dir, 'shallow')
if os.path.exists(shallow_file):
try:
check_output(['git', 'fetch', '--unshallow'])
except subprocess.CalledProcessError:
try:
os.unlink(shallow_file)
except OSError as exc:
if exc.errno != errno.ENOENT:
raise
args = process_args()
revs = check_output(['git', 'rev-list'] + args.revisions).splitlines()
make_shallow(shallow_file, args.revisions, args.refs)
ref_revs = check_output(['git', 'rev-list'] + args.refs).splitlines()
remaining_history = set(revs) & set(ref_revs)
for rev in remaining_history:
if check_output(['git', 'rev-parse', '{}^@'.format(rev)]):
sys.exit('Error: %s was not made shallow' % rev)
filter_refs(args.refs)
if args.shrink:
shrink_repo(git_dir)
subprocess.check_call(['git', 'fsck', '--unreachable'])
def process_args():
# TODO: add argument to automatically keep local-only refs, since they
# can't be easily restored with a git fetch.
parser = argparse.ArgumentParser(description='Remove the history of the specified revisions, then optionally filter the available refs to those specified.')
parser.add_argument('--ref', '-r', metavar='REF', action='append', dest='refs', help='remove all but the specified refs (cumulative)')
parser.add_argument('--shrink', '-s', action='store_true', help='shrink the git repository by repacking and pruning')
parser.add_argument('revisions', metavar='REVISION', nargs='+', help='a git revision/commit')
if len(sys.argv) < 2:
parser.print_help()
sys.exit(2)
args = parser.parse_args()
if args.refs:
args.refs = check_output(['git', 'rev-parse', '--symbolic-full-name'] + args.refs).splitlines()
else:
args.refs = get_all_refs(lambda r, t, tt: t == 'commit' or tt == 'commit')
args.refs = list(filter(lambda r: not r.endswith('/HEAD'), args.refs))
args.revisions = check_output(['git', 'rev-parse'] + ['%s^{}' % i for i in args.revisions]).splitlines()
return args
def check_output(cmd, input=None):
return subprocess.check_output(cmd, universal_newlines=True, input=input)
def make_shallow(shallow_file, revisions, refs):
"""Remove the history of the specified revisions."""
for rev in follow_history_intersections(revisions, refs):
print("Processing %s" % rev)
with open(shallow_file, 'a') as f:
f.write(rev + '\n')
def get_all_refs(ref_filter=None):
"""Return all the existing refs in this repository, optionally filtering the refs."""
ref_output = check_output(['git', 'for-each-ref', '--format=%(refname)\t%(objecttype)\t%(*objecttype)'])
ref_split = [tuple(iter_extend(l.rsplit('\t'), 3)) for l in ref_output.splitlines()]
if ref_filter:
ref_split = (e for e in ref_split if ref_filter(*e))
refs = [r[0] for r in ref_split]
return refs
def iter_extend(iterable, length, obj=None):
"""Ensure that iterable is the specified length by extending with obj."""
return itertools.islice(itertools.chain(iterable, itertools.repeat(obj)), length)
def filter_refs(refs):
"""Remove all but the specified refs from the git repository."""
all_refs = get_all_refs()
to_remove = set(all_refs) - set(refs)
if to_remove:
check_output(['xargs', '-0', '-n', '1', 'git', 'update-ref', '-d', '--no-deref'],
input=''.join(l + '\0' for l in to_remove))
def follow_history_intersections(revisions, refs):
"""Determine all the points where the history of the specified revisions intersects the specified refs."""
queue = collections.deque(revisions)
seen = set()
for rev in iter_except(queue.popleft, IndexError):
if rev in seen:
continue
parents = check_output(['git', 'rev-parse', '%s^@' % rev]).splitlines()
yield rev
seen.add(rev)
if not parents:
continue
check_refs = check_output(['git', 'merge-base', '--independent'] + sorted(refs)).splitlines()
for parent in parents:
for ref in check_refs:
print("Checking %s vs %s" % (parent, ref))
try:
merge_base = check_output(['git', 'merge-base', parent, ref]).rstrip()
except subprocess.CalledProcessError:
continue
else:
queue.append(merge_base)
def iter_except(func, exception, start=None):
"""Yield a function repeatedly until it raises an exception."""
try:
if start is not None:
yield start()
while True:
yield func()
except exception:
pass
def shrink_repo(git_dir):
"""Shrink the newly shallow repository, removing the unreachable objects."""
subprocess.check_call(['git', 'reflog', 'expire', '--expire-unreachable=now', '--all'])
subprocess.check_call(['git', 'repack', '-ad'])
try:
os.unlink(os.path.join(git_dir, 'objects', 'info', 'alternates'))
except OSError as exc:
if exc.errno != errno.ENOENT:
raise
subprocess.check_call(['git', 'prune', '--expire', 'now'])
if __name__ == '__main__':
main()

122
bitbake/bin/image-writer Executable file
View File

@@ -0,0 +1,122 @@
#!/usr/bin/env python
# Copyright (c) 2012 Wind River Systems, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
import os
import sys
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname( \
os.path.abspath(__file__))), 'lib'))
try:
import bb
except RuntimeError as exc:
sys.exit(str(exc))
import gtk
import optparse
import pygtk
from bb.ui.crumbs.hobwidget import HobAltButton, HobButton
from bb.ui.crumbs.hig.crumbsmessagedialog import CrumbsMessageDialog
from bb.ui.crumbs.hig.deployimagedialog import DeployImageDialog
from bb.ui.crumbs.hig.imageselectiondialog import ImageSelectionDialog
# I put all the fs bitbake supported here. Need more test.
DEPLOYABLE_IMAGE_TYPES = ["jffs2", "cramfs", "ext2", "ext3", "btrfs", "squashfs", "ubi", "vmdk"]
Title = "USB Image Writer"
class DeployWindow(gtk.Window):
def __init__(self, image_path=''):
super(DeployWindow, self).__init__()
if len(image_path) > 0:
valid = True
if not os.path.exists(image_path):
valid = False
lbl = "<b>Invalid image file path: %s.</b>\nPress <b>Select Image</b> to select an image." % image_path
else:
image_path = os.path.abspath(image_path)
extend_name = os.path.splitext(image_path)[1][1:]
if extend_name not in DEPLOYABLE_IMAGE_TYPES:
valid = False
lbl = "<b>Undeployable imge type: %s</b>\nPress <b>Select Image</b> to select an image." % extend_name
if not valid:
image_path = ''
crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
HobButton.style_button(button)
crumbs_dialog.run()
crumbs_dialog.destroy()
self.deploy_dialog = DeployImageDialog(Title, image_path, self,
gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT
| gtk.DIALOG_NO_SEPARATOR, None, standalone=True)
close_button = self.deploy_dialog.add_button("Close", gtk.RESPONSE_NO)
HobAltButton.style_button(close_button)
close_button.connect('clicked', gtk.main_quit)
write_button = self.deploy_dialog.add_button("Write USB image", gtk.RESPONSE_YES)
HobAltButton.style_button(write_button)
self.deploy_dialog.connect('select_image_clicked', self.select_image_clicked_cb)
self.deploy_dialog.connect('destroy', gtk.main_quit)
response = self.deploy_dialog.show()
def select_image_clicked_cb(self, dialog):
cwd = os.getcwd()
dialog = ImageSelectionDialog(cwd, DEPLOYABLE_IMAGE_TYPES, Title, self, gtk.FILE_CHOOSER_ACTION_SAVE )
button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
HobAltButton.style_button(button)
button = dialog.add_button("Open", gtk.RESPONSE_YES)
HobAltButton.style_button(button)
response = dialog.run()
if response == gtk.RESPONSE_YES:
if not dialog.image_names:
lbl = "<b>No selections made</b>\nClicked the radio button to select a image."
crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
HobButton.style_button(button)
crumbs_dialog.run()
crumbs_dialog.destroy()
dialog.destroy()
return
# get the full path of image
image_path = os.path.join(dialog.image_folder, dialog.image_names[0])
self.deploy_dialog.set_image_text_buffer(image_path)
self.deploy_dialog.set_image_path(image_path)
dialog.destroy()
def main():
parser = optparse.OptionParser(
usage = """%prog [-h] [image_file]
%prog writes bootable images to USB devices. You can
provide the image file on the command line or select it using the GUI.""")
options, args = parser.parse_args(sys.argv)
image_file = args[1] if len(args) > 1 else ''
dw = DeployWindow(image_file)
if __name__ == '__main__':
try:
main()
gtk.main()
except Exception:
import traceback
traceback.print_exc(3)

View File

@@ -1,324 +1,214 @@
#!/bin/echo ERROR: This script needs to be sourced. Please run as .
#!/bin/bash
# (c) 2013 Intel Corp.
# toaster - shell script to start Toaster
# Copyright (C) 2013-2015 Intel Corp.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# SPDX-License-Identifier: GPL-2.0-or-later
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
HELP="
Usage 1: source toaster start|stop [webport=<address:port>] [noweb] [nobuild] [toasterdir]
Optional arguments:
[nobuild] Setup the environment for capturing builds with toaster but disable managed builds
[noweb] Setup the environment for capturing builds with toaster but don't start the web server
[webport] Set the development server (default: localhost:8000)
[toasterdir] Set absolute path to be used as TOASTER_DIR (default: BUILDDIR/../)
Usage 2: source toaster manage [createsuperuser|lsupdates|migrate|makemigrations|checksettings|collectstatic|...]
"
custom_extention()
# This script enables toaster event logging and
# starts bitbake resident server
# use as: source toaster [start|stop]
# Helper function to kill a background toaster development server
function webserverKillAll()
{
custom_extension=$BBBASEDIR/lib/toaster/orm/fixtures/custom_toaster_append.sh
if [ -f $custom_extension ] ; then
$custom_extension $*
fi
local pidfile
for pidfile in ${BUILDDIR}/.toastermain.pid; do
if [ -f ${pidfile} ]; then
while kill -0 $(< ${pidfile}) 2>/dev/null; do
kill -SIGTERM -$(< ${pidfile}) 2>/dev/null
sleep 1;
done;
rm ${pidfile}
fi
done
}
databaseCheck()
function webserverStartAll()
{
retval=0
# you can always add a superuser later via
# ../bitbake/lib/toaster/manage.py createsuperuser --username=<ME>
$MANAGE migrate --noinput || retval=1
if [ $retval -eq 1 ]; then
echo "Failed migrations, aborting system start" 1>&2
return $retval
fi
# Make sure that checksettings can pick up any value for TEMPLATECONF
export TEMPLATECONF
$MANAGE checksettings --traceback || retval=1
if [ $retval -eq 1 ]; then
printf "\nError while checking settings; aborting\n"
return $retval
fi
return $retval
}
webserverKillAll()
{
local pidfile
if [ -f ${BUILDDIR}/.toastermain.pid ] ; then
custom_extention web_stop_postpend
else
custom_extention noweb_stop_postpend
fi
for pidfile in ${BUILDDIR}/.toastermain.pid ${BUILDDIR}/.runbuilds.pid; do
if [ -f ${pidfile} ]; then
pid=`cat ${pidfile}`
while kill -0 $pid 2>/dev/null; do
kill -SIGTERM $pid 2>/dev/null
sleep 1
done
rm ${pidfile}
retval=0
python $BBBASEDIR/lib/toaster/manage.py syncdb || retval=1
python $BBBASEDIR/lib/toaster/manage.py migrate orm || retval=2
if [ $retval -eq 1 ]; then
echo "Failed db sync, stopping system start" 1>&2
elif [ $retval -eq 2 ]; then
echo -e "\nError on migration, trying to recover... \n"
python $BBBASEDIR/lib/toaster/manage.py migrate orm 0001_initial --fake
retval=0
python $BBBASEDIR/lib/toaster/manage.py migrate orm || retval=1
fi
done
if [ $retval -eq 0 ]; then
python $BBBASEDIR/lib/toaster/manage.py runserver 0.0.0.0:8000 </dev/null >${BUILDDIR}/toaster_web.log 2>&1 & echo $! >${BUILDDIR}/.toastermain.pid
sleep 1
if ! cat "${BUILDDIR}/.toastermain.pid" | xargs -I{} kill -0 {} ; then
retval=1
rm "${BUILDDIR}/.toastermain.pid"
fi
fi
return $retval
}
webserverStartAll()
# Helper functions to add a special configuration file
function addtoConfiguration()
{
# do not start if toastermain points to a valid process
if ! cat "${BUILDDIR}/.toastermain.pid" 2>/dev/null | xargs -I{} kill -0 {} ; then
retval=1
rm "${BUILDDIR}/.toastermain.pid"
fi
retval=0
# check the database
databaseCheck || return 1
echo "Starting webserver..."
$MANAGE runserver --noreload "$ADDR_PORT" \
</dev/null >>${BUILDDIR}/toaster_web.log 2>&1 \
& echo $! >${BUILDDIR}/.toastermain.pid
sleep 1
if ! cat "${BUILDDIR}/.toastermain.pid" | xargs -I{} kill -0 {} ; then
retval=1
rm "${BUILDDIR}/.toastermain.pid"
else
echo "Toaster development webserver started at http://$ADDR_PORT"
echo -e "\nYou can now run 'bitbake <target>' on the command line and monitor your build in Toaster.\nYou can also use a Toaster project to configure and run a build.\n"
custom_extention web_start_postpend $ADDR_PORT
fi
return $retval
echo "#Created by toaster start script" > ${BUILDDIR}/conf/$2
echo $1 >> ${BUILDDIR}/conf/$2
}
INSTOPSYSTEM=0
# define the stop command
stop_system()
function stop_system()
{
# prevent reentry
if [ $INSTOPSYSTEM -eq 1 ]; then return; fi
if [ $INSTOPSYSTEM == 1 ]; then return; fi
INSTOPSYSTEM=1
if [ -f ${BUILDDIR}/.toasterui.pid ]; then
kill $(< ${BUILDDIR}/.toasterui.pid ) 2>/dev/null
rm ${BUILDDIR}/.toasterui.pid
fi
BBSERVER=localhost:8200 bitbake -m
unset BBSERVER
webserverKillAll
# unset exported variables
unset TOASTER_DIR
unset BITBAKE_UI
unset BBBASEDIR
# force stop any misbehaving bitbake server
lsof bitbake.lock | awk '{print $2}' | grep "[0-9]\+" | xargs -n1 -r kill
trap - SIGHUP
#trap - SIGCHLD
INSTOPSYSTEM=0
}
verify_prereq() {
# Verify Django version
reqfile=$(python3 -c "import os; print(os.path.realpath('$BBBASEDIR/toaster-requirements.txt'))")
exp='s/Django\([><=]\+\)\([^,]\+\),\([><=]\+\)\(.\+\)/'
# expand version parts to 2 digits to support 1.10.x > 1.8
# (note:helper functions hard to insert in-line)
exp=$exp'import sys,django;'
exp=$exp'version=["%02d" % int(n) for n in django.get_version().split(".")];'
exp=$exp'vmin=["%02d" % int(n) for n in "\2".split(".")];'
exp=$exp'vmax=["%02d" % int(n) for n in "\4".split(".")];'
exp=$exp'sys.exit(not (version \1 vmin and version \3 vmax))'
exp=$exp'/p'
if ! sed -n "$exp" $reqfile | python3 - ; then
req=`grep ^Django $reqfile`
echo "This program needs $req"
echo "Please install with pip3 install -r $reqfile"
return 2
fi
return 0
function check_pidbyfile() {
[ -e $1 ] && kill -0 $(< $1) 2>/dev/null
}
# read command line parameters
if [ -n "$BASH_SOURCE" ] ; then
TOASTER=${BASH_SOURCE}
elif [ -n "$ZSH_NAME" ] ; then
TOASTER=${(%):-%x}
else
TOASTER=$0
fi
export BBBASEDIR=`dirname $TOASTER`/..
MANAGE="python3 $BBBASEDIR/lib/toaster/manage.py"
if [ -z "$OE_ROOT" ]; then
OE_ROOT=`dirname $TOASTER`/../..
fi
# this is the configuraton file we are using for toaster
# we are using the same logic that oe-setup-builddir uses
# (based on TEMPLATECONF and .templateconf) to determine
# which toasterconf.json to use.
# note: There are a number of relative path assumptions
# in the local layers that currently make using an arbitrary
# toasterconf.json difficult.
. $OE_ROOT/.templateconf
if [ -n "$TEMPLATECONF" ]; then
if [ ! -d "$TEMPLATECONF" ]; then
# Allow TEMPLATECONF=meta-xyz/conf as a shortcut
if [ -d "$OE_ROOT/$TEMPLATECONF" ]; then
TEMPLATECONF="$OE_ROOT/$TEMPLATECONF"
fi
function notify_chldexit() {
if [ $NOTOASTERUI == 0 ]; then
check_pidbyfile ${BUILDDIR}/.toasterui.pid && return
stop_system
fi
fi
}
unset OE_ROOT
WEBSERVER=1
export TOASTER_BUILDSERVER=1
ADDR_PORT="localhost:8000"
TOASTERDIR=`dirname $BUILDDIR`
unset CMD
for param in $*; do
case $param in
noweb )
WEBSERVER=0
;;
nobuild )
TOASTER_BUILDSERVER=0
;;
start )
CMD=$param
;;
stop )
CMD=$param
;;
webport=*)
ADDR_PORT="${param#*=}"
# Split the addr:port string
ADDR=`echo $ADDR_PORT | cut -f 1 -d ':'`
PORT=`echo $ADDR_PORT | cut -f 2 -d ':'`
# If only a port has been speified then set address to localhost.
if [ $ADDR = $PORT ] ; then
ADDR_PORT="localhost:$PORT"
fi
;;
toasterdir=*)
TOASTERDIR="${param#*=}"
;;
manage )
CMD=$param
manage_cmd=""
;;
--help)
echo "$HELP"
return 0
;;
*)
if [ "manage" == "$CMD" ] ; then
manage_cmd="$manage_cmd $param"
else
echo "$HELP"
exit 1
fi
;;
esac
done
if [ `basename \"$0\"` = `basename \"${TOASTER}\"` ]; then
echo "Error: This script needs to be sourced. Please run as . $TOASTER"
return 1
fi
verify_prereq || return 1
# We make sure we're running in the current shell and in a good environment
if [ -z "$BUILDDIR" ] || ! which bitbake >/dev/null 2>&1 ; then
echo "Error: Build environment is not setup or bitbake is not in path." 1>&2
if [ -z "$ZSH_NAME" ] && [ `basename \"$0\"` = `basename \"$BASH_SOURCE\"` ]; then
echo "Error: This script needs to be sourced. Please run as 'source toaster [start|stop]'" 1>&2;
exit 1
fi
if [ -z "$BUILDDIR" ] || [ -z `which bitbake` ]; then
echo "Error: Build environment is not setup or bitbake is not in path." 1>&2;
return 2
fi
# this defines the dir toaster will use for
# 1) clones of layers (in _toaster_clones )
# 2) the build dir (in build)
# 3) the sqlite db if that is being used.
# 4) pid's we need to clean up on exit/shutdown
export TOASTER_DIR=$TOASTERDIR
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE TOASTER_DIR"
BBBASEDIR=`dirname ${BASH_SOURCE}`/..
# Verify prerequisites
if ! echo "import django; print (1,5) == django.VERSION[0:2]" | python 2>/dev/null | grep True >/dev/null; then
echo -e "This program needs Django 1.5. Please install with\n\nsudo pip install django==1.5"
return 2
fi
if ! echo "import south; print [0,8,4] == map(int,south.__version__.split(\".\"))" | python 2>/dev/null | grep True >/dev/null; then
echo -e "This program needs South 0.8.4. Please install with\n\nsudo pip install south==0.8.4"
return 2
fi
# Determine the action. If specified by arguments, fine, if not, toggle it
if [ "$CMD" = "start" ] ; then
if [ -n "$BBSERVER" ]; then
echo " Toaster is already running. Exiting..."
return 1
fi
elif [ "$CMD" = "" ]; then
echo "No command specified"
echo "$HELP"
return 1
if [ "x$1" == "xstart" ] || [ "x$1" == "xstop" ]; then
CMD="$1"
else
if [ -z "$BBSERVER" ]; then
CMD="start"
else
CMD="stop"
fi;
fi
NOTOASTERUI=0
for param in $*; do
case $param in
noui )
NOTOASTERUI=1
;;
esac
done
echo "The system will $CMD."
# Make sure it's safe to run by checking bitbake lock
lock=1
if [ -e $BUILDDIR/bitbake.lock ]; then
(flock -n 200 ) 200<$BUILDDIR/bitbake.lock || lock=0
fi
if [ ${CMD} == "start" ] && ( [ $lock -eq 0 ] || [ -e $BUILDDIR/.toastermain.pid ] ); then
echo "Error: bitbake lock state error. File locks show that the system is on." 2>&1
echo "If you see problems, stop and then start the system again." 2>&1
return 3
fi
# Execute the commands
custom_extention toaster_prepend $CMD $ADDR_PORT
case $CMD in
start )
# check if addr:port is not in use
if [ "$CMD" == 'start' ]; then
if [ $WEBSERVER -gt 0 ]; then
$MANAGE checksocket "$ADDR_PORT" || return 1
fi
fi
# Create configuration file
conf=${BUILDDIR}/conf/local.conf
line='INHERIT+="toaster buildhistory"'
grep -q "$line" $conf || echo $line >> $conf
if [ $WEBSERVER -eq 0 ] ; then
# Do not update the database for "noweb" unless
# it does not yet exist
if [ ! -f "$TOASTER_DIR/toaster.sqlite" ] ; then
if ! databaseCheck; then
echo "Failed ${CMD}."
return 4
fi
fi
custom_extention noweb_start_postpend $ADDR_PORT
fi
if [ $WEBSERVER -gt 0 ] && ! webserverStartAll; then
start_success=1
addtoConfiguration "INHERIT+=\"toaster buildhistory\"" toaster.conf
if ! webserverStartAll; then
echo "Failed ${CMD}."
return 4
fi
export BITBAKE_UI='toasterui'
if [ $TOASTER_BUILDSERVER -eq 1 ] ; then
$MANAGE runbuilds \
</dev/null >>${BUILDDIR}/toaster_runbuilds.log 2>&1 \
& echo $! >${BUILDDIR}/.runbuilds.pid
unset BBSERVER
bitbake --postread conf/toaster.conf --server-only -t xmlrpc -B localhost:8200
if [ $? -ne 0 ]; then
start_success=0
echo "Bitbake server start failed"
else
echo "Toaster build server not started."
export BBSERVER=localhost:8200
if [ $NOTOASTERUI == 0 ]; then # we start the TOASTERUI only if not inhibited
bitbake --observe-only -u toasterui >${BUILDDIR}/toaster_ui.log 2>&1 & echo $! >${BUILDDIR}/.toasterui.pid
fi
fi
# set fail safe stop system on terminal exit
if [ $start_success -eq 1 ]; then
# set fail safe stop system on terminal exit
trap stop_system SIGHUP
echo "Successful ${CMD}."
else
# failed start, do stop
stop_system
echo "Failed ${CMD}."
fi
# stop system on terminal exit
set -o monitor
trap stop_system SIGHUP
echo "Successful ${CMD}."
custom_extention toaster_postpend $CMD $ADDR_PORT
return 0
#trap notify_chldexit SIGCHLD
;;
stop )
stop_system
echo "Successful ${CMD}."
;;
manage )
cd $BBBASEDIR/lib/toaster
$MANAGE $manage_cmd
;;
esac
custom_extention toaster_postpend $CMD $ADDR_PORT

View File

@@ -1,115 +0,0 @@
#!/usr/bin/env python3
#
# Copyright (C) 2014 Alex Damian
#
# SPDX-License-Identifier: GPL-2.0-only
#
# This file re-uses code spread throughout other Bitbake source files.
# As such, all other copyrights belong to their own right holders.
#
"""
This command takes a filename as a single parameter. The filename is read
as a build eventlog, and the ToasterUI is used to process events in the file
and log data in the database
"""
import os
import sys
import json
import pickle
import codecs
import warnings
warnings.simplefilter("default")
from collections import namedtuple
# mangle syspath to allow easy import of modules
from os.path import join, dirname, abspath
sys.path.insert(0, join(dirname(dirname(abspath(__file__))), 'lib'))
import bb.cooker
from bb.ui import toasterui
class EventPlayer:
"""Emulate a connection to a bitbake server."""
def __init__(self, eventfile, variables):
self.eventfile = eventfile
self.variables = variables
self.eventmask = []
def waitEvent(self, _timeout):
"""Read event from the file."""
line = self.eventfile.readline().strip()
if not line:
return
try:
event_str = json.loads(line)['vars'].encode('utf-8')
event = pickle.loads(codecs.decode(event_str, 'base64'))
event_name = "%s.%s" % (event.__module__, event.__class__.__name__)
if event_name not in self.eventmask:
return
return event
except ValueError as err:
print("Failed loading ", line)
raise err
def runCommand(self, command_line):
"""Emulate running a command on the server."""
name = command_line[0]
if name == "getVariable":
var_name = command_line[1]
variable = self.variables.get(var_name)
if variable:
return variable['v'], None
return None, "Missing variable %s" % var_name
elif name == "getAllKeysWithFlags":
dump = {}
flaglist = command_line[1]
for key, val in self.variables.items():
try:
if not key.startswith("__"):
dump[key] = {
'v': val['v'],
'history' : val['history'],
}
for flag in flaglist:
dump[key][flag] = val[flag]
except Exception as err:
print(err)
return (dump, None)
elif name == 'setEventMask':
self.eventmask = command_line[-1]
return True, None
else:
raise Exception("Command %s not implemented" % command_line[0])
def getEventHandle(self):
"""
This method is called by toasterui.
The return value is passed to self.runCommand but not used there.
"""
pass
def main(argv):
with open(argv[-1]) as eventfile:
# load variables from the first line
variables = json.loads(eventfile.readline().strip())['allvariables']
params = namedtuple('ConfigParams', ['observe_only'])(True)
player = EventPlayer(eventfile, variables)
return toasterui.main(player, player, params)
# run toaster ui on our mock bitbake class
if __name__ == "__main__":
if len(sys.argv) != 2:
print("Usage: %s <event file>" % os.path.basename(sys.argv[0]))
sys.exit(1)
sys.exit(main(sys.argv))

View File

@@ -1,13 +0,0 @@
{
"version": 1,
"loggers": {
"BitBake.SigGen.HashEquiv": {
"level": "VERBOSE",
"handlers": ["BitBake.verbconsole"]
},
"BitBake.RunQueue.HashEquiv": {
"level": "VERBOSE",
"handlers": ["BitBake.verbconsole"]
}
}
}

View File

@@ -1,89 +0,0 @@
#! /usr/bin/env python3
#
# Copyright (C) 2020 Joshua Watt <JPEWhacker@gmail.com>
#
# SPDX-License-Identifier: MIT
import argparse
import os
import random
import shutil
import signal
import subprocess
import sys
import time
def try_unlink(path):
try:
os.unlink(path)
except:
pass
def main():
def cleanup():
shutil.rmtree("tmp/cache", ignore_errors=True)
try_unlink("bitbake-cookerdaemon.log")
try_unlink("bitbake.sock")
try_unlink("bitbake.lock")
parser = argparse.ArgumentParser(
description="Bitbake parser torture test",
epilog="""
A torture test for bitbake's parser. Repeatedly interrupts parsing until
bitbake decides to deadlock.
""",
)
args = parser.parse_args()
if not "BUILDDIR" in os.environ:
print(
"'BUILDDIR' not found in the environment. Did you initialize the build environment?"
)
return 1
os.chdir(os.environ["BUILDDIR"])
run_num = 0
while True:
if run_num % 100 == 0:
print("Calibrating wait time...")
cleanup()
start_time = time.monotonic()
r = subprocess.run(["bitbake", "-p"])
max_wait_time = time.monotonic() - start_time
if r.returncode != 0:
print("Calibration run exited with %d" % r.returncode)
return 1
print("Maximum wait time is %f seconds" % max_wait_time)
run_num += 1
wait_time = random.random() * max_wait_time
print("Run #%d" % run_num)
print("Will sleep for %f seconds" % wait_time)
cleanup()
with subprocess.Popen(["bitbake", "-p"]) as proc:
time.sleep(wait_time)
proc.send_signal(signal.SIGINT)
try:
proc.wait(45)
except subprocess.TimeoutExpired:
print("Run #%d: Waited too long. Possible deadlock!" % run_num)
proc.wait()
return 1
if proc.returncode == 0:
print("Exited successfully. Timeout too long?")
else:
print("Exited with %d" % proc.returncode)
if __name__ == "__main__":
sys.exit(main())

View File

@@ -1,6 +1,8 @@
#!/usr/bin/env python3
#!/usr/bin/env python
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# Copyright (C) 2012, 2018 Wind River Systems, Inc.
# Copyright (C) 2012 Wind River Systems, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
@@ -16,68 +18,51 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# Used for dumping the bb_cache.dat
# This is used for dumping the bb_cache.dat, the output format is:
# recipe_path PN PV PACKAGES
#
import os
import sys
import argparse
import warnings
# For importing bb.cache
sys.path.insert(0, os.path.join(os.path.abspath(os.path.dirname(sys.argv[0])), '../lib'))
from bb.cache import CoreRecipeInfo
import pickle
import cPickle as pickle
class DumpCache(object):
def __init__(self):
parser = argparse.ArgumentParser(
description="bb_cache.dat's dumper",
epilog="Use %(prog)s --help to get help")
parser.add_argument("-r", "--recipe",
help="specify the recipe, default: all recipes", action="store")
parser.add_argument("-m", "--members",
help = "specify the member, use comma as separator for multiple ones, default: all members", action="store", default="")
parser.add_argument("-s", "--skip",
help = "skip skipped recipes", action="store_true")
parser.add_argument("cachefile",
help = "specify bb_cache.dat", nargs = 1, action="store", default="")
def main(argv=None):
"""
Get the mapping for the target recipe.
"""
if len(argv) != 1:
print >>sys.stderr, "Error, need one argument!"
return 2
self.args = parser.parse_args()
cachefile = argv[0]
def main(self):
with open(self.args.cachefile[0], "rb") as cachefile:
pickled = pickle.Unpickler(cachefile)
while True:
try:
key = pickled.load()
val = pickled.load()
except Exception:
break
if isinstance(val, CoreRecipeInfo):
pn = val.pn
with open(cachefile, "rb") as cachefile:
pickled = pickle.Unpickler(cachefile)
while cachefile:
try:
key = pickled.load()
val = pickled.load()
except Exception:
break
if isinstance(val, CoreRecipeInfo) and (not val.skipped):
pn = val.pn
# Filter out the native recipes.
if key.startswith('virtual:native:') or pn.endswith("-native"):
continue
if self.args.recipe and self.args.recipe != pn:
continue
# 1.0 is the default version for a no PV recipe.
if val.__dict__.has_key("pv"):
pv = val.pv
else:
pv = "1.0"
if self.args.skip and val.skipped:
continue
if self.args.members:
out = key
for member in self.args.members.split(','):
out += ": %s" % val.__dict__.get(member)
print("%s" % out)
else:
print("%s: %s" % (key, val.__dict__))
elif not self.args.recipe:
print("%s %s" % (key, val))
print("%s %s %s %s" % (key, pn, pv, ' '.join(val.packages)))
if __name__ == "__main__":
try:
dump = DumpCache()
ret = dump.main()
except Exception as esc:
ret = 1
import traceback
traceback.print_exc()
sys.exit(ret)
sys.exit(main(sys.argv[1:]))

View File

@@ -1,23 +0,0 @@
# SPDX-License-Identifier: MIT
#
# Copyright (c) 2021 Joshua Watt <JPEWhacker@gmail.com>
#
# Dockerfile to build a bitbake hash equivalence server container
#
# From the root of the bitbake repository, run:
#
# docker build -f contrib/hashserv/Dockerfile .
#
FROM alpine:3.13.1
RUN apk add --no-cache python3
COPY bin/bitbake-hashserv /opt/bbhashserv/bin/
COPY lib/hashserv /opt/bbhashserv/lib/hashserv/
COPY lib/bb /opt/bbhashserv/lib/bb/
COPY lib/codegen.py /opt/bbhashserv/lib/codegen.py
COPY lib/ply /opt/bbhashserv/lib/ply/
COPY lib/bs4 /opt/bbhashserv/lib/bs4/
ENTRYPOINT ["/opt/bbhashserv/bin/bitbake-hashserv"]

View File

@@ -1,18 +0,0 @@
The MIT License (MIT)
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

View File

@@ -6,12 +6,12 @@
"
" This sets up the syntax highlighting for BitBake files, like .bb, .bbclass and .inc
if &compatible || version < 600 || exists("b:loaded_bitbake_plugin")
if &compatible || version < 600
finish
endif
" .bb, .bbappend and .bbclass
au BufNewFile,BufRead *.{bb,bbappend,bbclass} set filetype=bitbake
au BufNewFile,BufRead *.{bb,bbappend,bbclass} set filetype=bitbake
" .inc
au BufNewFile,BufRead *.inc set filetype=bitbake

View File

@@ -1,13 +1,2 @@
" Only do this when not done yet for this buffer
if exists("b:did_ftplugin")
finish
endif
" Don't load another plugin for this buffer
let b:did_ftplugin = 1
let b:undo_ftplugin = "setl cms< sts< sw< et< sua<"
setlocal commentstring=#\ %s
setlocal softtabstop=4 shiftwidth=4 expandtab
setlocal suffixesadd+=.bb,.bbclass
set sts=4 sw=4 et
set cms=#%s

View File

@@ -1,343 +0,0 @@
" Vim indent file
" Language: BitBake
" Copyright: Copyright (C) 2019 Agilent Technologies, Inc.
" Maintainer: Chris Laplante <chris.laplante@agilent.com>
" License: You may redistribute this under the same terms as Vim itself
if exists("b:did_indent")
finish
endif
if exists("*BitbakeIndent")
finish
endif
runtime! indent/sh.vim
unlet b:did_indent
setlocal indentexpr=BitbakeIndent(v:lnum)
setlocal autoindent nolisp
function s:is_bb_python_func_def(lnum)
let stack = synstack(a:lnum, 1)
if len(stack) == 0
return 0
endif
let top = synIDattr(stack[0], "name")
echo top
return synIDattr(stack[0], "name") == "bbPyFuncDef"
endfunction
"""" begin modified from indent/python.vim, upstream commit 7a9bd7c1e0ce1baf5a02daf36eeae3638aa315c7
"""" This copied code is licensed the same as Vim itself.
setlocal indentkeys+=<:>,=elif,=except
let s:keepcpo= &cpo
set cpo&vim
let s:maxoff = 50 " maximum number of lines to look backwards for ()
function GetPythonIndent(lnum)
" If this line is explicitly joined: If the previous line was also joined,
" line it up with that one, otherwise add two 'shiftwidth'
if getline(a:lnum - 1) =~ '\\$'
if a:lnum > 1 && getline(a:lnum - 2) =~ '\\$'
return indent(a:lnum - 1)
endif
return indent(a:lnum - 1) + (exists("g:pyindent_continue") ? eval(g:pyindent_continue) : (shiftwidth() * 2))
endif
" If the start of the line is in a string don't change the indent.
if has('syntax_items')
\ && synIDattr(synID(a:lnum, 1, 1), "name") =~ "String$"
return -1
endif
" Search backwards for the previous non-empty line.
let plnum = prevnonblank(v:lnum - 1)
if plnum == 0
" This is the first non-empty line, use zero indent.
return 0
endif
call cursor(plnum, 1)
" Identing inside parentheses can be very slow, regardless of the searchpair()
" timeout, so let the user disable this feature if he doesn't need it
let disable_parentheses_indenting = get(g:, "pyindent_disable_parentheses_indenting", 0)
if disable_parentheses_indenting == 1
let plindent = indent(plnum)
let plnumstart = plnum
else
" searchpair() can be slow sometimes, limit the time to 150 msec or what is
" put in g:pyindent_searchpair_timeout
let searchpair_stopline = 0
let searchpair_timeout = get(g:, 'pyindent_searchpair_timeout', 150)
" If the previous line is inside parenthesis, use the indent of the starting
" line.
" Trick: use the non-existing "dummy" variable to break out of the loop when
" going too far back.
let parlnum = searchpair('(\|{\|\[', '', ')\|}\|\]', 'nbW',
\ "line('.') < " . (plnum - s:maxoff) . " ? dummy :"
\ . " synIDattr(synID(line('.'), col('.'), 1), 'name')"
\ . " =~ '\\(Comment\\|Todo\\|String\\)$'",
\ searchpair_stopline, searchpair_timeout)
if parlnum > 0
" We may have found the opening brace of a BitBake Python task, e.g. 'python do_task {'
" If so, ignore it here - it will be handled later.
if s:is_bb_python_func_def(parlnum)
let parlnum = 0
let plindent = indent(plnum)
let plnumstart = plnum
else
let plindent = indent(parlnum)
let plnumstart = parlnum
endif
else
let plindent = indent(plnum)
let plnumstart = plnum
endif
" When inside parenthesis: If at the first line below the parenthesis add
" two 'shiftwidth', otherwise same as previous line.
" i = (a
" + b
" + c)
call cursor(a:lnum, 1)
let p = searchpair('(\|{\|\[', '', ')\|}\|\]', 'bW',
\ "line('.') < " . (a:lnum - s:maxoff) . " ? dummy :"
\ . " synIDattr(synID(line('.'), col('.'), 1), 'name')"
\ . " =~ '\\(Comment\\|Todo\\|String\\)$'",
\ searchpair_stopline, searchpair_timeout)
if p > 0
if s:is_bb_python_func_def(p)
" Handle first non-empty line inside a BB Python task
if p == plnum
return shiftwidth()
endif
" Handle the user actually trying to close a BitBake Python task
let line = getline(a:lnum)
if line =~ '^\s*}'
return -2
endif
" Otherwise ignore the brace
let p = 0
else
if p == plnum
" When the start is inside parenthesis, only indent one 'shiftwidth'.
let pp = searchpair('(\|{\|\[', '', ')\|}\|\]', 'bW',
\ "line('.') < " . (a:lnum - s:maxoff) . " ? dummy :"
\ . " synIDattr(synID(line('.'), col('.'), 1), 'name')"
\ . " =~ '\\(Comment\\|Todo\\|String\\)$'",
\ searchpair_stopline, searchpair_timeout)
if pp > 0
return indent(plnum) + (exists("g:pyindent_nested_paren") ? eval(g:pyindent_nested_paren) : shiftwidth())
endif
return indent(plnum) + (exists("g:pyindent_open_paren") ? eval(g:pyindent_open_paren) : (shiftwidth() * 2))
endif
if plnumstart == p
return indent(plnum)
endif
return plindent
endif
endif
endif
" Get the line and remove a trailing comment.
" Use syntax highlighting attributes when possible.
let pline = getline(plnum)
let pline_len = strlen(pline)
if has('syntax_items')
" If the last character in the line is a comment, do a binary search for
" the start of the comment. synID() is slow, a linear search would take
" too long on a long line.
if synIDattr(synID(plnum, pline_len, 1), "name") =~ "\\(Comment\\|Todo\\)$"
let min = 1
let max = pline_len
while min < max
let col = (min + max) / 2
if synIDattr(synID(plnum, col, 1), "name") =~ "\\(Comment\\|Todo\\)$"
let max = col
else
let min = col + 1
endif
endwhile
let pline = strpart(pline, 0, min - 1)
endif
else
let col = 0
while col < pline_len
if pline[col] == '#'
let pline = strpart(pline, 0, col)
break
endif
let col = col + 1
endwhile
endif
" If the previous line ended with a colon, indent this line
if pline =~ ':\s*$'
return plindent + shiftwidth()
endif
" If the previous line was a stop-execution statement...
" TODO: utilize this logic to deindent when ending a bbPyDefRegion
if getline(plnum) =~ '^\s*\(break\|continue\|raise\|return\|pass\|bb\.fatal\)\>'
" See if the user has already dedented
if indent(a:lnum) > indent(plnum) - shiftwidth()
" If not, recommend one dedent
return indent(plnum) - shiftwidth()
endif
" Otherwise, trust the user
return -1
endif
" If the current line begins with a keyword that lines up with "try"
if getline(a:lnum) =~ '^\s*\(except\|finally\)\>'
let lnum = a:lnum - 1
while lnum >= 1
if getline(lnum) =~ '^\s*\(try\|except\)\>'
let ind = indent(lnum)
if ind >= indent(a:lnum)
return -1 " indent is already less than this
endif
return ind " line up with previous try or except
endif
let lnum = lnum - 1
endwhile
return -1 " no matching "try"!
endif
" If the current line begins with a header keyword, dedent
if getline(a:lnum) =~ '^\s*\(elif\|else\)\>'
" Unless the previous line was a one-liner
if getline(plnumstart) =~ '^\s*\(for\|if\|try\)\>'
return plindent
endif
" Or the user has already dedented
if indent(a:lnum) <= plindent - shiftwidth()
return -1
endif
return plindent - shiftwidth()
endif
" When after a () construct we probably want to go back to the start line.
" a = (b
" + c)
" here
if parlnum > 0
return plindent
endif
return -1
endfunction
let &cpo = s:keepcpo
unlet s:keepcpo
""" end of stuff from indent/python.vim
let b:did_indent = 1
setlocal indentkeys+=0\"
function BitbakeIndent(lnum)
if !has('syntax_items')
return -1
endif
let stack = synstack(a:lnum, 1)
if len(stack) == 0
return -1
endif
let name = synIDattr(stack[0], "name")
" TODO: support different styles of indentation for assignments. For now,
" we only support like this:
" VAR = " \
" value1 \
" value2 \
" "
"
" i.e. each value indented by shiftwidth(), with the final quote " completely unindented.
if name == "bbVarValue"
" Quote handling is tricky. kernel.bbclass has this line for instance:
" EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" " HOSTCPP="${BUILD_CPP}""
" Instead of trying to handle crazy cases like that, just assume that a
" double-quote on a line by itself (following an assignment) means the
" user is closing the assignment, and de-dent.
if getline(a:lnum) =~ '^\s*"$'
return 0
endif
let prevstack = synstack(a:lnum - 1, 1)
if len(prevstack) == 0
return -1
endif
let prevname = synIDattr(prevstack[0], "name")
" Only indent if there was actually a continuation character on
" the previous line, to avoid misleading indentation.
let prevlinelastchar = synIDattr(synID(a:lnum - 1, col([a:lnum - 1, "$"]) - 1, 1), "name")
let prev_continued = prevlinelastchar == "bbContinue"
" Did the previous line introduce an assignment?
if index(["bbVarDef", "bbVarFlagDef"], prevname) != -1
if prev_continued
return shiftwidth()
endif
endif
if !prev_continued
return 0
endif
" Autoindent can take it from here
return -1
endif
if index(["bbPyDefRegion", "bbPyFuncRegion"], name) != -1
let ret = GetPythonIndent(a:lnum)
" Should normally always be indented by at least one shiftwidth; but allow
" return of -1 (defer to autoindent) or -2 (force indent to 0)
if ret == 0
return shiftwidth()
elseif ret == -2
return 0
endif
return ret
endif
" TODO: GetShIndent doesn't detect tasks prepended with 'fakeroot'
" Need to submit a patch upstream to Vim to provide an extension point.
" Unlike the Python indenter, the Sh indenter is way too large to copy and
" modify here.
if name == "bbShFuncRegion"
return GetShIndent()
endif
" TODO:
" + heuristics for de-denting out of a bbPyDefRegion? e.g. when the user
" types an obvious BB keyword like addhandler or addtask, or starts
" writing a shell task. Maybe too hard to implement...
return -1
endfunction

15
bitbake/contrib/vim/plugin/newbb.vim Normal file → Executable file
View File

@@ -10,7 +10,7 @@
"
" Will try to use git to find the user name and email
if &compatible || v:version < 600 || exists("b:loaded_bitbake_plugin")
if &compatible || v:version < 600
finish
endif
@@ -25,7 +25,7 @@ endfun
fun! <SID>GetUserEmail()
let l:user_email = system("git config --get user.email")
if v:shell_error
return "unknown@user.org"
return "unknow@user.org"
else
return substitute(l:user_email, "\n", "", "")
endfun
@@ -41,10 +41,6 @@ fun! BBHeader()
endfun
fun! NewBBTemplate()
if line2byte(line('$') + 1) != -1
return
endif
let l:paste = &paste
set nopaste
@@ -52,17 +48,18 @@ fun! NewBBTemplate()
call BBHeader()
" New the bb template
put ='SUMMARY = \"\"'
put ='DESCRIPTION = \"\"'
put ='HOMEPAGE = \"\"'
put ='LICENSE = \"\"'
put ='SECTION = \"\"'
put ='DEPENDS = \"\"'
put ='PR = \"r0\"'
put =''
put ='SRC_URI = \"\"'
" Go to the first place to edit
0
/^SUMMARY =/
/^DESCRIPTION =/
exec "normal 2f\""
if paste == 1
@@ -80,7 +77,7 @@ if v:progname =~ "vimdiff"
endif
augroup NewBB
au BufNewFile,BufReadPost *.bb
au BufNewFile *.bb
\ if g:bb_create_on_empty |
\ call NewBBTemplate() |
\ endif

View File

@@ -1,46 +0,0 @@
" Vim plugin file
" Purpose: Create a template for new bbappend file
" Author: Joshua Watt <JPEWhacker@gmail.com>
" Copyright: Copyright (C) 2017 Joshua Watt <JPEWhacker@gmail.com>
"
" This file is licensed under the MIT license, see COPYING.MIT in
" this source distribution for the terms.
"
if &compatible || v:version < 600 || exists("b:loaded_bitbake_plugin")
finish
endif
fun! NewBBAppendTemplate()
if line2byte(line('$') + 1) != -1
return
endif
let l:paste = &paste
set nopaste
" New bbappend template
0 put ='FILESEXTRAPATHS:prepend := \"${THISDIR}/${PN}:\"'
2
if paste == 1
set paste
endif
endfun
if !exists("g:bb_create_on_empty")
let g:bb_create_on_empty = 1
endif
" disable in case of vimdiff
if v:progname =~ "vimdiff"
let g:bb_create_on_empty = 0
endif
augroup NewBBAppend
au BufNewFile,BufReadPost *.bbappend
\ if g:bb_create_on_empty |
\ call NewBBAppendTemplate() |
\ endif
augroup END

View File

@@ -12,7 +12,7 @@
"
" It's an entirely new type, just has specific syntax in shell and python code
if &compatible || v:version < 600 || exists("b:loaded_bitbake_plugin")
if &compatible || v:version < 600
finish
endif
if exists("b:current_syntax")
@@ -51,15 +51,15 @@ syn region bbString matchgroup=bbQuote start=+'+ skip=+\\$+ end=+'+
syn match bbExport "^export" nextgroup=bbIdentifier skipwhite
syn keyword bbExportFlag export contained nextgroup=bbIdentifier skipwhite
syn match bbIdentifier "[a-zA-Z0-9\-_\.\/\+]\+" display contained
syn match bbVarDeref "${[a-zA-Z0-9\-_:\.\/\+]\+}" contained
syn match bbVarDeref "${[a-zA-Z0-9\-_\.\/\+]\+}" contained
syn match bbVarEq "\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)" contained nextgroup=bbVarValue
syn match bbVarDef "^\(export\s*\)\?\([a-zA-Z0-9\-_\.\/\+][${}a-zA-Z0-9\-_:\.\/\+]*\)\s*\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)\@=" contains=bbExportFlag,bbIdentifier,bbOverrideOperator,bbVarDeref nextgroup=bbVarEq
syn match bbVarDef "^\(export\s*\)\?\([a-zA-Z0-9\-_\.\/\+]\+\(_[${}a-zA-Z0-9\-_\.\/\+]\+\)\?\)\s*\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)\@=" contains=bbExportFlag,bbIdentifier,bbVarDeref nextgroup=bbVarEq
syn match bbVarValue ".*$" contained contains=bbString,bbVarDeref,bbVarPyValue
syn region bbVarPyValue start=+${@+ skip=+\\$+ end=+}+ contained contains=@python
" Vars metadata flags
syn match bbVarFlagDef "^\([a-zA-Z0-9\-_\.]\+\)\(\[[a-zA-Z0-9\-_\.+]\+\]\)\@=" contains=bbIdentifier nextgroup=bbVarFlagFlag
syn region bbVarFlagFlag matchgroup=bbArrayBrackets start="\[" end="\]\s*\(:=\|=\|.=\|=.|+=\|=+\|?=\)\@=" contained contains=bbIdentifier nextgroup=bbVarEq
syn match bbVarFlagDef "^\([a-zA-Z0-9\-_\.]\+\)\(\[[a-zA-Z0-9\-_\.]\+\]\)\@=" contains=bbIdentifier nextgroup=bbVarFlagFlag
syn region bbVarFlagFlag matchgroup=bbArrayBrackets start="\[" end="\]\s*\(=\|+=\|=+\|?=\)\@=" contained contains=bbIdentifier nextgroup=bbVarEq
" Includes and requires
syn keyword bbInclude inherit include require contained
@@ -67,17 +67,15 @@ syn match bbIncludeRest ".*$" contained contains=bbString,bbVarDeref
syn match bbIncludeLine "^\(inherit\|include\|require\)\s\+" contains=bbInclude nextgroup=bbIncludeRest
" Add taks and similar
syn keyword bbStatement addtask deltask addhandler after before EXPORT_FUNCTIONS contained
syn keyword bbStatement addtask addhandler after before EXPORT_FUNCTIONS contained
syn match bbStatementRest ".*$" skipwhite contained contains=bbStatement
syn match bbStatementLine "^\(addtask\|deltask\|addhandler\|after\|before\|EXPORT_FUNCTIONS\)\s\+" contains=bbStatement nextgroup=bbStatementRest
syn match bbStatementLine "^\(addtask\|addhandler\|after\|before\|EXPORT_FUNCTIONS\)\s\+" contains=bbStatement nextgroup=bbStatementRest
" OE Important Functions
syn keyword bbOEFunctions do_fetch do_unpack do_patch do_configure do_compile do_stage do_install do_package contained
" Generic Functions
syn match bbFunction "\h[0-9A-Za-z_\-\.]*" display contained contains=bbOEFunctions
syn keyword bbOverrideOperator append prepend remove contained
syn match bbFunction "\h[0-9A-Za-z_-]*" display contained contains=bbOEFunctions
" BitBake shell metadata
syn include @shell syntax/sh.vim
@@ -85,7 +83,7 @@ if exists("b:current_syntax")
unlet b:current_syntax
endif
syn keyword bbShFakeRootFlag fakeroot contained
syn match bbShFuncDef "^\(fakeroot\s*\)\?\([\.0-9A-Za-z_:${}\-\.]\+\)\(python\)\@<!\(\s*()\s*\)\({\)\@=" contains=bbShFakeRootFlag,bbFunction,bbOverrideOperator,bbVarDeref,bbDelimiter nextgroup=bbShFuncRegion skipwhite
syn match bbShFuncDef "^\(fakeroot\s*\)\?\([0-9A-Za-z_${}-]\+\)\(python\)\@<!\(\s*()\s*\)\({\)\@=" contains=bbShFakeRootFlag,bbFunction,bbVarDeref,bbDelimiter nextgroup=bbShFuncRegion skipwhite
syn region bbShFuncRegion matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" contained contains=@shell
" Python value inside shell functions
@@ -93,7 +91,7 @@ syn region shDeref start=+${@+ skip=+\\$+ excludenl end=+}+ contained co
" BitBake python metadata
syn keyword bbPyFlag python contained
syn match bbPyFuncDef "^\(fakeroot\s*\)\?\(python\)\(\s\+[0-9A-Za-z_:${}\-\.]\+\)\?\(\s*()\s*\)\({\)\@=" contains=bbShFakeRootFlag,bbPyFlag,bbFunction,bbOverrideOperator,bbVarDeref,bbDelimiter nextgroup=bbPyFuncRegion skipwhite
syn match bbPyFuncDef "^\(python\s\+\)\([0-9A-Za-z_${}-]\+\)\?\(\s*()\s*\)\({\)\@=" contains=bbPyFlag,bbFunction,bbVarDeref,bbDelimiter nextgroup=bbPyFuncRegion skipwhite
syn region bbPyFuncRegion matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" contained contains=@python
" BitBake 'def'd python functions
@@ -124,6 +122,5 @@ hi def link bbStatement Statement
hi def link bbStatementRest Identifier
hi def link bbOEFunctions Special
hi def link bbVarPyValue PreProc
hi def link bbOverrideOperator Operator
let b:current_syntax = "bb"

View File

@@ -1 +0,0 @@
_build/

View File

@@ -1,35 +1,91 @@
# Minimal makefile for Sphinx documentation
# This is a single Makefile to handle all generated BitBake documents.
# The Makefile needs to live in the documentation directory and all figures used
# in any manuals must be .PNG files and live in the individual book's figures
# directory.
#
# The Makefile has these targets:
#
# pdf: generates a PDF version of a manual.
# html: generates an HTML version of a manual.
# tarball: creates a tarball for the doc files.
# validate: validates
# clean: removes files
#
# The Makefile generates an HTML and PDF version of every document. The
# variable DOC indicates the folder name for a given manual.
#
# To build a manual, you must invoke 'make' with the DOC argument.
#
# Examples:
#
# make DOC=bitbake-user-manual
# make pdf DOC=bitbake-user-manual
#
# The first example generates the HTML and PDF versions of the User Manual.
# The second example generates the HTML version only of the User Manual.
#
# You can set these variables from the command line, and also
# from the environment for the first two.
SPHINXOPTS ?= -W --keep-going -j auto
SPHINXBUILD ?= sphinx-build
SOURCEDIR = .
BUILDDIR = _build
DESTDIR = final
ifeq ($(DOC),bitbake-user-manual)
XSLTOPTS = --stringparam html.stylesheet bitbake-user-manual-style.css \
--stringparam chapter.autolabel 1 \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--xinclude
ALLPREQ = html pdf tarball
TARFILES = bitbake-user-manual-style.css bitbake-user-manual.html bitbake-user-manual.pdf figures/bitbake-title.png
MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
FIGURES = figures
STYLESHEET = $(DOC)/*.css
ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
endif
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
##
# These URI should be rewritten by your distribution's xml catalog to
# match your localy installed XSL stylesheets.
XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current
XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
.PHONY: help Makefile clean publish
all: $(ALLPREQ)
publish: Makefile html singlehtml
rm -rf $(BUILDDIR)/$(DESTDIR)/
mkdir -p $(BUILDDIR)/$(DESTDIR)/
cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
pdf:
ifeq ($(DOC),bitbake-user-manual)
@echo " "
@echo "********** Building."$(DOC)
@echo " "
cd $(DOC); ../tools/docbook-to-pdf $(DOC).xml ../template; cd ..
endif
html:
ifeq ($(DOC),bitbake-user-manual)
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
@echo " "
@echo "******** Building "$(DOC)
@echo " "
cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
endif
tarball: html
@echo " "
@echo "******** Creating Tarball of document files"
@echo " "
cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
validate:
cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
publish:
@if test -f $(DOC)/$(DOC).html; \
then \
echo " "; \
echo "******** Publishing "$(DOC)".html"; \
echo " "; \
scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
else \
echo " "; \
echo $(DOC)".html missing. Generate the file first then try again."; \
echo " "; \
fi
clean:
@rm -rf $(BUILDDIR)
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;

View File

@@ -13,43 +13,27 @@ Folders exist for individual manuals as follows:
Each folder is self-contained regarding content and figures.
If you want to find HTML versions of the BitBake manuals on the web,
go to https://www.openembedded.org/wiki/Documentation.
go to http://www.openembedded.org/wiki/Documentation.
Sphinx
======
Makefile
========
The BitBake documentation was migrated from the original DocBook
format to Sphinx based documentation for the Yocto Project 3.2
release.
The Makefile processes manual directories to create HTML, PDF,
tarballs, etc. Details on how the Makefile work are documented
inside the Makefile. See that file for more information.
Additional information related to the Sphinx migration, and guidelines
for developers willing to contribute to the BitBake documentation can
be found in the Yocto Project Documentation README file:
To build a manual, you run the make command and pass it the name
of the folder containing the manual's contents.
For example, the following command run from the documentation directory
creates an HTML and a PDF version of the BitBake User Manual.
The DOC variable specifies the manual you are making:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/README
$ make DOC=bitbake-user-manual
How to build the Yocto Project documentation
============================================
template
========
Contains various templates, fonts, and some old PNG files.
Sphinx is written in Python. While it might work with Python2, for
obvious reasons, we will only support building the BitBake
documentation with Python3.
Sphinx might be available in your Linux distro packages repositories,
however it is not recommend using distro packages, as they might be
old versions, especially if you are using an LTS version of your
distro. The recommended method to install Sphinx and all required
dependencies is to use the Python Package Index (pip).
To install all required packages run:
$ pip3 install sphinx sphinx_rtd_theme pyyaml
To build the documentation locally, run:
$ cd documentation
$ make -f Makefile.sphinx html
The resulting HTML index page will be _build/html/index.html, and you
can browse your own copy of the locally generated documentation with
your browser.
tools
=====
Contains a tool to convert the DocBook files to PDF format.

View File

@@ -1,14 +0,0 @@
{% extends "!breadcrumbs.html" %}
{% block breadcrumbs %}
<li>
<span class="doctype_switcher_placeholder">{{ doctype or 'single' }}</span>
<span class="version_switcher_placeholder">{{ release }}</span>
</li>
<li> &raquo;</li>
{% for doc in parents %}
<li><a href="{{ doc.link|e }}">{{ doc.title }}</a> &raquo;</li>
{% endfor %}
<li>{{ title }}</li>
{% endblock %}

View File

@@ -1,7 +0,0 @@
{% extends "!layout.html" %}
{% block extrabody %}
<div id="outdated-warning" style="text-align: center; background-color: #FFBABA; color: #6A0E0E;">
</div>
{% endblock %}

View File

@@ -0,0 +1,15 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
<xsl:param name="html.stylesheet" select="'user-manual-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<!-- <xsl:param name="appendix.autolabel" select="A" /> -->
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
<xsl:param name="appendix.autolabel">A</xsl:param>
<!-- <xsl:param name="generate.toc" select="'article nop'"></xsl:param> -->
</xsl:stylesheet>

View File

@@ -1,724 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
=========
Execution
=========
|
The primary purpose for running BitBake is to produce some kind of
output such as a single installable package, a kernel, a software
development kit, or even a full, board-specific bootable Linux image,
complete with bootloader, kernel, and root filesystem. Of course, you
can execute the ``bitbake`` command with options that cause it to
execute single tasks, compile single recipe files, capture or clear
data, or simply return information about the execution environment.
This chapter describes BitBake's execution process from start to finish
when you use it to create an image. The execution process is launched
using the following command form::
$ bitbake target
For information on
the BitBake command and its options, see ":ref:`The BitBake Command
<bitbake-user-manual-command>`" section.
.. note::
Prior to executing BitBake, you should take advantage of available
parallel thread execution on your build host by setting the
:term:`BB_NUMBER_THREADS` variable in
your project's ``local.conf`` configuration file.
A common method to determine this value for your build host is to run
the following::
$ grep processor /proc/cpuinfo
This command returns
the number of processors, which takes into account hyper-threading.
Thus, a quad-core build host with hyper-threading most likely shows
eight processors, which is the value you would then assign to
:term:`BB_NUMBER_THREADS`.
A possibly simpler solution is that some Linux distributions (e.g.
Debian and Ubuntu) provide the ``ncpus`` command.
Parsing the Base Configuration Metadata
=======================================
The first thing BitBake does is parse base configuration metadata. Base
configuration metadata consists of your project's ``bblayers.conf`` file
to determine what layers BitBake needs to recognize, all necessary
``layer.conf`` files (one from each layer), and ``bitbake.conf``. The
data itself is of various types:
- **Recipes:** Details about particular pieces of software.
- **Class Data:** An abstraction of common build information (e.g. how to
build a Linux kernel).
- **Configuration Data:** Machine-specific settings, policy decisions,
and so forth. Configuration data acts as the glue to bind everything
together.
The ``layer.conf`` files are used to construct key variables such as
:term:`BBPATH` and :term:`BBFILES`.
:term:`BBPATH` is used to search for configuration and class files under the
``conf`` and ``classes`` directories, respectively. :term:`BBFILES` is used
to locate both recipe and recipe append files (``.bb`` and
``.bbappend``). If there is no ``bblayers.conf`` file, it is assumed the
user has set the :term:`BBPATH` and :term:`BBFILES` directly in the environment.
Next, the ``bitbake.conf`` file is located using the :term:`BBPATH` variable
that was just constructed. The ``bitbake.conf`` file may also include
other configuration files using the ``include`` or ``require``
directives.
Prior to parsing configuration files, BitBake looks at certain
variables, including:
- :term:`BB_ENV_WHITELIST`
- :term:`BB_ENV_EXTRAWHITE`
- :term:`BB_PRESERVE_ENV`
- :term:`BB_ORIGENV`
- :term:`BITBAKE_UI`
The first four variables in this list relate to how BitBake treats shell
environment variables during task execution. By default, BitBake cleans
the environment variables and provides tight control over the shell
execution environment. However, through the use of these first four
variables, you can apply your control regarding the environment
variables allowed to be used by BitBake in the shell during execution of
tasks. See the
":ref:`bitbake-user-manual/bitbake-user-manual-metadata:Passing Information Into the Build Task Environment`"
section and the information about these variables in the variable
glossary for more information on how they work and on how to use them.
The base configuration metadata is global and therefore affects all
recipes and tasks that are executed.
BitBake first searches the current working directory for an optional
``conf/bblayers.conf`` configuration file. This file is expected to
contain a :term:`BBLAYERS` variable that is a
space-delimited list of 'layer' directories. Recall that if BitBake
cannot find a ``bblayers.conf`` file, then it is assumed the user has
set the :term:`BBPATH` and :term:`BBFILES` variables directly in the
environment.
For each directory (layer) in this list, a ``conf/layer.conf`` file is
located and parsed with the :term:`LAYERDIR` variable
being set to the directory where the layer was found. The idea is these
files automatically set up :term:`BBPATH` and other
variables correctly for a given build directory.
BitBake then expects to find the ``conf/bitbake.conf`` file somewhere in
the user-specified :term:`BBPATH`. That configuration file generally has
include directives to pull in any other metadata such as files specific
to the architecture, the machine, the local environment, and so forth.
Only variable definitions and include directives are allowed in BitBake
``.conf`` files. Some variables directly influence BitBake's behavior.
These variables might have been set from the environment depending on
the environment variables previously mentioned or set in the
configuration files. The ":ref:`bitbake-user-manual/bitbake-user-manual-ref-variables:Variables Glossary`"
chapter presents a full list of
variables.
After parsing configuration files, BitBake uses its rudimentary
inheritance mechanism, which is through class files, to inherit some
standard classes. BitBake parses a class when the inherit directive
responsible for getting that class is encountered.
The ``base.bbclass`` file is always included. Other classes that are
specified in the configuration using the
:term:`INHERIT` variable are also included. BitBake
searches for class files in a ``classes`` subdirectory under the paths
in :term:`BBPATH` in the same way as configuration files.
A good way to get an idea of the configuration files and the class files
used in your execution environment is to run the following BitBake
command::
$ bitbake -e > mybb.log
Examining the top of the ``mybb.log``
shows you the many configuration files and class files used in your
execution environment.
.. note::
You need to be aware of how BitBake parses curly braces. If a recipe
uses a closing curly brace within the function and the character has
no leading spaces, BitBake produces a parsing error. If you use a
pair of curly braces in a shell function, the closing curly brace
must not be located at the start of the line without leading spaces.
Here is an example that causes BitBake to produce a parsing error::
fakeroot create_shar() {
cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
###### The following "}" at the start of the line causes a parsing error ######
}
EOF
}
Writing the recipe this way avoids the error:
fakeroot create_shar() {
cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
###### The following "}" with a leading space at the start of the line avoids the error ######
}
EOF
}
Locating and Parsing Recipes
============================
During the configuration phase, BitBake will have set
:term:`BBFILES`. BitBake now uses it to construct a
list of recipes to parse, along with any append files (``.bbappend``) to
apply. :term:`BBFILES` is a space-separated list of available files and
supports wildcards. An example would be::
BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"
BitBake parses each
recipe and append file located with :term:`BBFILES` and stores the values of
various variables into the datastore.
.. note::
Append files are applied in the order they are encountered in BBFILES.
For each file, a fresh copy of the base configuration is made, then the
recipe is parsed line by line. Any inherit statements cause BitBake to
find and then parse class files (``.bbclass``) using
:term:`BBPATH` as the search path. Finally, BitBake
parses in order any append files found in :term:`BBFILES`.
One common convention is to use the recipe filename to define pieces of
metadata. For example, in ``bitbake.conf`` the recipe name and version
are used to set the variables :term:`PN` and
:term:`PV`::
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
In this example, a recipe called "something_1.2.3.bb" would set
:term:`PN` to "something" and :term:`PV` to "1.2.3".
By the time parsing is complete for a recipe, BitBake has a list of
tasks that the recipe defines and a set of data consisting of keys and
values as well as dependency information about the tasks.
BitBake does not need all of this information. It only needs a small
subset of the information to make decisions about the recipe.
Consequently, BitBake caches the values in which it is interested and
does not store the rest of the information. Experience has shown it is
faster to re-parse the metadata than to try and write it out to the disk
and then reload it.
Where possible, subsequent BitBake commands reuse this cache of recipe
information. The validity of this cache is determined by first computing
a checksum of the base configuration data (see
:term:`BB_HASHCONFIG_WHITELIST`) and
then checking if the checksum matches. If that checksum matches what is
in the cache and the recipe and class files have not changed, BitBake is
able to use the cache. BitBake then reloads the cached information about
the recipe instead of reparsing it from scratch.
Recipe file collections exist to allow the user to have multiple
repositories of ``.bb`` files that contain the same exact package. For
example, one could easily use them to make one's own local copy of an
upstream repository, but with custom modifications that one does not
want upstream. Here is an example::
BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
BBFILE_COLLECTIONS = "upstream local"
BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"
.. note::
The layers mechanism is now the preferred method of collecting code.
While the collections code remains, its main use is to set layer
priorities and to deal with overlap (conflicts) between layers.
.. _bb-bitbake-providers:
Providers
=========
Assuming BitBake has been instructed to execute a target and that all
the recipe files have been parsed, BitBake starts to figure out how to
build the target. BitBake looks through the :term:`PROVIDES` list for each
of the recipes. A :term:`PROVIDES` list is the list of names by which the
recipe can be known. Each recipe's :term:`PROVIDES` list is created
implicitly through the recipe's :term:`PN` variable and
explicitly through the recipe's :term:`PROVIDES`
variable, which is optional.
When a recipe uses :term:`PROVIDES`, that recipe's functionality can be
found under an alternative name or names other than the implicit :term:`PN`
name. As an example, suppose a recipe named ``keyboard_1.0.bb``
contained the following::
PROVIDES += "fullkeyboard"
The :term:`PROVIDES`
list for this recipe becomes "keyboard", which is implicit, and
"fullkeyboard", which is explicit. Consequently, the functionality found
in ``keyboard_1.0.bb`` can be found under two different names.
.. _bb-bitbake-preferences:
Preferences
===========
The :term:`PROVIDES` list is only part of the solution for figuring out a
target's recipes. Because targets might have multiple providers, BitBake
needs to prioritize providers by determining provider preferences.
A common example in which a target has multiple providers is
"virtual/kernel", which is on the :term:`PROVIDES` list for each kernel
recipe. Each machine often selects the best kernel provider by using a
line similar to the following in the machine configuration file::
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
The default :term:`PREFERRED_PROVIDER` is the provider
with the same name as the target. BitBake iterates through each target
it needs to build and resolves them and their dependencies using this
process.
Understanding how providers are chosen is made complicated by the fact
that multiple versions might exist for a given provider. BitBake
defaults to the highest version of a provider. Version comparisons are
made using the same method as Debian. You can use the
:term:`PREFERRED_VERSION` variable to
specify a particular version. You can influence the order by using the
:term:`DEFAULT_PREFERENCE` variable.
By default, files have a preference of "0". Setting
:term:`DEFAULT_PREFERENCE` to "-1" makes the recipe unlikely to be used
unless it is explicitly referenced. Setting :term:`DEFAULT_PREFERENCE` to
"1" makes it likely the recipe is used. :term:`PREFERRED_VERSION` overrides
any :term:`DEFAULT_PREFERENCE` setting. :term:`DEFAULT_PREFERENCE` is often used
to mark newer and more experimental recipe versions until they have
undergone sufficient testing to be considered stable.
When there are multiple "versions" of a given recipe, BitBake defaults
to selecting the most recent version, unless otherwise specified. If the
recipe in question has a
:term:`DEFAULT_PREFERENCE` set lower than
the other recipes (default is 0), then it will not be selected. This
allows the person or persons maintaining the repository of recipe files
to specify their preference for the default selected version.
Additionally, the user can specify their preferred version.
If the first recipe is named ``a_1.1.bb``, then the
:term:`PN` variable will be set to "a", and the
:term:`PV` variable will be set to 1.1.
Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by
default. However, if you define the following variable in a ``.conf``
file that BitBake parses, you can change that preference::
PREFERRED_VERSION_a = "1.1"
.. note::
It is common for a recipe to provide two versions -- a stable,
numbered (and preferred) version, and a version that is automatically
checked out from a source code repository that is considered more
"bleeding edge" but can be selected only explicitly.
For example, in the OpenEmbedded codebase, there is a standard,
versioned recipe file for BusyBox, ``busybox_1.22.1.bb``, but there
is also a Git-based version, ``busybox_git.bb``, which explicitly
contains the line ::
DEFAULT_PREFERENCE = "-1"
to ensure that the
numbered, stable version is always preferred unless the developer
selects otherwise.
.. _bb-bitbake-dependencies:
Dependencies
============
Each target BitBake builds consists of multiple tasks such as ``fetch``,
``unpack``, ``patch``, ``configure``, and ``compile``. For best
performance on multi-core systems, BitBake considers each task as an
independent entity with its own set of dependencies.
Dependencies are defined through several variables. You can find
information about variables BitBake uses in the
:doc:`bitbake-user-manual-ref-variables` near the end of this manual. At a
basic level, it is sufficient to know that BitBake uses the
:term:`DEPENDS` and
:term:`RDEPENDS` variables when calculating
dependencies.
For more information on how BitBake handles dependencies, see the
:ref:`bitbake-user-manual/bitbake-user-manual-metadata:Dependencies`
section.
.. _ref-bitbake-tasklist:
The Task List
=============
Based on the generated list of providers and the dependency information,
BitBake can now calculate exactly what tasks it needs to run and in what
order it needs to run them. The
:ref:`bitbake-user-manual/bitbake-user-manual-execution:executing tasks`
section has more information on how BitBake chooses which task to
execute next.
The build now starts with BitBake forking off threads up to the limit
set in the :term:`BB_NUMBER_THREADS`
variable. BitBake continues to fork threads as long as there are tasks
ready to run, those tasks have all their dependencies met, and the
thread threshold has not been exceeded.
It is worth noting that you can greatly speed up the build time by
properly setting the :term:`BB_NUMBER_THREADS` variable.
As each task completes, a timestamp is written to the directory
specified by the :term:`STAMP` variable. On subsequent
runs, BitBake looks in the build directory within ``tmp/stamps`` and
does not rerun tasks that are already completed unless a timestamp is
found to be invalid. Currently, invalid timestamps are only considered
on a per recipe file basis. So, for example, if the configure stamp has
a timestamp greater than the compile timestamp for a given target, then
the compile task would rerun. Running the compile task again, however,
has no effect on other providers that depend on that target.
The exact format of the stamps is partly configurable. In modern
versions of BitBake, a hash is appended to the stamp so that if the
configuration changes, the stamp becomes invalid and the task is
automatically rerun. This hash, or signature used, is governed by the
signature policy that is configured (see the
:ref:`bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`
section for information). It is also
possible to append extra metadata to the stamp using the
``[stamp-extra-info]`` task flag. For example, OpenEmbedded uses this
flag to make some tasks machine-specific.
.. note::
Some tasks are marked as "nostamp" tasks. No timestamp file is
created when these tasks are run. Consequently, "nostamp" tasks are
always rerun.
For more information on tasks, see the
:ref:`bitbake-user-manual/bitbake-user-manual-metadata:tasks` section.
Executing Tasks
===============
Tasks can be either a shell task or a Python task. For shell tasks,
BitBake writes a shell script to
``${``\ :term:`T`\ ``}/run.do_taskname.pid`` and then
executes the script. The generated shell script contains all the
exported variables, and the shell functions with all variables expanded.
Output from the shell script goes to the file
``${T}/log.do_taskname.pid``. Looking at the expanded shell functions in
the run file and the output in the log files is a useful debugging
technique.
For Python tasks, BitBake executes the task internally and logs
information to the controlling terminal. Future versions of BitBake will
write the functions to files similar to the way shell tasks are handled.
Logging will be handled in a way similar to shell tasks as well.
The order in which BitBake runs the tasks is controlled by its task
scheduler. It is possible to configure the scheduler and define custom
implementations for specific use cases. For more information, see these
variables that control the behavior:
- :term:`BB_SCHEDULER`
- :term:`BB_SCHEDULERS`
It is possible to have functions run before and after a task's main
function. This is done using the ``[prefuncs]`` and ``[postfuncs]``
flags of the task that lists the functions to run.
.. _checksums:
Checksums (Signatures)
======================
A checksum is a unique signature of a task's inputs. The signature of a
task can be used to determine if a task needs to be run. Because it is a
change in a task's inputs that triggers running the task, BitBake needs
to detect all the inputs to a given task. For shell tasks, this turns
out to be fairly easy because BitBake generates a "run" shell script for
each task and it is possible to create a checksum that gives you a good
idea of when the task's data changes.
To complicate the problem, some things should not be included in the
checksum. First, there is the actual specific build path of a given task
- the working directory. It does not matter if the working directory
changes because it should not affect the output for target packages. The
simplistic approach for excluding the working directory is to set it to
some fixed value and create the checksum for the "run" script. BitBake
goes one step better and uses the
:term:`BB_HASHBASE_WHITELIST` variable
to define a list of variables that should never be included when
generating the signatures.
Another problem results from the "run" scripts containing functions that
might or might not get called. The incremental build solution contains
code that figures out dependencies between shell functions. This code is
used to prune the "run" scripts down to the minimum set, thereby
alleviating this problem and making the "run" scripts much more readable
as a bonus.
So far we have solutions for shell scripts. What about Python tasks? The
same approach applies even though these tasks are more difficult. The
process needs to figure out what variables a Python function accesses
and what functions it calls. Again, the incremental build solution
contains code that first figures out the variable and function
dependencies, and then creates a checksum for the data used as the input
to the task.
Like the working directory case, situations exist where dependencies
should be ignored. For these cases, you can instruct the build process
to ignore a dependency by using a line like the following::
PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
This example ensures that the
``PACKAGE_ARCHS`` variable does not depend on the value of ``MACHINE``,
even if it does reference it.
Equally, there are cases where we need to add dependencies BitBake is
not able to find. You can accomplish this by using a line like the
following::
PACKAGE_ARCHS[vardeps] = "MACHINE"
This example explicitly
adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``.
Consider a case with in-line Python, for example, where BitBake is not
able to figure out dependencies. When running in debug mode (i.e. using
``-DDD``), BitBake produces output when it discovers something for which
it cannot figure out dependencies.
Thus far, this section has limited discussion to the direct inputs into
a task. Information based on direct inputs is referred to as the
"basehash" in the code. However, there is still the question of a task's
indirect inputs - the things that were already built and present in the
build directory. The checksum (or signature) for a particular task needs
to add the hashes of all the tasks on which the particular task depends.
Choosing which dependencies to add is a policy decision. However, the
effect is to generate a master checksum that combines the basehash and
the hashes of the task's dependencies.
At the code level, there are a variety of ways both the basehash and the
dependent task hashes can be influenced. Within the BitBake
configuration file, we can give BitBake some extra information to help
it construct the basehash. The following statement effectively results
in a list of global variable dependency excludes - variables never
included in any checksum. This example uses variables from OpenEmbedded
to help illustrate the concept::
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \
USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
The previous example excludes the work directory, which is part of
``TMPDIR``.
The rules for deciding which hashes of dependent tasks to include
through dependency chains are more complex and are generally
accomplished with a Python function. The code in
``meta/lib/oe/sstatesig.py`` shows two examples of this and also
illustrates how you can insert your own policy into the system if so
desired. This file defines the two basic signature generators
OpenEmbedded-Core uses: "OEBasic" and "OEBasicHash". By default, there
is a dummy "noop" signature handler enabled in BitBake. This means that
behavior is unchanged from previous versions. ``OE-Core`` uses the
"OEBasicHash" signature handler by default through this setting in the
``bitbake.conf`` file::
BB_SIGNATURE_HANDLER ?= "OEBasicHash"
The "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is the same as the "OEBasic"
version but adds the task hash to the stamp files. This results in any
metadata change that changes the task hash, automatically causing the
task to be run again. This removes the need to bump
:term:`PR` values, and changes to metadata automatically
ripple across the build.
It is also worth noting that the end result of these signature
generators is to make some dependency and hash information available to
the build. This information includes:
- ``BB_BASEHASH_task-``\ *taskname*: The base hashes for each task in the
recipe.
- ``BB_BASEHASH_``\ *filename:taskname*: The base hashes for each
dependent task.
- :term:`BB_TASKHASH`: The hash of the currently running task.
It is worth noting that BitBake's "-S" option lets you debug BitBake's
processing of signatures. The options passed to -S allow different
debugging modes to be used, either using BitBake's own debug functions
or possibly those defined in the metadata/signature handler itself. The
simplest parameter to pass is "none", which causes a set of signature
information to be written out into ``STAMPS_DIR`` corresponding to the
targets specified. The other currently available parameter is
"printdiff", which causes BitBake to try to establish the closest
signature match it can (e.g. in the sstate cache) and then run
``bitbake-diffsigs`` over the matches to determine the stamps and delta
where these two stamp trees diverge.
.. note::
It is likely that future versions of BitBake will provide other
signature handlers triggered through additional "-S" parameters.
You can find more information on checksum metadata in the
:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
section.
Setscene
========
The setscene process enables BitBake to handle "pre-built" artifacts.
The ability to handle and reuse these artifacts allows BitBake the
luxury of not having to build something from scratch every time.
Instead, BitBake can use, when possible, existing build artifacts.
BitBake needs to have reliable data indicating whether or not an
artifact is compatible. Signatures, described in the previous section,
provide an ideal way of representing whether an artifact is compatible.
If a signature is the same, an object can be reused.
If an object can be reused, the problem then becomes how to replace a
given task or set of tasks with the pre-built artifact. BitBake solves
the problem with the "setscene" process.
When BitBake is asked to build a given target, before building anything,
it first asks whether cached information is available for any of the
targets it's building, or any of the intermediate targets. If cached
information is available, BitBake uses this information instead of
running the main tasks.
BitBake first calls the function defined by the
:term:`BB_HASHCHECK_FUNCTION` variable
with a list of tasks and corresponding hashes it wants to build. This
function is designed to be fast and returns a list of the tasks for
which it believes in can obtain artifacts.
Next, for each of the tasks that were returned as possibilities, BitBake
executes a setscene version of the task that the possible artifact
covers. Setscene versions of a task have the string "_setscene" appended
to the task name. So, for example, the task with the name ``xxx`` has a
setscene task named ``xxx_setscene``. The setscene version of the task
executes and provides the necessary artifacts returning either success
or failure.
As previously mentioned, an artifact can cover more than one task. For
example, it is pointless to obtain a compiler if you already have the
compiled binary. To handle this, BitBake calls the
:term:`BB_SETSCENE_DEPVALID` function for
each successful setscene task to know whether or not it needs to obtain
the dependencies of that task.
You can find more information on setscene metadata in the
:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
section.
Logging
=======
In addition to the standard command line option to control how verbose
builds are when execute, bitbake also supports user defined
configuration of the `Python
logging <https://docs.python.org/3/library/logging.html>`__ facilities
through the :term:`BB_LOGCONFIG` variable. This
variable defines a json or yaml `logging
configuration <https://docs.python.org/3/library/logging.config.html>`__
that will be intelligently merged into the default configuration. The
logging configuration is merged using the following rules:
- The user defined configuration will completely replace the default
configuration if top level key ``bitbake_merge`` is set to the value
``False``. In this case, all other rules are ignored.
- The user configuration must have a top level ``version`` which must
match the value of the default configuration.
- Any keys defined in the ``handlers``, ``formatters``, or ``filters``,
will be merged into the same section in the default configuration,
with the user specified keys taking replacing a default one if there
is a conflict. In practice, this means that if both the default
configuration and user configuration specify a handler named
``myhandler``, the user defined one will replace the default. To
prevent the user from inadvertently replacing a default handler,
formatter, or filter, all of the default ones are named with a prefix
of "``BitBake.``"
- If a logger is defined by the user with the key ``bitbake_merge`` set
to ``False``, that logger will be completely replaced by user
configuration. In this case, no other rules will apply to that
logger.
- All user defined ``filter`` and ``handlers`` properties for a given
logger will be merged with corresponding properties from the default
logger. For example, if the user configuration adds a filter called
``myFilter`` to the ``BitBake.SigGen``, and the default configuration
adds a filter called ``BitBake.defaultFilter``, both filters will be
applied to the logger
As an example, consider the following user logging configuration file
which logs all Hash Equivalence related messages of VERBOSE or higher to
a file called ``hashequiv.log`` ::
{
"version": 1,
"handlers": {
"autobuilderlog": {
"class": "logging.FileHandler",
"formatter": "logfileFormatter",
"level": "DEBUG",
"filename": "hashequiv.log",
"mode": "w"
}
},
"formatters": {
"logfileFormatter": {
"format": "%(name)s: %(levelname)s: %(message)s"
}
},
"loggers": {
"BitBake.SigGen.HashEquiv": {
"level": "VERBOSE",
"handlers": ["autobuilderlog"]
},
"BitBake.RunQueue.HashEquiv": {
"level": "VERBOSE",
"handlers": ["autobuilderlog"]
}
}
}

View File

@@ -0,0 +1,850 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id="bitbake-user-manual-execution">
<title>Execution</title>
<para>
The primary purpose for running BitBake is to produce some kind
of output such as an image, a kernel, or a software development
kit.
Of course, you can execute the <filename>bitbake</filename>
command with options that cause it to execute single tasks,
compile single recipe files, capture or clear data, or simply
return information about the execution environment.
</para>
<para>
This chapter describes BitBake's execution process from start
to finish when you use it to create an image.
The execution process is launched using the following command
form:
<literallayout class='monospaced'>
$ bitbake &lt;target&gt;
</literallayout>
For information on the BitBake command and its options,
see
"<link linkend='bitbake-user-manual-command'>The BitBake Command</link>"
section.
</para>
<note>
Prior to executing BitBake, you should take advantage of parallel
thread execution by setting the
<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
variable in your <filename>local.conf</filename>
configuration file.
</note>
<section id='parsing-the-base-configuration-metadata'>
<title>Parsing the Base Configuration Metadata</title>
<para>
The first thing BitBake does is parse base configuration
metadata.
Base configuration metadata consists of the
<filename>bblayers.conf</filename> file to determine what
layers BitBake needs to recognize, all necessary
<filename>layer.conf</filename> files (one from each layer),
and <filename>bitbake.conf</filename>.
The data itself is of various types:
<itemizedlist>
<listitem><para><emphasis>Recipes:</emphasis>
Details about particular pieces of software.
</para></listitem>
<listitem><para><emphasis>Class Data:</emphasis>
An abstraction of common build information
(e.g. how to build a Linux kernel).
</para></listitem>
<listitem><para><emphasis>Configuration Data:</emphasis>
Machine-specific settings, policy decisions,
and so forth.
Configuration data acts as the glue to bind everything
together.</para></listitem>
</itemizedlist>
</para>
<para>
The <filename>layer.conf</filename> files are used to
construct key variables such as
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
and
<link linkend='var-BBFILES'><filename>BBFILES</filename></link>.
<filename>BBPATH</filename> is used to search for
configuration and class files under
<filename>conf/</filename> and <filename>class/</filename>
directories, respectively.
<filename>BBFILES</filename> is used to find recipe files
(<filename>.bb</filename> and <filename>.bbappend</filename>).
If there is no <filename>bblayers.conf</filename> file,
it is assumed the user has set the <filename>BBPATH</filename>
and <filename>BBFILES</filename> directly in the environment.
</para>
<para>
Next, the <filename>bitbake.conf</filename> file is searched
using the <filename>BBPATH</filename> variable that was
just constructed.
The <filename>bitbake.conf</filename> file may also include other
configuration files using the
<filename>include</filename> or
<filename>require</filename> directives.
</para>
<para>
Prior to parsing configuration files, Bitbake looks
at certain variables, including:
<itemizedlist>
<listitem><para><link linkend='var-BB_ENV_WHITELIST'><filename>BB_ENV_WHITELIST</filename></link></para></listitem>
<listitem><para><link linkend='var-BB_PRESERVE_ENV'><filename>BB_PRESERVE_ENV</filename></link></para></listitem>
<listitem><para><link linkend='var-BB_ENV_EXTRAWHITE'><filename>BB_ENV_EXTRAWHITE</filename></link></para></listitem>
<listitem><para>
<link linkend='var-BITBAKE_UI'><filename>BITBAKE_UI</filename></link>
</para></listitem>
</itemizedlist>
You can find information on how to pass environment variables into the BitBake
execution environment in the
"<link linkend='passing-information-into-the-build-task-environment'>Passing Information Into the Build Task Environment</link>" section.
</para>
<para>
The base configuration metadata is global
and therefore affects all recipes and tasks that are executed.
</para>
<para>
BitBake first searches the current working directory for an
optional <filename>conf/bblayers.conf</filename> configuration file.
This file is expected to contain a
<link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link>
variable that is a space delimited list of 'layer' directories.
Recall that if BitBake cannot find a <filename>bblayers.conf</filename>
file then it is assumed the user has set the <filename>BBPATH</filename>
and <filename>BBFILES</filename> directly in the environment.
</para>
<para>
For each directory (layer) in this list, a <filename>conf/layer.conf</filename>
file is searched for and parsed with the
<link linkend='var-LAYERDIR'><filename>LAYERDIR</filename></link>
variable being set to the directory where the layer was found.
The idea is these files automatically setup
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
and other variables correctly for a given build directory.
</para>
<para>
BitBake then expects to find the <filename>conf/bitbake.conf</filename>
file somewhere in the user-specified <filename>BBPATH</filename>.
That configuration file generally has include directives to pull
in any other metadata such as files specific to the architecture,
the machine, the local environment, and so forth.
</para>
<para>
Only variable definitions and include directives are allowed
in <filename>.conf</filename> files.
Some variables directly influence BitBake's behavior.
These variables might have been set from the environment
depending on the environment variables previously
mentioned or set in the configuration files.
The
"<link linkend='ref-variables-glos'>Variables Glossary</link>"
chapter presents a full list of variables.
</para>
<para>
After parsing configuration files, BitBake uses its rudimentary
inheritance mechanism, which is through class files, to inherit
some standard classes.
BitBake parses a class when the inherit directive responsible
for getting that class is encountered.
</para>
<para>
The <filename>base.bbclass</filename> file is always included.
Other classes that are specified in the configuration using the
<link linkend='var-INHERIT'><filename>INHERIT</filename></link>
variable are also included.
BitBake searches for class files in a "classes" subdirectory under
the paths in <filename>BBPATH</filename> in the same way as
configuration files.
</para>
<para>
A good way to get an idea of the configuration files and
the class files used in your execution environment is to
run the following BitBake command:
<literallayout class='monospaced'>
$ bitbake -e > mybb.log
</literallayout>
Examining the top of the <filename>mybb.log</filename>
shows you the many configuration files and class files
used in your execution environment.
</para>
<note>
<para>
You need to be aware of how BitBake parses curly braces.
If a recipe uses a closing curly brace within the function and
the character has no leading spaces, BitBake produces a parsing
error.
If you use a pair of curly brace in a shell function, the
closing curly brace must not be located at the start of the line
without leading spaces.
</para>
<para>
Here is an example that causes BitBake to produce a parsing
error:
<literallayout class='monospaced'>
fakeroot create_shar() {
cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
###### The following "}" at the start of the line causes a parsing error ######
}
EOF
}
</literallayout>
Writing the recipe this way avoids the error:
<literallayout class='monospaced'>
fakeroot create_shar() {
cat &lt;&lt; "EOF" &gt; ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
usage()
{
echo "test"
######The following "}" with a leading space at the start of the line avoids the error ######
}
EOF
}
</literallayout>
</para>
</note>
</section>
<section id='locating-and-parsing-recipes'>
<title>Locating and Parsing Recipes</title>
<para>
During the configuration phase, BitBake will have set
<link linkend='var-BBFILES'><filename>BBFILES</filename></link>.
BitBake now uses it to construct a list of recipes to parse,
along with any append files (<filename>.bbappend</filename>)
to apply.
<filename>BBFILES</filename> is a space-separated list of
available files and supports wildcards.
An example would be:
<literallayout class='monospaced'>
BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"
</literallayout>
BitBake parses each recipe and append file located
with <filename>BBFILES</filename> and stores the values of
various variables into the datastore.
<note>
Append files are applied in the order they are encountered in
<filename>BBFILES</filename>.
</note>
For each file, a fresh copy of the base configuration is
made, then the recipe is parsed line by line.
Any inherit statements cause BitBake to find and
then parse class files (<filename>.bbclass</filename>)
using
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
as the search path.
Finally, BitBake parses in order any append files found in
<filename>BBFILES</filename>.
</para>
<para>
One common convention is to use the recipe filename to define
pieces of metadata.
For example, in <filename>bitbake.conf</filename> the recipe
name and version set
<link linkend='var-PN'><filename>PN</filename></link> and
<link linkend='var-PV'><filename>PV</filename></link>:
<literallayout class='monospaced'>
PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[1] or '1.0'}"
PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE'),d)[0] or 'defaultpkgname'}"
</literallayout>
In this example, a recipe called "something_1.2.3.bb" sets
<filename>PN</filename> to "something" and
<filename>PV</filename> to "1.2.3".
</para>
<para>
By the time parsing is complete for a recipe, BitBake
has a list of tasks that the recipe defines and a set of
data consisting of keys and values as well as
dependency information about the tasks.
</para>
<para>
BitBake does not need all of this information.
It only needs a small subset of the information to make
decisions about the recipe.
Consequently, BitBake caches the values in which it is
interested and does not store the rest of the information.
Experience has shown it is faster to re-parse the metadata than to
try and write it out to the disk and then reload it.
</para>
<para>
Where possible, subsequent BitBake commands reuse this cache of
recipe information.
The validity of this cache is determined by first computing a
checksum of the base configuration data (see
<link linkend='var-BB_HASHCONFIG_WHITELIST'><filename>BB_HASHCONFIG_WHITELIST</filename></link>)
and then checking if the checksum matches.
If that checksum matches what is in the cache and the recipe
and class files have not changed, Bitbake is able to use
the cache.
BitBake then reloads the cached information about the recipe
instead of reparsing it from scratch.
</para>
<para>
Recipe file collections exist to allow the user to
have multiple repositories of
<filename>.bb</filename> files that contain the same
exact package.
For example, one could easily use them to make one's
own local copy of an upstream repository, but with
custom modifications that one does not want upstream.
Here is an example:
<literallayout class='monospaced'>
BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
BBFILE_COLLECTIONS = "upstream local"
BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
BBFILE_PRIORITY_upstream = "5"
BBFILE_PRIORITY_local = "10"
</literallayout>
<note>
The layers mechanism is now the preferred method of collecting
code.
While the collections code remains, its main use is to set layer
priorities and to deal with overlap (conflicts) between layers.
</note>
</para>
</section>
<section id='bb-bitbake-providers'>
<title>Preferences and Providers</title>
<para>
Assuming BitBake has been instructed to execute a target
and that all the recipe files have been parsed, BitBake
starts to figure out how to build the target.
BitBake starts by looking through the
<link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
set in recipe files.
The default <filename>PROVIDES</filename> for a recipe is its name
(<link linkend='var-PN'><filename>PN</filename></link>),
however, a recipe can provide multiple things.
</para>
<para>
As an example of adding an extra provider, suppose a recipe named
<filename>foo_1.0.bb</filename> contained the following:
<literallayout class='monospaced'>
PROVIDES += "virtual/bar_1.0"
</literallayout>
The recipe now provides both "foo_1.0" and "virtual/bar_1.0".
The "virtual/" namespace is often used to denote cases where
multiple providers are expected with the user choosing between
them.
Kernels and toolchain components are common cases of this in
OpenEmbedded.
</para>
<para>
Sometimes a target might have multiple providers.
A common example is "virtual/kernel", which is provided by each
kernel recipe.
Each machine often selects the best kernel provider by using a
line similar to the following in the machine configuration file:
<literallayout class='monospaced'>
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
</literallayout>
The default
<link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>
is the provider with the same name as the target.
Bitbake iterates through each target it needs to build and
resolves them and their dependencies using this process.
</para>
<para>
Understanding how providers are chosen is made complicated by the fact
that multiple versions might exist.
BitBake defaults to the highest version of a provider.
Version comparisons are made using the same method as Debian.
You can use the
<link linkend='var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link>
variable to specify a particular version.
You can influence the order by using the
<link linkend='var-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link>
variable.
By default, files have a preference of "0".
Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
recipe unlikely to be used unless it is explicitly referenced.
Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the recipe is used.
<filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting.
<filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental recipe
versions until they have undergone sufficient testing to be considered stable.
</para>
<para>
When there are multiple “versions” of a given recipe,
BitBake defaults to selecting the most recent
version, unless otherwise specified.
If the recipe in question has a
<link linkend='var-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link>
set lower than
the other recipes (default is 0), then it will not be
selected.
This allows the person or persons maintaining
the repository of recipe files to specify
their preference for the default selected version.
In addition, the user can specify their preferred version.
</para>
<para>
If the first recipe is named <filename>a_1.1.bb</filename>,
then the
<link linkend='var-PN'><filename>PN</filename></link> variable
will be set to “a”, and the
<link linkend='var-PV'><filename>PV</filename></link>
variable will be set to 1.1.
</para>
<para>
If we then have a recipe named <filename>a_1.2.bb</filename>, BitBake
will choose 1.2 by default.
However, if we define the following variable in a
<filename>.conf</filename> file that BitBake parses, we
can change that.
<literallayout class='monospaced'>
PREFERRED_VERSION_a = "1.1"
</literallayout>
</para>
<para>
In summary, BitBake has created a list of providers, which is prioritized, for each target.
</para>
</section>
<section id='bb-bitbake-dependencies'>
<title>Dependencies</title>
<para>
Each target BitBake builds consists of multiple tasks such as
<filename>fetch</filename>, <filename>unpack</filename>,
<filename>patch</filename>, <filename>configure</filename>,
and <filename>compile</filename>.
For best performance on multi-core systems, BitBake considers each
task as an independent
entity with its own set of dependencies.
</para>
<para>
Dependencies are defined through several variables.
You can find information about variables BitBake uses in
the <link linkend='ref-variables-glos'>Variables Glossary</link>
near the end of this manual.
At a basic level, it is sufficient to know that BitBake uses the
<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link> and
<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> variables when
calculating dependencies.
</para>
<para>
For more information on how BitBake handles dependencies, see the
"<link linkend='dependencies'>Dependencies</link>" section.
</para>
</section>
<section id='ref-bitbake-tasklist'>
<title>The Task List</title>
<para>
Based on the generated list of providers and the dependency information,
BitBake can now calculate exactly what tasks it needs to run and in what
order it needs to run them.
The
"<link linkend='executing-tasks'>Executing Tasks</link>" section has more
information on how BitBake chooses which task to execute next.
</para>
<para>
The build now starts with BitBake forking off threads up to the limit set in the
<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
variable.
BitBake continues to fork threads as long as there are tasks ready to run,
those tasks have all their dependencies met, and the thread threshold has not been
exceeded.
</para>
<para>
It is worth noting that you can greatly speed up the build time by properly setting
the <filename>BB_NUMBER_THREADS</filename> variable.
</para>
<para>
As each task completes, a timestamp is written to the directory specified by the
<link linkend='var-STAMP'><filename>STAMP</filename></link> variable.
On subsequent runs, BitBake looks in the build directory within
<filename>tmp/stamps</filename>and does not rerun
tasks that are already completed unless a timestamp is found to be invalid.
Currently, invalid timestamps are only considered on a per
recipe file basis.
So, for example, if the configure stamp has a timestamp greater than the
compile timestamp for a given target, then the compile task would rerun.
Running the compile task again, however, has no effect on other providers
that depend on that target.
</para>
<para>
The exact format of the stamps is partly configurable.
In modern versions of BitBake, a hash is appended to the
stamp so that if the configuration changes, the stamp becomes
invalid and the task is automatically rerun.
This hash, or signature used, is governed by the signature policy
that is configured (see the
"<link linkend='checksums'>Checksums (Signatures)</link>"
section for information).
It is also possible to append extra metadata to the stamp using
the "stamp-extra-info" task flag.
For example, OpenEmbedded uses this flag to make some tasks machine-specific.
</para>
<note>
Some tasks are marked as "nostamp" tasks.
No timestamp file is created when these tasks are run.
Consequently, "nostamp" tasks are always rerun.
</note>
<para>
For more information on tasks, see the
"<link linkend='tasks'>Tasks</link>" section.
</para>
</section>
<section id='executing-tasks'>
<title>Executing Tasks</title>
<para>
Tasks can either be a shell task or a Python task.
For shell tasks, BitBake writes a shell script to
<filename>${</filename><link linkend='var-T'><filename>T</filename></link><filename>}/run.do_taskname.pid</filename>
and then executes the script.
The generated shell script contains all the exported variables,
and the shell functions with all variables expanded.
Output from the shell script goes to the file
<filename>${T}/log.do_taskname.pid</filename>.
Looking at the expanded shell functions in the run file and
the output in the log files is a useful debugging technique.
</para>
<para>
For Python tasks, BitBake executes the task internally and logs
information to the controlling terminal.
Future versions of BitBake will write the functions to files
similar to the way shell tasks are handled.
Logging will be handled in a way similar to shell tasks as well.
</para>
<para>
The order in which BitBake runs the tasks is controlled by its
task scheduler.
It is possible to configure the scheduler and define custom
implementations for specific use cases.
For more information, see these variables that control the
behavior:
<itemizedlist>
<listitem><para>
<link linkend='var-BB_SCHEDULER'><filename>BB_SCHEDULER</filename></link>
</para></listitem>
<listitem><para>
<link linkend='var-BB_SCHEDULERS'><filename>BB_SCHEDULERS</filename></link>
</para></listitem>
</itemizedlist>
It is possible to have functions run before and after a task's main
function.
This is done using the "prefuncs" and "postfuncs" flags of the task
that lists the functions to run.
</para>
</section>
<section id='checksums'>
<title>Checksums (Signatures)</title>
<para>
A checksum is a unique signature of a task's inputs.
The signature of a task can be used to determine if a task
needs to be run.
Because it is a change in a task's inputs that triggers running
the task, BitBake needs to detect all the inputs to a given task.
For shell tasks, this turns out to be fairly easy because
BitBake generates a "run" shell script for each task and
it is possible to create a checksum that gives you a good idea of when
the task's data changes.
</para>
<para>
To complicate the problem, some things should not be included in
the checksum.
First, there is the actual specific build path of a given task -
the working directory.
It does not matter if the working directory changes because it should not
affect the output for target packages.
The simplistic approach for excluding the working directory is to set
it to some fixed value and create the checksum for the "run" script.
BitBake goes one step better and uses the
<link linkend='var-BB_HASHBASE_WHITELIST'><filename>BB_HASHBASE_WHITELIST</filename></link>
variable to define a list of variables that should never be included
when generating the signatures.
</para>
<para>
Another problem results from the "run" scripts containing functions that
might or might not get called.
The incremental build solution contains code that figures out dependencies
between shell functions.
This code is used to prune the "run" scripts down to the minimum set,
thereby alleviating this problem and making the "run" scripts much more
readable as a bonus.
</para>
<para>
So far we have solutions for shell scripts.
What about Python tasks?
The same approach applies even though these tasks are more difficult.
The process needs to figure out what variables a Python function accesses
and what functions it calls.
Again, the incremental build solution contains code that first figures out
the variable and function dependencies, and then creates a checksum for the data
used as the input to the task.
</para>
<para>
Like the working directory case, situations exist where dependencies
should be ignored.
For these cases, you can instruct the build process to ignore a dependency
by using a line like the following:
<literallayout class='monospaced'>
PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
</literallayout>
This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not
depend on the value of <filename>MACHINE</filename>, even if it does reference it.
</para>
<para>
Equally, there are cases where we need to add dependencies BitBake
is not able to find.
You can accomplish this by using a line like the following:
<literallayout class='monospaced'>
PACKAGE_ARCHS[vardeps] = "MACHINE"
</literallayout>
This example explicitly adds the <filename>MACHINE</filename> variable as a
dependency for <filename>PACKAGE_ARCHS</filename>.
</para>
<para>
Consider a case with in-line Python, for example, where BitBake is not
able to figure out dependencies.
When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
produces output when it discovers something for which it cannot figure out
dependencies.
</para>
<para>
Thus far, this section has limited discussion to the direct inputs into a task.
Information based on direct inputs is referred to as the "basehash" in the
code.
However, there is still the question of a task's indirect inputs - the
things that were already built and present in the build directory.
The checksum (or signature) for a particular task needs to add the hashes
of all the tasks on which the particular task depends.
Choosing which dependencies to add is a policy decision.
However, the effect is to generate a master checksum that combines the basehash
and the hashes of the task's dependencies.
</para>
<para>
At the code level, there are a variety of ways both the basehash and the
dependent task hashes can be influenced.
Within the BitBake configuration file, we can give BitBake some extra information
to help it construct the basehash.
The following statement effectively results in a list of global variable
dependency excludes - variables never included in any checksum.
This example uses variables from OpenEmbedded to help illustrate
the concept:
<literallayout class='monospaced'>
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
</literallayout>
The previous example excludes the work directory, which is part of
<filename>TMPDIR</filename>.
</para>
<para>
The rules for deciding which hashes of dependent tasks to include through
dependency chains are more complex and are generally accomplished with a
Python function.
The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
of this and also illustrates how you can insert your own policy into the system
if so desired.
This file defines the two basic signature generators OpenEmbedded Core
uses: "OEBasic" and "OEBasicHash".
By default, there is a dummy "noop" signature handler enabled in BitBake.
This means that behavior is unchanged from previous versions.
<filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
through this setting in the <filename>bitbake.conf</filename> file:
<literallayout class='monospaced'>
BB_SIGNATURE_HANDLER ?= "OEBasicHash"
</literallayout>
The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
"OEBasic" version but adds the task hash to the stamp files.
This results in any metadata change that changes the task hash, automatically
causing the task to be run again.
This removes the need to bump
<link linkend='var-PR'><filename>PR</filename></link>
values, and changes to metadata automatically ripple across the build.
</para>
<para>
It is also worth noting that the end result of these signature generators is to
make some dependency and hash information available to the build.
This information includes:
<itemizedlist>
<listitem><para><filename>BB_BASEHASH_task-&lt;taskname&gt;</filename>:
The base hashes for each task in the recipe.
</para></listitem>
<listitem><para><filename>BB_BASEHASH_&lt;filename:taskname&gt;</filename>:
The base hashes for each dependent task.
</para></listitem>
<listitem><para><filename>BBHASHDEPS_&lt;filename:taskname&gt;</filename>:
The task dependencies for each task.
</para></listitem>
<listitem><para><filename>BB_TASKHASH</filename>:
The hash of the currently running task.
</para></listitem>
</itemizedlist>
</para>
<para>
It is worth noting that BitBake's "-S" option lets you
debug Bitbake's processing of signatures.
The options passed to -S allow different debugging modes
to be used, either using BitBake's own debug functions
or possibly those defined in the metadata/signature handler
itself.
The simplest parameter to pass is "none", which causes a
set of signature information to be written out into
<filename>STAMP_DIR</filename>
corresponding to the targets specified.
The other currently available parameter is "printdiff",
which causes BitBake to try to establish the closest
signature match it can (e.g. in the sstate cache) and then
run <filename>bitbake-diffsigs</filename> over the matches
to determine the stamps and delta where these two
stamp trees diverge.
<note>
It is likely that future versions of BitBake with
provide other signature handlers triggered through
additional "-S" paramters.
</note>
</para>
<para>
You can find more information on checksum metadata in the
"<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>"
section.
</para>
</section>
<section id='setscene'>
<title>Setscene</title>
<para>
The setscene process enables BitBake to handle "pre-built" artifacts.
The ability to handle and reuse these artifacts allows BitBake
the luxury of not having to build something from scratch every time.
Instead, BitBake can use, when possible, existing build artifacts.
</para>
<para>
BitBake needs to have reliable data indicating whether or not an
artifact is compatible.
Signatures, described in the previous section, provide an ideal
way of representing whether an artifact is compatible.
If a signature is the same, an object can be reused.
</para>
<para>
If an object can be reused, the problem then becomes how to
replace a given task or set of tasks with the pre-built artifact.
BitBake solves the problem with the "setscene" process.
</para>
<para>
When BitBake is asked to build a given target, before building anything,
it first asks whether cached information is available for any of the
targets it's building, or any of the intermediate targets.
If cached information is available, BitBake uses this information instead of
running the main tasks.
</para>
<para>
BitBake first calls the function defined by the
<link linkend='var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>
variable with a list of tasks and corresponding
hashes it wants to build.
This function is designed to be fast and returns a list
of the tasks for which it believes in can obtain artifacts.
</para>
<para>
Next, for each of the tasks that were returned as possibilities,
BitBake executes a setscene version of the task that the possible
artifact covers.
Setscene versions of a task have the string "_setscene" appended to the
task name.
So, for example, the task with the name <filename>xxx</filename> has
a setscene task named <filename>xxx_setscene</filename>.
The setscene version of the task executes and provides the necessary
artifacts returning either success or failure.
</para>
<para>
As previously mentioned, an artifact can cover more than one task.
For example, it is pointless to obtain a compiler if you
already have the compiled binary.
To handle this, BitBake calls the
<link linkend='var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>
function for each successful setscene task to know whether or not it needs
to obtain the dependencies of that task.
</para>
<para>
Finally, after all the setscene tasks have executed, BitBake calls the
function listed in
<link linkend='var-BB_SETSCENE_VERIFY_FUNCTION'><filename>BB_SETSCENE_VERIFY_FUNCTION</filename></link>
with the list of tasks BitBake thinks has been "covered".
The metadata can then ensure that this list is correct and can
inform BitBake that it wants specific tasks to be run regardless
of the setscene result.
</para>
<para>
You can find more information on setscene metadata in the
"<link linkend='task-checksums-and-setscene'>Task Checksums and Setscene</link>"
section.
</para>
</section>
</chapter>

View File

@@ -1,694 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
=====================
File Download Support
=====================
|
BitBake's fetch module is a standalone piece of library code that deals
with the intricacies of downloading source code and files from remote
systems. Fetching source code is one of the cornerstones of building
software. As such, this module forms an important part of BitBake.
The current fetch module is called "fetch2" and refers to the fact that
it is the second major version of the API. The original version is
obsolete and has been removed from the codebase. Thus, in all cases,
"fetch" refers to "fetch2" in this manual.
The Download (Fetch)
====================
BitBake takes several steps when fetching source code or files. The
fetcher codebase deals with two distinct processes in order: obtaining
the files from somewhere (cached or otherwise) and then unpacking those
files into a specific location and perhaps in a specific way. Getting
and unpacking the files is often optionally followed by patching.
Patching, however, is not covered by this module.
The code to execute the first part of this process, a fetch, looks
something like the following::
src_uri = (d.getVar('SRC_URI') or "").split()
fetcher = bb.fetch2.Fetch(src_uri, d)
fetcher.download()
This code sets up an instance of the fetch class. The instance uses a
space-separated list of URLs from the :term:`SRC_URI`
variable and then calls the ``download`` method to download the files.
The instantiation of the fetch class is usually followed by::
rootdir = l.getVar('WORKDIR')
fetcher.unpack(rootdir)
This code unpacks the downloaded files to the specified by ``WORKDIR``.
.. note::
For convenience, the naming in these examples matches the variables
used by OpenEmbedded. If you want to see the above code in action,
examine the OpenEmbedded class file ``base.bbclass``
.
The :term:`SRC_URI` and ``WORKDIR`` variables are not hardcoded into the
fetcher, since those fetcher methods can be (and are) called with
different variable names. In OpenEmbedded for example, the shared state
(sstate) code uses the fetch module to fetch the sstate files.
When the ``download()`` method is called, BitBake tries to resolve the
URLs by looking for source files in a specific search order:
- *Pre-mirror Sites:* BitBake first uses pre-mirrors to try and find
source files. These locations are defined using the
:term:`PREMIRRORS` variable.
- *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g
from :term:`SRC_URI`).
- *Mirror Sites:* If fetch failures occur, BitBake next uses mirror
locations as defined by the :term:`MIRRORS` variable.
For each URL passed to the fetcher, the fetcher calls the submodule that
handles that particular URL type. This behavior can be the source of
some confusion when you are providing URLs for the :term:`SRC_URI` variable.
Consider the following two URLs::
https://git.yoctoproject.org/git/poky;protocol=git
git://git.yoctoproject.org/git/poky;protocol=http
In the former case, the URL is passed to the ``wget`` fetcher, which does not
understand "git". Therefore, the latter case is the correct form since the Git
fetcher does know how to use HTTP as a transport.
Here are some examples that show commonly used mirror definitions::
PREMIRRORS ?= "\
bzr://.*/.\* http://somemirror.org/sources/ \\n \
cvs://.*/.\* http://somemirror.org/sources/ \\n \
git://.*/.\* http://somemirror.org/sources/ \\n \
hg://.*/.\* http://somemirror.org/sources/ \\n \
osc://.*/.\* http://somemirror.org/sources/ \\n \
p4://.*/.\* http://somemirror.org/sources/ \\n \
svn://.*/.\* http://somemirror.org/sources/ \\n"
MIRRORS =+ "\
ftp://.*/.\* http://somemirror.org/sources/ \\n \
http://.*/.\* http://somemirror.org/sources/ \\n \
https://.*/.\* http://somemirror.org/sources/ \\n"
It is useful to note that BitBake
supports cross-URLs. It is possible to mirror a Git repository on an
HTTP server as a tarball. This is what the ``git://`` mapping in the
previous example does.
Since network accesses are slow, BitBake maintains a cache of files
downloaded from the network. Any source files that are not local (i.e.
downloaded from the Internet) are placed into the download directory,
which is specified by the :term:`DL_DIR` variable.
File integrity is of key importance for reproducing builds. For
non-local archive downloads, the fetcher code can verify SHA-256 and MD5
checksums to ensure the archives have been downloaded correctly. You can
specify these checksums by using the :term:`SRC_URI` variable with the
appropriate varflags as follows::
SRC_URI[md5sum] = "value"
SRC_URI[sha256sum] = "value"
You can also specify the checksums as
parameters on the :term:`SRC_URI` as shown below::
SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
If multiple URIs exist, you can specify the checksums either directly as
in the previous example, or you can name the URLs. The following syntax
shows how you name the URIs::
SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
After a file has been downloaded and
has had its checksum checked, a ".done" stamp is placed in :term:`DL_DIR`.
BitBake uses this stamp during subsequent builds to avoid downloading or
comparing a checksum for the file again.
.. note::
It is assumed that local storage is safe from data corruption. If
this were not the case, there would be bigger issues to worry about.
If :term:`BB_STRICT_CHECKSUM` is set, any
download without a checksum triggers an error message. The
:term:`BB_NO_NETWORK` variable can be used to
make any attempted network access a fatal error, which is useful for
checking that mirrors are complete as well as other things.
If :term:`BB_CHECK_SSL_CERTS` is set to ``0`` then SSL certificate checking will
be disabled. This variable defaults to ``1`` so SSL certificates are normally
checked.
.. _bb-the-unpack:
The Unpack
==========
The unpack process usually immediately follows the download. For all
URLs except Git URLs, BitBake uses the common ``unpack`` method.
A number of parameters exist that you can specify within the URL to
govern the behavior of the unpack stage:
- *unpack:* Controls whether the URL components are unpacked. If set to
"1", which is the default, the components are unpacked. If set to
"0", the unpack stage leaves the file alone. This parameter is useful
when you want an archive to be copied in and not be unpacked.
- *dos:* Applies to ``.zip`` and ``.jar`` files and specifies whether
to use DOS line ending conversion on text files.
- *subdir:* Unpacks the specific URL to the specified subdirectory
within the root directory.
The unpack call automatically decompresses and extracts files with ".Z",
".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm". ".srpm", ".deb" and
".bz2" extensions as well as various combinations of tarball extensions.
As mentioned, the Git fetcher has its own unpack method that is
optimized to work with Git trees. Basically, this method works by
cloning the tree into the final directory. The process is completed
using references so that there is only one central copy of the Git
metadata needed.
.. _bb-fetchers:
Fetchers
========
As mentioned earlier, the URL prefix determines which fetcher submodule
BitBake uses. Each submodule can support different URL parameters, which
are described in the following sections.
.. _local-file-fetcher:
Local file fetcher (``file://``)
--------------------------------
This submodule handles URLs that begin with ``file://``. The filename
you specify within the URL can be either an absolute or relative path to
a file. If the filename is relative, the contents of the
:term:`FILESPATH` variable is used in the same way
``PATH`` is used to find executables. If the file cannot be found, it is
assumed that it is available in :term:`DL_DIR` by the
time the ``download()`` method is called.
If you specify a directory, the entire directory is unpacked.
Here are a couple of example URLs, the first relative and the second
absolute::
SRC_URI = "file://relativefile.patch"
SRC_URI = "file:///Users/ich/very_important_software"
.. _http-ftp-fetcher:
HTTP/FTP wget fetcher (``http://``, ``ftp://``, ``https://``)
-------------------------------------------------------------
This fetcher obtains files from web and FTP servers. Internally, the
fetcher uses the wget utility.
The executable and parameters used are specified by the
``FETCHCMD_wget`` variable, which defaults to sensible values. The
fetcher supports a parameter "downloadfilename" that allows the name of
the downloaded file to be specified. Specifying the name of the
downloaded file is useful for avoiding collisions in
:term:`DL_DIR` when dealing with multiple files that
have the same name.
Some example URLs are as follows::
SRC_URI = "http://oe.handhelds.org/not_there.aac"
SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
.. note::
Because URL parameters are delimited by semi-colons, this can
introduce ambiguity when parsing URLs that also contain semi-colons,
for example::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
Such URLs should should be modified by replacing semi-colons with '&'
characters::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
In most cases this should work. Treating semi-colons and '&' in
queries identically is recommended by the World Wide Web Consortium
(W3C). Note that due to the nature of the URL, you may have to
specify the name of the downloaded file as well::
SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"
.. _cvs-fetcher:
CVS fetcher (``(cvs://``)
-------------------------
This submodule handles checking out files from the CVS version control
system. You can configure it using a number of different variables:
- :term:`FETCHCMD_cvs <FETCHCMD>`: The name of the executable to use when running
the ``cvs`` command. This name is usually "cvs".
- :term:`SRCDATE`: The date to use when fetching the CVS source code. A
special value of "now" causes the checkout to be updated on every
build.
- :term:`CVSDIR`: Specifies where a temporary
checkout is saved. The location is often ``DL_DIR/cvs``.
- CVS_PROXY_HOST: The name to use as a "proxy=" parameter to the
``cvs`` command.
- CVS_PROXY_PORT: The port number to use as a "proxyport="
parameter to the ``cvs`` command.
As well as the standard username and password URL syntax, you can also
configure the fetcher with various URL parameters:
The supported parameters are as follows:
- *"method":* The protocol over which to communicate with the CVS
server. By default, this protocol is "pserver". If "method" is set to
"ext", BitBake examines the "rsh" parameter and sets ``CVS_RSH``. You
can use "dir" for local directories.
- *"module":* Specifies the module to check out. You must supply this
parameter.
- *"tag":* Describes which CVS TAG should be used for the checkout. By
default, the TAG is empty.
- *"date":* Specifies a date. If no "date" is specified, the
:term:`SRCDATE` of the configuration is used to
checkout a specific date. The special value of "now" causes the
checkout to be updated on every build.
- *"localdir":* Used to rename the module. Effectively, you are
renaming the output directory to which the module is unpacked. You
are forcing the module into a special directory relative to
:term:`CVSDIR`.
- *"rsh":* Used in conjunction with the "method" parameter.
- *"scmdata":* Causes the CVS metadata to be maintained in the tarball
the fetcher creates when set to "keep". The tarball is expanded into
the work directory. By default, the CVS metadata is removed.
- *"fullpath":* Controls whether the resulting checkout is at the
module level, which is the default, or is at deeper paths.
- *"norecurse":* Causes the fetcher to only checkout the specified
directory with no recurse into any subdirectories.
- *"port":* The port to which the CVS server connects.
Some example URLs are as follows::
SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
.. _svn-fetcher:
Subversion (SVN) Fetcher (``svn://``)
-------------------------------------
This fetcher submodule fetches code from the Subversion source control
system. The executable used is specified by ``FETCHCMD_svn``, which
defaults to "svn". The fetcher's temporary working directory is set by
:term:`SVNDIR`, which is usually ``DL_DIR/svn``.
The supported parameters are as follows:
- *"module":* The name of the svn module to checkout. You must provide
this parameter. You can think of this parameter as the top-level
directory of the repository data you want.
- *"path_spec":* A specific directory in which to checkout the
specified svn module.
- *"protocol":* The protocol to use, which defaults to "svn". If
"protocol" is set to "svn+ssh", the "ssh" parameter is also used.
- *"rev":* The revision of the source code to checkout.
- *"scmdata":* Causes the ".svn" directories to be available during
compile-time when set to "keep". By default, these directories are
removed.
- *"ssh":* An optional parameter used when "protocol" is set to
"svn+ssh". You can use this parameter to specify the ssh program used
by svn.
- *"transportuser":* When required, sets the username for the
transport. By default, this parameter is empty. The transport
username is different than the username used in the main URL, which
is passed to the subversion command.
Following are three examples using svn::
SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
.. _git-fetcher:
Git Fetcher (``git://``)
------------------------
This fetcher submodule fetches code from the Git source control system.
The fetcher works by creating a bare clone of the remote into
:term:`GITDIR`, which is usually ``DL_DIR/git2``. This
bare clone is then cloned into the work directory during the unpack
stage when a specific tree is checked out. This is done using alternates
and by reference to minimize the amount of duplicate data on the disk
and make the unpack process fast. The executable used can be set with
``FETCHCMD_git``.
This fetcher supports the following parameters:
- *"protocol":* The protocol used to fetch the files. The default is
"git" when a hostname is set. If a hostname is not set, the Git
protocol is "file". You can also use "http", "https", "ssh" and
"rsync".
- *"nocheckout":* Tells the fetcher to not checkout source code when
unpacking when set to "1". Set this option for the URL where there is
a custom routine to checkout code. The default is "0".
- *"rebaseable":* Indicates that the upstream Git repository can be
rebased. You should set this parameter to "1" if revisions can become
detached from branches. In this case, the source mirror tarball is
done per revision, which has a loss of efficiency. Rebasing the
upstream Git repository could cause the current revision to disappear
from the upstream repository. This option reminds the fetcher to
preserve the local cache carefully for future use. The default value
for this parameter is "0".
- *"nobranch":* Tells the fetcher to not check the SHA validation for
the branch when set to "1". The default is "0". Set this option for
the recipe that refers to the commit that is valid for a tag instead
of the branch.
- *"bareclone":* Tells the fetcher to clone a bare clone into the
destination directory without checking out a working tree. Only the
raw Git metadata is provided. This parameter implies the "nocheckout"
parameter as well.
- *"branch":* The branch(es) of the Git tree to clone. If unset, this
is assumed to be "master". The number of branch parameters much match
the number of name parameters.
- *"rev":* The revision to use for the checkout. The default is
"master".
- *"tag":* Specifies a tag to use for the checkout. To correctly
resolve tags, BitBake must access the network. For that reason, tags
are often not used. As far as Git is concerned, the "tag" parameter
behaves effectively the same as the "rev" parameter.
- *"subpath":* Limits the checkout to a specific subpath of the tree.
By default, the whole tree is checked out.
- *"destsuffix":* The name of the path in which to place the checkout.
By default, the path is ``git/``.
- *"usehead":* Enables local ``git://`` URLs to use the current branch
HEAD as the revision for use with ``AUTOREV``. The "usehead"
parameter implies no branch and only works when the transfer protocol
is ``file://``.
Here are some example URLs::
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
.. note::
When using ``git`` as the fetcher of the main source code of your software,
``S`` should be set accordingly::
S = "${WORKDIR}/git"
.. note::
Specifying passwords directly in ``git://`` urls is not supported.
There are several reasons: :term:`SRC_URI` is often written out to logs and
other places, and that could easily leak passwords; it is also all too
easy to share metadata without removing passwords. SSH keys, ``~/.netrc``
and ``~/.ssh/config`` files can be used as alternatives.
.. _gitsm-fetcher:
Git Submodule Fetcher (``gitsm://``)
------------------------------------
This fetcher submodule inherits from the :ref:`Git
fetcher<bitbake-user-manual/bitbake-user-manual-fetching:git fetcher
(\`\`git://\`\`)>` and extends that fetcher's behavior by fetching a
repository's submodules. :term:`SRC_URI` is passed to the Git fetcher as
described in the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git
fetcher (\`\`git://\`\`)` section.
.. note::
You must clean a recipe when switching between '``git://``' and
'``gitsm://``' URLs.
The Git Submodules fetcher is not a complete fetcher implementation.
The fetcher has known issues where it does not use the normal source
mirroring infrastructure properly. Further, the submodule sources it
fetches are not visible to the licensing and source archiving
infrastructures.
.. _clearcase-fetcher:
ClearCase Fetcher (``ccrc://``)
-------------------------------
This fetcher submodule fetches code from a
`ClearCase <http://en.wikipedia.org/wiki/Rational_ClearCase>`__
repository.
To use this fetcher, make sure your recipe has proper
:term:`SRC_URI`, :term:`SRCREV`, and
:term:`PV` settings. Here is an example::
SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
SRCREV = "EXAMPLE_CLEARCASE_TAG"
PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
The fetcher uses the ``rcleartool`` or
``cleartool`` remote client, depending on which one is available.
Following are options for the :term:`SRC_URI` statement:
- *vob*: The name, which must include the prepending "/" character,
of the ClearCase VOB. This option is required.
- *module*: The module, which must include the prepending "/"
character, in the selected VOB.
.. note::
The module and vob options are combined to create the load rule in the
view config spec. As an example, consider the vob and module values from
the SRC_URI statement at the start of this section. Combining those values
results in the following::
load /example_vob/example_module
- *proto*: The protocol, which can be either ``http`` or ``https``.
By default, the fetcher creates a configuration specification. If you
want this specification written to an area other than the default, use
the ``CCASE_CUSTOM_CONFIG_SPEC`` variable in your recipe to define where
the specification is written.
.. note::
the SRCREV loses its functionality if you specify this variable. However,
SRCREV is still used to label the archive after a fetch even though it does
not define what is fetched.
Here are a couple of other behaviors worth mentioning:
- When using ``cleartool``, the login of ``cleartool`` is handled by
the system. The login require no special steps.
- In order to use ``rcleartool`` with authenticated users, an
"rcleartool login" is necessary before using the fetcher.
.. _perforce-fetcher:
Perforce Fetcher (``p4://``)
----------------------------
This fetcher submodule fetches code from the
`Perforce <https://www.perforce.com/>`__ source control system. The
executable used is specified by ``FETCHCMD_p4``, which defaults to "p4".
The fetcher's temporary working directory is set by
:term:`P4DIR`, which defaults to "DL_DIR/p4".
The fetcher does not make use of a perforce client, instead it
relies on ``p4 files`` to retrieve a list of
files and ``p4 print`` to transfer the content
of those files locally.
To use this fetcher, make sure your recipe has proper
:term:`SRC_URI`, :term:`SRCREV`, and
:term:`PV` values. The p4 executable is able to use the
config file defined by your system's ``P4CONFIG`` environment variable
in order to define the Perforce server URL and port, username, and
password if you do not wish to keep those values in a recipe itself. If
you choose not to use ``P4CONFIG``, or to explicitly set variables that
``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is
the server's URL and port number, and you can specify a username and
password directly in your recipe within :term:`SRC_URI`.
Here is an example that relies on ``P4CONFIG`` to specify the server URL
and port, username, and password, and fetches the Head Revision::
SRC_URI = "p4://example-depot/main/source/..."
SRCREV = "${AUTOREV}"
PV = "p4-${SRCPV}"
S = "${WORKDIR}/p4"
Here is an example that specifies the server URL and port, username, and
password, and fetches a Revision based on a Label::
P4PORT = "tcp:p4server.example.net:1666"
SRC_URI = "p4://user:passwd@example-depot/main/source/..."
SRCREV = "release-1.0"
PV = "p4-${SRCPV}"
S = "${WORKDIR}/p4"
.. note::
You should always set S to "${WORKDIR}/p4" in your recipe.
By default, the fetcher strips the depot location from the local file paths. In
the above example, the content of ``example-depot/main/source/`` will be placed
in ``${WORKDIR}/p4``. For situations where preserving parts of the remote depot
paths locally is desirable, the fetcher supports two parameters:
- *"module":*
The top-level depot location or directory to fetch. The value of this
parameter can also point to a single file within the depot, in which case
the local file path will include the module path.
- *"remotepath":*
When used with the value "``keep``", the fetcher will mirror the full depot
paths locally for the specified location, even in combination with the
``module`` parameter.
Here is an example use of the the ``module`` parameter::
SRC_URI = "p4://user:passwd@example-depot/main;module=source/..."
In this case, the content of the top-level directory ``source/`` will be fetched
to ``${P4DIR}``, including the directory itself. The top-level directory will
be accesible at ``${P4DIR}/source/``.
Here is an example use of the the ``remotepath`` parameter::
SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep"
In this case, the content of the top-level directory ``source/`` will be fetched
to ``${P4DIR}``, but the complete depot paths will be mirrored locally. The
top-level directory will be accessible at
``${P4DIR}/example-depot/main/source/``.
.. _repo-fetcher:
Repo Fetcher (``repo://``)
--------------------------
This fetcher submodule fetches code from ``google-repo`` source control
system. The fetcher works by initiating and syncing sources of the
repository into :term:`REPODIR`, which is usually
``${DL_DIR}/repo``.
This fetcher supports the following parameters:
- *"protocol":* Protocol to fetch the repository manifest (default:
git).
- *"branch":* Branch or tag of repository to get (default: master).
- *"manifest":* Name of the manifest file (default: ``default.xml``).
Here are some example URLs::
SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
.. _az-fetcher:
Az Fetcher (``az://``)
--------------------------
This submodule fetches data from an
`Azure Storage account <https://docs.microsoft.com/en-us/azure/storage/>`__ ,
it inherits its functionality from the HTTP wget fetcher, but modifies its
behavior to accomodate the usage of a
`Shared Access Signature (SAS) <https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview>`__
for non-public data.
Such functionality is set by the variable:
- :term:`AZ_SAS`: The Azure Storage Shared Access Signature provides secure
delegate access to resources, if this variable is set, the Az Fetcher will
use it when fetching artifacts from the cloud.
You can specify the AZ_SAS variable as shown below::
AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"
Here is an example URL::
SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>"
It can also be used when setting mirrors definitions using the :term:`PREMIRRORS` variable.
Other Fetchers
--------------
Fetch submodules also exist for the following:
- Bazaar (``bzr://``)
- Mercurial (``hg://``)
- npm (``npm://``)
- OSC (``osc://``)
- Secure FTP (``sftp://``)
- Secure Shell (``ssh://``)
- Trees using Git Annex (``gitannex://``)
No documentation currently exists for these lesser used fetcher
submodules. However, you might find the code helpful and readable.
Auto Revisions
==============
We need to document ``AUTOREV`` and :term:`SRCREV_FORMAT` here.

View File

@@ -0,0 +1,622 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter>
<title>File Download Support</title>
<para>
BitBake's fetch module is a standalone piece of library code
that deals with the intricacies of downloading source code
and files from remote systems.
Fetching source code is one of the corner stones of building software.
As such, this module forms an important part of BitBake.
</para>
<para>
The current fetch module is called "fetch2" and refers to the
fact that it is the second major version of the API.
The original version is obsolete and removed from the codebase.
Thus, in all cases, "fetch" refers to "fetch2" in this
manual.
</para>
<section id='the-download-fetch'>
<title>The Download (Fetch)</title>
<para>
BitBake takes several steps when fetching source code or files.
The fetcher codebase deals with two distinct processes in order:
obtaining the files from somewhere (cached or otherwise)
and then unpacking those files into a specific location and
perhaps in a specific way.
Getting and unpacking the files is often optionally followed
by patching.
Patching, however, is not covered by this module.
</para>
<para>
The code to execute the first part of this process, a fetch,
looks something like the following:
<literallayout class='monospaced'>
src_uri = (d.getVar('SRC_URI', True) or "").split()
fetcher = bb.fetch2.Fetch(src_uri, d)
fetcher.download()
</literallayout>
This code sets up an instance of the fetch class.
The instance uses a space-separated list of URLs from the
<link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
variable and then calls the <filename>download</filename>
method to download the files.
</para>
<para>
The instantiation of the fetch class is usually followed by:
<literallayout class='monospaced'>
rootdir = l.getVar('WORKDIR', True)
fetcher.unpack(rootdir)
</literallayout>
This code unpacks the downloaded files to the
specified by <filename>WORKDIR</filename>.
<note>
For convenience, the naming in these examples matches
the variables used by OpenEmbedded.
</note>
The <filename>SRC_URI</filename> and <filename>WORKDIR</filename>
variables are not coded into the fetcher.
They variables can (and are) called with different variable names.
In OpenEmbedded for example, the shared state (sstate) code uses
the fetch module to fetch the sstate files.
</para>
<para>
When the <filename>download()</filename> method is called,
BitBake tries to fulfill the URLs by looking for source files
in a specific search order:
<itemizedlist>
<listitem><para><emphasis>Pre-mirror Sites:</emphasis>
BitBake first uses pre-mirrors to try and find source files.
These locations are defined using the
<link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
variable.
</para></listitem>
<listitem><para><emphasis>Source URI:</emphasis>
If pre-mirrors fail, BitBake uses the original URL (e.g from
<filename>SRC_URI</filename>).
</para></listitem>
<listitem><para><emphasis>Mirror Sites:</emphasis>
If fetch failures occur, BitBake next uses mirror location as
defined by the
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
variable.
</para></listitem>
</itemizedlist>
</para>
<para>
For each URL passed to the fetcher, the fetcher
calls the submodule that handles that particular URL type.
This behavior can be the source of some confusion when you
are providing URLs for the <filename>SRC_URI</filename>
variable.
Consider the following two URLs:
<literallayout class='monospaced'>
http://git.yoctoproject.org/git/poky;protocol=git
git://git.yoctoproject.org/git/poky;protocol=http
</literallayout>
In the former case, the URL is passed to the
<filename>wget</filename> fetcher, which does not
understand "git".
Therefore, the latter case is the correct form since the
Git fetcher does know how to use HTTP as a transport.
</para>
<para>
Here are some examples that show commonly used mirror
definitions:
<literallayout class='monospaced'>
PREMIRRORS ?= "\
bzr://.*/.* http://somemirror.org/sources/ \n \
cvs://.*/.* http://somemirror.org/sources/ \n \
git://.*/.* http://somemirror.org/sources/ \n \
hg://.*/.* http://somemirror.org/sources/ \n \
osc://.*/.* http://somemirror.org/sources/ \n \
p4://.*/.* http://somemirror.org/sources/ \n \
svn://.*/.* http://somemirror.org/sources/ \n"
MIRRORS =+ "\
ftp://.*/.* http://somemirror.org/sources/ \n \
http://.*/.* http://somemirror.org/sources/ \n \
https://.*/.* http://somemirror.org/sources/ \n"
</literallayout>
It is useful to note that BitBake supports
cross-URLs.
It is possible to mirror a Git repository on an HTTP
server as a tarball.
This is what the <filename>git://</filename> mapping in
the previous example does.
</para>
<para>
Since network accesses are slow, Bitbake maintains a
cache of files downloaded from the network.
Any source files that are not local (i.e.
downloaded from the Internet) are placed into the download
directory, which is specified by the
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
variable.
</para>
<para>
File integrity is of key importance for reproducing builds.
For non-local archive downloads, the fetcher code can verify
sha256 and md5 checksums to ensure the archives have been
downloaded correctly.
You can specify these checksums by using the
<filename>SRC_URI</filename> variable with the appropriate
varflags as follows:
<literallayout class='monospaced'>
SRC_URI[md5sum] = "value"
SRC_URI[sha256sum] = "value"
</literallayout>
You can also specify the checksums as parameters on the
<filename>SRC_URI</filename> as shown below:
<literallayout class='monospaced'>
SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
</literallayout>
If multiple URIs exist, you can specify the checksums either
directly as in the previous example, or you can name the URLs.
The following syntax shows how you name the URIs:
<literallayout class='monospaced'>
SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
</literallayout>
After a file has been downloaded and has had its checksum checked,
a ".done" stamp is placed in <filename>DL_DIR</filename>.
BitBake uses this stamp during subsequent builds to avoid
downloading or comparing a checksum for the file again.
<note>
It is assumed that local storage is safe from data corruption.
If this were not the case, there would be bigger issues to worry about.
</note>
</para>
<para>
If
<link linkend='var-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link>
is set, any download without a checksum triggers an
error message.
The
<link linkend='var-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link>
variable can be used to make any attempted network access a fatal
error, which is useful for checking that mirrors are complete
as well as other things.
</para>
</section>
<section id='bb-the-unpack'>
<title>The Unpack</title>
<para>
The unpack process usually immediately follows the download.
For all URLs except Git URLs, BitBake uses the common
<filename>unpack</filename> method.
</para>
<para>
A number of parameters exist that you can specify within the
URL to govern the behavior of the unpack stage:
<itemizedlist>
<listitem><para><emphasis>unpack:</emphasis>
Controls whether the URL components are unpacked.
If set to "1", which is the default, the components
are unpacked.
If set to "0", the unpack stage leaves the file alone.
This parameter is useful when you want an archive to be
copied in and not be unpacked.
</para></listitem>
<listitem><para><emphasis>dos:</emphasis>
Applies to <filename>.zip</filename> and
<filename>.jar</filename> files and specifies whether to
use DOS line ending conversion on text files.
</para></listitem>
<listitem><para><emphasis>basepath:</emphasis>
Instructs the unpack stage to strip the specified
directories from the source path when unpacking.
</para></listitem>
<listitem><para><emphasis>subdir:</emphasis>
Unpacks the specific URL to the specified subdirectory
within the root directory.
</para></listitem>
</itemizedlist>
The unpack call automatically decompresses and extracts files
with ".Z", ".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm".
".srpm", ".deb" and ".bz2" extensions as well as various combinations
of tarball extensions.
</para>
<para>
As mentioned, the Git fetcher has its own unpack method that
is optimized to work with Git trees.
Basically, this method works by cloning the tree into the final
directory.
The process is completed using references so that there is
only one central copy of the Git metadata needed.
</para>
</section>
<section id='bb-fetchers'>
<title>Fetchers</title>
<para>
As mentioned earlier, the URL prefix determines which
fetcher submodule BitBake uses.
Each submodule can support different URL parameters,
which are described in the following sections.
</para>
<section id='local-file-fetcher'>
<title>Local file fetcher (<filename>file://</filename>)</title>
<para>
This submodule handles URLs that begin with
<filename>file://</filename>.
The filename you specify with in the URL can
either be an absolute or relative path to a file.
If the filename is relative, the contents of the
<link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
variable is used in the same way
<filename>PATH</filename> is used to find executables.
Failing that,
<link linkend='var-FILESDIR'><filename>FILESDIR</filename></link>
is used to find the appropriate relative file.
<note>
<filename>FILESDIR</filename> is deprecated and can
be replaced with <filename>FILESPATH</filename>.
Because <filename>FILESDIR</filename> is likely to be
removed, you should not use this variable in any new code.
</note>
If the file cannot be found, it is assumed that it is available in
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
by the time the <filename>download()</filename> method is called.
</para>
<para>
If you specify a directory, the entire directory is
unpacked.
</para>
<para>
Here are some example URLs:
<literallayout class='monospaced'>
SRC_URI = "file://relativefile.patch"
SRC_URI = "file://relativefile.patch;this=ignored"
SRC_URI = "file:///Users/ich/very_important_software"
</literallayout>
</para>
</section>
<section id='cvs-fetcher'>
<title>CVS fetcher (<filename>(cvs://</filename>)</title>
<para>
This submodule handles checking out files from the
CVS version control system.
You can configure it using a number of different variables:
<itemizedlist>
<listitem><para><emphasis><filename>FETCHCMD_cvs</filename>:</emphasis>
The name of the executable to use when running
the <filename>cvs</filename> command.
This name is usually "cvs".
</para></listitem>
<listitem><para><emphasis><filename>SRCDATE</filename>:</emphasis>
The date to use when fetching the CVS source code.
A special value of "now" causes the checkout to
be updated on every build.
</para></listitem>
<listitem><para><emphasis><filename>CVSDIR</filename>:</emphasis>
Specifies where a temporary checkout is saved.
The location is often <filename>DL_DIR/cvs</filename>.
</para></listitem>
<listitem><para><emphasis><filename>CVS_PROXY_HOST</filename>:</emphasis>
The name to use as a "proxy=" parameter to the
<filename>cvs</filename> command.
</para></listitem>
<listitem><para><emphasis><filename>CVS_PROXY_PORT</filename>:</emphasis>
The port number to use as a "proxyport=" parameter to
the <filename>cvs</filename> command.
</para></listitem>
</itemizedlist>
As well as the standard username and password URL syntax,
you can also configure the fetcher with various URL parameters:
</para>
<para>
The supported parameters are as follows:
<itemizedlist>
<listitem><para><emphasis>"method":</emphasis>
The protocol over which to communicate with the cvs server.
By default, this protocol is "pserver".
If "method" is set to "ext", BitBake examines the
"rsh" parameter and sets <filename>CVS_RSH</filename>.
You can use "dir" for local directories.
</para></listitem>
<listitem><para><emphasis>"module":</emphasis>
Specifies the module to check out.
You must supply this parameter.
</para></listitem>
<listitem><para><emphasis>"tag":</emphasis>
Describes which CVS TAG should be used for
the checkout.
By default, the TAG is empty.
</para></listitem>
<listitem><para><emphasis>"date":</emphasis>
Specifies a date.
If no "date" is specified, the
<link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
of the configuration is used to checkout a specific date.
The special value of "now" causes the checkout to be
updated on every build.
</para></listitem>
<listitem><para><emphasis>"localdir":</emphasis>
Used to rename the module.
Effectively, you are renaming the output directory
to which the module is unpacked.
You are forcing the module into a special
directory relative to <filename>CVSDIR</filename>.
</para></listitem>
<listitem><para><emphasis>"rsh"</emphasis>
Used in conjunction with the "method" parameter.
</para></listitem>
<listitem><para><emphasis>"scmdata":</emphasis>
Causes the CVS metadata to be maintained in the tarball
the fetcher creates when set to "keep".
The tarball is expanded into the work directory.
By default, the CVS metadata is removed.
</para></listitem>
<listitem><para><emphasis>"fullpath":</emphasis>
Controls whether the resulting checkout is at the
module level, which is the default, or is at deeper
paths.
</para></listitem>
<listitem><para><emphasis>"norecurse":</emphasis>
Causes the fetcher to only checkout the specified
directory with no recurse into any subdirectories.
</para></listitem>
<listitem><para><emphasis>"port":</emphasis>
The port to which the CVS server connects.
</para></listitem>
</itemizedlist>
Some example URLs are as follows:
<literallayout class='monospaced'>
SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
</literallayout>
</para>
</section>
<section id='http-ftp-fetcher'>
<title>HTTP/FTP wget fetcher (<filename>http://</filename>, <filename>ftp://</filename>, <filename>https://</filename>)</title>
<para>
This fetcher obtains files from web and FTP servers.
Internally, the fetcher uses the wget utility.
</para>
<para>
The executable and parameters used are specified by the
<filename>FETCHCMD_wget</filename> variable, which defaults
to a sensible values.
The fetcher supports a parameter "downloadfilename" that
allows the name of the downloaded file to be specified.
Specifying the name of the downloaded file is useful
for avoiding collisions in
<link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
when dealing with multiple files that have the same name.
</para>
<para>
Some example URLs are as follows:
<literallayout class='monospaced'>
SRC_URI = "http://oe.handhelds.org/not_there.aac"
SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
SRC_URI = "ftp://you@oe.handheld.sorg/home/you/secret.plan"
</literallayout>
</para>
</section>
<section id='svn-fetcher'>
<title>Subversion (SVN) Fetcher (<filename>svn://</filename>)</title>
<para>
This fetcher submodule fetches code from the
Subversion source control system.
The executable used is specified by
<filename>FETCHCMD_svn</filename>, which defaults
to "svn".
The fetcher's temporary working directory is set
by <filename>SVNDIR</filename>, which is usually
<filename>DL_DIR/svn</filename>.
</para>
<para>
The supported parameters are as follows:
<itemizedlist>
<listitem><para><emphasis>"module":</emphasis>
The name of the svn module to checkout.
You must provide this parameter.
You can think of this parameter as the top-level
directory of the repository data you want.
</para></listitem>
<listitem><para><emphasis>"protocol":</emphasis>
The protocol to use, which defaults to "svn".
Other options are "svn+ssh" and "rsh".
For "rsh", the "rsh" parameter is also used.
</para></listitem>
<listitem><para><emphasis>"rev":</emphasis>
The revision of the source code to checkout.
</para></listitem>
<listitem><para><emphasis>"date":</emphasis>
The date of the source code to checkout.
Specific revisions are generally much safer to checkout
rather than by date as they do not involve timezones
(e.g. they are much more deterministic).
</para></listitem>
<listitem><para><emphasis>"scmdata":</emphasis>
Causes the “.svn” directories to be available during
compile-time when set to "keep".
By default, these directories are removed.
</para></listitem>
</itemizedlist>
Following are two examples using svn:
<literallayout class='monospaced'>
SRC_URI = "svn://svn.oe.handhelds.org/svn;module=vip;proto=http;rev=667"
SRC_URI = "svn://svn.oe.handhelds.org/svn/;module=opie;proto=svn+ssh;date=20060126"
</literallayout>
</para>
</section>
<section id='git-fetcher'>
<title>GIT Fetcher (<filename>git://</filename>)</title>
<para>
This fetcher submodule fetches code from the Git
source control system.
The fetcher works by creating a bare clone of the
remote into <filename>GITDIR</filename>, which is
usually <filename>DL_DIR/git</filename>.
This bare clone is then cloned into the work directory during the
unpack stage when a specific tree is checked out.
This is done using alternates and by reference to
minimize the amount of duplicate data on the disk and
make the unpack process fast.
The executable used can be set with
<filename>FETCHCMD_git</filename>.
</para>
<para>
This fetcher supports the following parameters:
<itemizedlist>
<listitem><para><emphasis>"protocol":</emphasis>
The protocol used to fetch the files.
The default is "git" when a hostname is set.
If a hostname is not set, the Git protocol is "file".
You can also use "http", "https", "ssh" and "rsync".
</para></listitem>
<listitem><para><emphasis>"nocheckout":</emphasis>
Tells the fetcher to not checkout source code when
unpacking when set to "1".
Set this option for the URL where there is a custom
routine to checkout code.
The default is "0".
</para></listitem>
<listitem><para><emphasis>"rebaseable":</emphasis>
Indicates that the upstream Git repository can be rebased.
You should set this parameter to "1" if
revisions can become detached from branches.
In this case, the source mirror tarball is done per
revision, which has a loss of efficiency.
Rebasing the upstream Git repository could cause the
current revision to disappear from the upstream repository.
This option reminds the fetcher to preserve the local cache
carefully for future use.
The default value for this parameter is "0".
</para></listitem>
<listitem><para><emphasis>"nobranch":</emphasis>
Tells the fetcher to not check the SHA validation
for the branch when set to "1".
The default is "0".
Set this option for the recipe that refers to
the commit that is valid for a tag instead of
the branch.
</para></listitem>
<listitem><para><emphasis>"bareclone":</emphasis>
Tells the fetcher to clone a bare clone into the
destination directory without checking out a working tree.
Only the raw Git metadata is provided.
This parameter implies the "nocheckout" parameter as well.
</para></listitem>
<listitem><para><emphasis>"branch":</emphasis>
The branch(es) of the Git tree to clone.
If unset, this is assumed to be "master".
The number of branch parameters much match the number of
name parameters.
</para></listitem>
<listitem><para><emphasis>"rev":</emphasis>
The revision to use for the checkout.
The default is "master".
</para></listitem>
<listitem><para><emphasis>"tag":</emphasis>
Specifies a tag to use for the checkout.
To correctly resolve tags, BitBake must access the
network.
For that reason, tags are often not used.
As far as Git is concerned, the "tag" parameter behaves
effectively the same as the "revision" parameter.
</para></listitem>
<listitem><para><emphasis>"subpath":</emphasis>
Limits the checkout to a specific subpath of the tree.
By default, the whole tree is checked out.
</para></listitem>
<listitem><para><emphasis>"destsuffix":</emphasis>
The name of the path in which to place the checkout.
By default, the path is <filename>git/</filename>.
</para></listitem>
</itemizedlist>
Here are some example URLs:
<literallayout class='monospaced'>
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
</literallayout>
</para>
</section>
<section id='other-fetchers'>
<title>Other Fetchers</title>
<para>
Fetch submodules also exist for the following:
<itemizedlist>
<listitem><para>
Bazaar (<filename>bzr://</filename>)
</para></listitem>
<listitem><para>
Perforce (<filename>p4://</filename>)
</para></listitem>
<listitem><para>
Git Submodules (<filename>gitsm://</filename>)
</para></listitem>
<listitem><para>
Trees using Git Annex (<filename>gitannex://</filename>)
</para></listitem>
<listitem><para>
Secure FTP (<filename>sftp://</filename>)
</para></listitem>
<listitem><para>
Secure Shell (<filename>ssh://</filename>)
</para></listitem>
<listitem><para>
Repo (<filename>repo://</filename>)
</para></listitem>
<listitem><para>
OSC (<filename>osc://</filename>)
</para></listitem>
<listitem><para>
Mercurial (<filename>hg://</filename>)
</para></listitem>
</itemizedlist>
No documentation currently exists for these lesser used
fetcher submodules.
However, you might find the code helpful and readable.
</para>
</section>
</section>
<section id='auto-revisions'>
<title>Auto Revisions</title>
<para>
We need to document <filename>AUTOREV</filename> and
<filename>SRCREV_FORMAT</filename> here.
</para>
</section>
</chapter>

View File

@@ -1,415 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
===================
Hello World Example
===================
BitBake Hello World
===================
The simplest example commonly used to demonstrate any new programming
language or tool is the "`Hello
World <http://en.wikipedia.org/wiki/Hello_world_program>`__" example.
This appendix demonstrates, in tutorial form, Hello World within the
context of BitBake. The tutorial describes how to create a new project
and the applicable metadata files necessary to allow BitBake to build
it.
Obtaining BitBake
=================
See the :ref:`bitbake-user-manual/bitbake-user-manual-hello:obtaining bitbake` section for
information on how to obtain BitBake. Once you have the source code on
your machine, the BitBake directory appears as follows::
$ ls -al
total 100
drwxrwxr-x. 9 wmat wmat 4096 Jan 31 13:44 .
drwxrwxr-x. 3 wmat wmat 4096 Feb 4 10:45 ..
-rw-rw-r--. 1 wmat wmat 365 Nov 26 04:55 AUTHORS
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 bin
drwxrwxr-x. 4 wmat wmat 4096 Jan 31 13:44 build
-rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 classes
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 conf
drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 contrib
-rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 doc
-rw-rw-r--. 1 wmat wmat 69 Nov 26 04:55 .gitignore
-rw-rw-r--. 1 wmat wmat 849 Nov 26 04:55 HEADER
drwxrwxr-x. 5 wmat wmat 4096 Jan 31 13:44 lib
-rw-rw-r--. 1 wmat wmat 195 Nov 26 04:55 MANIFEST.in
-rw-rw-r--. 1 wmat wmat 2887 Nov 26 04:55 TODO
At this point, you should have BitBake cloned to a directory that
matches the previous listing except for dates and user names.
Setting Up the BitBake Environment
==================================
First, you need to be sure that you can run BitBake. Set your working
directory to where your local BitBake files are and run the following
command::
$ ./bin/bitbake --version
BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
The console output tells you what version
you are running.
The recommended method to run BitBake is from a directory of your
choice. To be able to run BitBake from any directory, you need to add
the executable binary to your binary to your shell's environment
``PATH`` variable. First, look at your current ``PATH`` variable by
entering the following::
$ echo $PATH
Next, add the directory location
for the BitBake binary to the ``PATH``. Here is an example that adds the
``/home/scott-lenovo/bitbake/bin`` directory to the front of the
``PATH`` variable::
$ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
You should now be able to enter the ``bitbake`` command from the command
line while working from any directory.
The Hello World Example
=======================
The overall goal of this exercise is to build a complete "Hello World"
example utilizing task and layer concepts. Because this is how modern
projects such as OpenEmbedded and the Yocto Project utilize BitBake, the
example provides an excellent starting point for understanding BitBake.
To help you understand how to use BitBake to build targets, the example
starts with nothing but the ``bitbake`` command, which causes BitBake to
fail and report problems. The example progresses by adding pieces to the
build to eventually conclude with a working, minimal "Hello World"
example.
While every attempt is made to explain what is happening during the
example, the descriptions cannot cover everything. You can find further
information throughout this manual. Also, you can actively participate
in the :oe_lists:`/g/bitbake-devel`
discussion mailing list about the BitBake build tool.
.. note::
This example was inspired by and drew heavily from
`Mailing List post - The BitBake equivalent of "Hello, World!"
<https://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html>`_.
As stated earlier, the goal of this example is to eventually compile
"Hello World". However, it is unknown what BitBake needs and what you
have to provide in order to achieve that goal. Recall that BitBake
utilizes three types of metadata files:
:ref:`bitbake-user-manual/bitbake-user-manual-intro:configuration files`,
:ref:`bitbake-user-manual/bitbake-user-manual-intro:classes`, and
:ref:`bitbake-user-manual/bitbake-user-manual-intro:recipes`.
But where do they go? How does BitBake find
them? BitBake's error messaging helps you answer these types of
questions and helps you better understand exactly what is going on.
Following is the complete "Hello World" example.
#. **Create a Project Directory:** First, set up a directory for the
"Hello World" project. Here is how you can do so in your home
directory::
$ mkdir ~/hello
$ cd ~/hello
This is the directory that
BitBake will use to do all of its work. You can use this directory
to keep all the metafiles needed by BitBake. Having a project
directory is a good way to isolate your project.
#. **Run BitBake:** At this point, you have nothing but a project
directory. Run the ``bitbake`` command and see what it does::
$ bitbake
The BBPATH variable is not set and bitbake did not
find a conf/bblayers.conf file in the expected location.
Maybe you accidentally invoked bitbake from the wrong directory?
DEBUG: Removed the following variables from the environment:
GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
_, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
The majority of this output is specific to environment variables that
are not directly relevant to BitBake. However, the very first
message regarding the :term:`BBPATH` variable and the
``conf/bblayers.conf`` file is relevant.
When you run BitBake, it begins looking for metadata files. The
:term:`BBPATH` variable is what tells BitBake where
to look for those files. :term:`BBPATH` is not set and you need to set
it. Without :term:`BBPATH`, BitBake cannot find any configuration files
(``.conf``) or recipe files (``.bb``) at all. BitBake also cannot
find the ``bitbake.conf`` file.
#. **Setting BBPATH:** For this example, you can set :term:`BBPATH` in
the same manner that you set ``PATH`` earlier in the appendix. You
should realize, though, that it is much more flexible to set the
:term:`BBPATH` variable up in a configuration file for each project.
From your shell, enter the following commands to set and export the
:term:`BBPATH` variable::
$ BBPATH="projectdirectory"
$ export BBPATH
Use your actual project directory in the command. BitBake uses that
directory to find the metadata it needs for your project.
.. note::
When specifying your project directory, do not use the tilde
("~") character as BitBake does not expand that character as the
shell would.
#. **Run BitBake:** Now that you have :term:`BBPATH` defined, run the
``bitbake`` command again::
$ bitbake
ERROR: Traceback (most recent call last):
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
return func(fn, *args)
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
return bb.parse.handle(fn, data, include)
File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
return h['handle'](fn, data, include)
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
abs_fn = resolve_file(fn, data)
File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
raise IOError("file %s not found in %s" % (fn, bbpath))
IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
This sample output shows that BitBake could not find the
``conf/bitbake.conf`` file in the project directory. This file is
the first thing BitBake must find in order to build a target. And,
since the project directory for this example is empty, you need to
provide a ``conf/bitbake.conf`` file.
#. **Creating conf/bitbake.conf:** The ``conf/bitbake.conf`` includes
a number of configuration variables BitBake uses for metadata and
recipe files. For this example, you need to create the file in your
project directory and define some key BitBake variables. For more
information on the ``bitbake.conf`` file, see
https://git.openembedded.org/bitbake/tree/conf/bitbake.conf.
Use the following commands to create the ``conf`` directory in the
project directory::
$ mkdir conf
From within the ``conf`` directory,
use some editor to create the ``bitbake.conf`` so that it contains
the following::
PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
TMPDIR = "${TOPDIR}/tmp"
CACHE = "${TMPDIR}/cache"
STAMP = "${TMPDIR}/${PN}/stamps"
T = "${TMPDIR}/${PN}/work"
B = "${TMPDIR}/${PN}"
.. note::
Without a value for PN , the variables STAMP , T , and B , prevent more
than one recipe from working. You can fix this by either setting PN to
have a value similar to what OpenEmbedded and BitBake use in the default
bitbake.conf file (see previous example). Or, by manually updating each
recipe to set PN . You will also need to include PN as part of the STAMP
, T , and B variable definitions in the local.conf file.
The ``TMPDIR`` variable establishes a directory that BitBake uses
for build output and intermediate files other than the cached
information used by the
:ref:`bitbake-user-manual/bitbake-user-manual-execution:setscene`
process. Here, the ``TMPDIR`` directory is set to ``hello/tmp``.
.. tip::
You can always safely delete the tmp directory in order to rebuild a
BitBake target. The build process creates the directory for you when you
run BitBake.
For information about each of the other variables defined in this
example, check :term:`PN`, :term:`TOPDIR`, :term:`CACHE`, :term:`STAMP`,
:term:`T` or :term:`B` to take you to the definitions in the
glossary.
#. **Run BitBake:** After making sure that the ``conf/bitbake.conf`` file
exists, you can run the ``bitbake`` command again::
$ bitbake
ERROR: Traceback (most recent call last):
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
return func(fn, *args)
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
include(fn, file, lineno, d, "inherit")
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
In the sample output,
BitBake could not find the ``classes/base.bbclass`` file. You need
to create that file next.
#. **Creating classes/base.bbclass:** BitBake uses class files to
provide common code and functionality. The minimally required class
for BitBake is the ``classes/base.bbclass`` file. The ``base`` class
is implicitly inherited by every recipe. BitBake looks for the class
in the ``classes`` directory of the project (i.e ``hello/classes``
in this example).
Create the ``classes`` directory as follows::
$ cd $HOME/hello
$ mkdir classes
Move to the ``classes`` directory and then create the
``base.bbclass`` file by inserting this single line: addtask build
The minimal task that BitBake runs is the ``do_build`` task. This is
all the example needs in order to build the project. Of course, the
``base.bbclass`` can have much more depending on which build
environments BitBake is supporting.
#. **Run BitBake:** After making sure that the ``classes/base.bbclass``
file exists, you can run the ``bitbake`` command again::
$ bitbake
Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
BitBake is finally reporting
no errors. However, you can see that it really does not have
anything to do. You need to create a recipe that gives BitBake
something to do.
#. **Creating a Layer:** While it is not really necessary for such a
small example, it is good practice to create a layer in which to
keep your code separate from the general metadata used by BitBake.
Thus, this example creates and uses a layer called "mylayer".
.. note::
You can find additional information on layers in the
":ref:`bitbake-user-manual/bitbake-user-manual-intro:Layers`" section.
Minimally, you need a recipe file and a layer configuration file in
your layer. The configuration file needs to be in the ``conf``
directory inside the layer. Use these commands to set up the layer
and the ``conf`` directory::
$ cd $HOME
$ mkdir mylayer
$ cd mylayer
$ mkdir conf
Move to the ``conf`` directory and create a ``layer.conf`` file that has the
following::
BBPATH .= ":${LAYERDIR}"
BBFILES += "${LAYERDIR}/*.bb"
BBFILE_COLLECTIONS += "mylayer"
BBFILE_PATTERN_mylayer := "^${LAYERDIR_RE}/"
For information on these variables, click on :term:`BBFILES`,
:term:`LAYERDIR`, :term:`BBFILE_COLLECTIONS` or :term:`BBFILE_PATTERN_mylayer <BBFILE_PATTERN>`
to go to the definitions in the glossary.
You need to create the recipe file next. Inside your layer at the
top-level, use an editor and create a recipe file named
``printhello.bb`` that has the following::
DESCRIPTION = "Prints Hello World"
PN = 'printhello'
PV = '1'
python do_build() {
bb.plain("********************");
bb.plain("* *");
bb.plain("* Hello, World! *");
bb.plain("* *");
bb.plain("********************");
}
The recipe file simply provides
a description of the recipe, the name, version, and the ``do_build``
task, which prints out "Hello World" to the console. For more
information on :term:`DESCRIPTION`, :term:`PN` or :term:`PV`
follow the links to the glossary.
#. **Run BitBake With a Target:** Now that a BitBake target exists, run
the command and provide that target::
$ cd $HOME/hello
$ bitbake printhello
ERROR: no recipe files to build, check your BBPATH and BBFILES?
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
We have created the layer with the recipe and
the layer configuration file but it still seems that BitBake cannot
find the recipe. BitBake needs a ``conf/bblayers.conf`` that lists
the layers for the project. Without this file, BitBake cannot find
the recipe.
#. **Creating conf/bblayers.conf:** BitBake uses the
``conf/bblayers.conf`` file to locate layers needed for the project.
This file must reside in the ``conf`` directory of the project (i.e.
``hello/conf`` for this example).
Set your working directory to the ``hello/conf`` directory and then
create the ``bblayers.conf`` file so that it contains the following::
BBLAYERS ?= " \
/home/<you>/mylayer \
"
You need to provide your own information for ``you`` in the file.
#. **Run BitBake With a Target:** Now that you have supplied the
``bblayers.conf`` file, run the ``bitbake`` command and provide the
target::
$ bitbake printhello
Parsing recipes: 100% |##################################################################################|
Time: 00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing RunQueue
NOTE: Executing RunQueue Tasks
********************
* *
* Hello, World! *
* *
********************
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
.. note::
After the first execution, re-running bitbake printhello again will not
result in a BitBake run that prints the same console output. The reason
for this is that the first time the printhello.bb recipe's do_build task
executes successfully, BitBake writes a stamp file for the task. Thus,
the next time you attempt to run the task using that same bitbake
command, BitBake notices the stamp and therefore determines that the task
does not need to be re-run. If you delete the tmp directory or run
bitbake -c clean printhello and then re-run the build, the "Hello,
World!" message will be printed again.

View File

@@ -0,0 +1,506 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id='hello-world-example'>
<title>Hello World Example</title>
<section id='bitbake-hello-world'>
<title>BitBake Hello World</title>
<para>
The simplest example commonly used to demonstrate any new
programming language or tool is the
"<ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>"
example.
This appendix demonstrates, in tutorial form, Hello
World within the context of BitBake.
The tutorial describes how to create a new project
and the applicable metadata files necessary to allow
BitBake to build it.
</para>
</section>
<section id='example-obtaining-bitbake'>
<title>Obtaining BitBake</title>
<para>
See the
"<link linkend='obtaining-bitbake'>Obtaining BitBake</link>"
section for information on how to obtain BitBake.
Once you have the source code on your machine, the BitBake directory
appears as follows:
<literallayout class='monospaced'>
$ ls -al
total 100
drwxrwxr-x. 9 wmat wmat 4096 Jan 31 13:44 .
drwxrwxr-x. 3 wmat wmat 4096 Feb 4 10:45 ..
-rw-rw-r--. 1 wmat wmat 365 Nov 26 04:55 AUTHORS
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 bin
drwxrwxr-x. 4 wmat wmat 4096 Jan 31 13:44 build
-rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 classes
drwxrwxr-x. 2 wmat wmat 4096 Nov 26 04:55 conf
drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 contrib
-rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
drwxrwxr-x. 3 wmat wmat 4096 Nov 26 04:55 doc
-rw-rw-r--. 1 wmat wmat 69 Nov 26 04:55 .gitignore
-rw-rw-r--. 1 wmat wmat 849 Nov 26 04:55 HEADER
drwxrwxr-x. 5 wmat wmat 4096 Jan 31 13:44 lib
-rw-rw-r--. 1 wmat wmat 195 Nov 26 04:55 MANIFEST.in
-rwxrwxr-x. 1 wmat wmat 3195 Jan 31 11:57 setup.py
-rw-rw-r--. 1 wmat wmat 2887 Nov 26 04:55 TODO
</literallayout>
</para>
<para>
At this point, you should have BitBake cloned to
a directory that matches the previous listing except for
dates and user names.
</para>
</section>
<section id='setting-up-the-bitbake-environment'>
<title>Setting Up the BitBake Environment</title>
<para>
First, you need to be sure that you can run BitBake.
Set your working directory to where your local BitBake
files are and run the following command:
<literallayout class='monospaced'>
$ ./bin/bitbake --version
BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
</literallayout>
The console output tells you what version you are running.
</para>
<para>
The recommended method to run BitBake is from a directory of your
choice.
To be able to run BitBake from any directory, you need to add the
executable binary to your binary to your shell's environment
<filename>PATH</filename> variable.
First, look at your current <filename>PATH</filename> variable
by entering the following:
<literallayout class='monospaced'>
$ echo $PATH
</literallayout>
Next, add the directory location for the BitBake binary to the
<filename>PATH</filename>.
Here is an example that adds the
<filename>/home/scott-lenovo/bitbake/bin</filename> directory
to the front of the <filename>PATH</filename> variable:
<literallayout class='monospaced'>
$ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
</literallayout>
You should now be able to enter the <filename>bitbake</filename>
command from the command line while working from any directory.
</para>
</section>
<section id='the-hello-world-example'>
<title>The Hello World Example</title>
<para>
The overall goal of this exercise is to build a
complete "Hello World" example utilizing task and layer
concepts.
Because this is how modern projects such as OpenEmbedded and
the Yocto Project utilize BitBake, the example
provides an excellent starting point for understanding
BitBake.
</para>
<para>
To help you understand how to use BitBake to build targets,
the example starts with nothing but the <filename>bitbake</filename>
command, which causes BitBake to fail and report problems.
The example progresses by adding pieces to the build to
eventually conclude with a working, minimal "Hello World"
example.
</para>
<para>
While every attempt is made to explain what is happening during
the example, the descriptions cannot cover everything.
You can find further information throughout this manual.
Also, you can actively participate in the
<ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'></ulink>
discussion mailing list about the BitBake build tool.
</para>
<note>
This example was inspired by and drew heavily from these sources:
<itemizedlist>
<listitem><para>
<ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>
</para></listitem>
<listitem><para>
<ulink url="http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/">Hambedded Linux blog post - From Bitbake Hello World to an Image</ulink>
</para></listitem>
</itemizedlist>
</note>
<para>
As stated earlier, the goal of this example
is to eventually compile "Hello World".
However, it is unknown what BitBake needs and what you have
to provide in order to achieve that goal.
Recall that BitBake utilizes three types of metadata files:
<link linkend='configuration-files'>Configuration Files</link>,
<link linkend='classes'>Classes</link>, and
<link linkend='recipes'>Recipes</link>.
But where do they go?
How does BitBake find them?
BitBake's error messaging helps you answer these types of questions
and helps you better understand exactly what is going on.
</para>
<para>
Following is the complete "Hello World" example.
</para>
<orderedlist>
<listitem><para><emphasis>Create a Project Directory:</emphasis>
First, set up a directory for the "Hello World" project.
Here is how you can do so in your home directory:
<literallayout class='monospaced'>
$ mkdir ~/hello
$ cd ~/hello
</literallayout>
This is the directory that BitBake will use to do all of
its work.
You can use this directory to keep all the metafiles needed
by BitBake.
Having a project directory is a good way to isolate your
project.
</para></listitem>
<listitem><para><emphasis>Run Bitbake:</emphasis>
At this point, you have nothing but a project directory.
Run the <filename>bitbake</filename> command and see what
it does:
<literallayout class='monospaced'>
$ bitbake
The BBPATH variable is not set and bitbake did not
find a conf/bblayers.conf file in the expected location.
Maybe you accidentally invoked bitbake from the wrong directory?
DEBUG: Removed the following variables from the environment:
GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
_, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
</literallayout>
The majority of this output is specific to environment variables
that are not directly relevant to BitBake.
However, the very first message regarding the
<filename>BBPATH</filename> variable and the
<filename>conf/bblayers.conf</filename> file
is relevant.</para>
<para>
When you run BitBake, it begins looking for metadata files.
The
<link linkend='var-BBPATH'><filename>BBPATH</filename></link>
variable is what tells BitBake where to look for those files.
<filename>BBPATH</filename> is not set and you need to set it.
Without <filename>BBPATH</filename>, Bitbake cannot
find any configuration files (<filename>.conf</filename>)
or recipe files (<filename>.bb</filename>) at all.
BitBake also cannot find the <filename>bitbake.conf</filename>
file.
</para></listitem>
<listitem><para><emphasis>Setting <filename>BBPATH</filename>:</emphasis>
For this example, you can set <filename>BBPATH</filename>
in the same manner that you set <filename>PATH</filename>
earlier in the appendix.
You should realize, though, that it is much more flexible to set the
<filename>BBPATH</filename> variable up in a configuration
file for each project.</para>
<para>From your shell, enter the following commands to set and
export the <filename>BBPATH</filename> variable:
<literallayout class='monospaced'>
$ BBPATH="&lt;projectdirectory&gt;"
$ export BBPATH
</literallayout>
Use your actual project directory in the command.
BitBake uses that directory to find the metadata it needs for
your project.
<note>
When specifying your project directory, do not use the
tilde ("~") character as BitBake does not expand that character
as the shell would.
</note>
</para></listitem>
<listitem><para><emphasis>Run Bitbake:</emphasis>
Now that you have <filename>BBPATH</filename> defined, run
the <filename>bitbake</filename> command again:
<literallayout class='monospaced'>
$ bitbake
ERROR: Traceback (most recent call last):
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
return func(fn, *args)
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
return bb.parse.handle(fn, data, include)
File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
return h['handle'](fn, data, include)
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
abs_fn = resolve_file(fn, data)
File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
raise IOError("file %s not found in %s" % (fn, bbpath))
IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
</literallayout>
This sample output shows that BitBake could not find the
<filename>conf/bitbake.conf</filename> file in the project
directory.
This file is the first thing BitBake must find in order
to build a target.
And, since the project directory for this example is
empty, you need to provide a <filename>conf/bitbake.conf</filename>
file.
</para></listitem>
<listitem><para><emphasis>Creating <filename>conf/bitbake.conf</filename>:</emphasis>
The <filename>conf/bitbake.conf</filename> includes a number of
configuration variables BitBake uses for metadata and recipe
files.
For this example, you need to create the file in your project directory
and define some key BitBake variables.
For more information on the <filename>bitbake.conf</filename>,
see
<ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#an-overview-of-bitbakeconf'></ulink>
</para>
<para>Use the following commands to create the <filename>conf</filename>
directory in the project directory:
<literallayout class='monospaced'>
$ mkdir conf
</literallayout>
From within the <filename>conf</filename> directory, use
some editor to create the <filename>bitbake.conf</filename>
so that it contains the following:
<literallayout class='monospaced'>
TMPDIR = "${<link linkend='var-TOPDIR'>TOPDIR</link>}/tmp"
<link linkend='var-CACHE'>CACHE</link> = "${TMPDIR}/cache"
<link linkend='var-STAMP'>STAMP</link> = "${TMPDIR}/stamps"
<link linkend='var-T'>T</link> = "${TMPDIR}/work"
<link linkend='var-B'>B</link> = "${TMPDIR}"
</literallayout>
The <filename>TMPDIR</filename> variable establishes a directory
that BitBake uses for build output and intermediate files (other
than the cached information used by the
<link linkend='setscene'>Setscene</link> process.
Here, the <filename>TMPDIR</filename> directory is set to
<filename>hello/tmp</filename>.
<note><title>Tip</title>
You can always safely delete the <filename>tmp</filename>
directory in order to rebuild a BitBake target.
The build process creates the directory for you
when you run BitBake.
</note></para>
<para>For information about each of the other variables defined in this
example, click on the links to take you to the definitions in
the glossary.
</para></listitem>
<listitem><para><emphasis>Run Bitbake:</emphasis>
After making sure that the <filename>conf/bitbake.conf</filename>
file exists, you can run the <filename>bitbake</filename>
command again:
<literallayout class='monospaced'>
$ bitbake
ERROR: Traceback (most recent call last):
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
return func(fn, *args)
File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
include(fn, file, lineno, d, "inherit")
File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
</literallayout>
In the sample output, BitBake could not find the
<filename>classes/base.bbclass</filename> file.
You need to create that file next.
</para></listitem>
<listitem><para><emphasis>Creating <filename>classes/base.bbclass</filename>:</emphasis>
BitBake uses class files to provide common code and functionality.
The minimally required class for BitBake is the
<filename>classes/base.bbclass</filename> file.
The <filename>base</filename> class is implicitly inherited by
every recipe.
BitBake looks for the class in the <filename>classes</filename>
directory of the project (i.e <filename>hello/classes</filename>
in this example).
</para>
<para>Create the <filename>classes</filename> directory as follows:
<literallayout class='monospaced'>
$ cd $HOME/hello
$ mkdir classes
</literallayout>
Move to the <filename>classes</filename> directory and then
create the <filename>base.bbclass</filename> file by inserting
this single line:
<literallayout class='monospaced'>
addtask build
</literallayout>
The minimal task that BitBake runs is the
<filename>do_build</filename> task.
This is all the example needs in order to build the project.
Of course, the <filename>base.bbclass</filename> can have much
more depending on which build environments BitBake is
supporting.
For more information on the <filename>base.bbclass</filename> file,
you can look at
<ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#tasks'></ulink>.
</para></listitem>
<listitem><para><emphasis>Run Bitbake:</emphasis>
After making sure that the <filename>classes/base.bbclass</filename>
file exists, you can run the <filename>bitbake</filename>
command again:
<literallayout class='monospaced'>
$ bitbake
Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
</literallayout>
BitBake is finally reporting no errors.
However, you can see that it really does not have anything
to do.
You need to create a recipe that gives BitBake something to do.
</para></listitem>
<listitem><para><emphasis>Creating a Layer:</emphasis>
While it is not really necessary for such a small example,
it is good practice to create a layer in which to keep your
code separate from the general metadata used by BitBake.
Thus, this example creates and uses a layer called "mylayer".
<note>
You can find additional information on adding a layer at
<ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#adding-an-example-layer'></ulink>.
</note>
</para>
<para>Minimally, you need a recipe file and a layer configuration
file in your layer.
The configuration file needs to be in the <filename>conf</filename>
directory inside the layer.
Use these commands to set up the layer and the <filename>conf</filename>
directory:
<literallayout class='monospaced'>
$ cd $HOME
$ mkdir mylayer
$ cd mylayer
$ mkdir conf
</literallayout>
Move to the <filename>conf</filename> directory and create a
<filename>layer.conf</filename> file that has the following:
<literallayout class='monospaced'>
BBPATH .= ":${<link linkend='var-LAYERDIR'>LAYERDIR</link>}"
<link linkend='var-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb"
<link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer"
<link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR}/"
</literallayout>
For information on these variables, click the links
to go to the definitions in the glossary.</para>
<para>You need to create the recipe file next.
Inside your layer at the top-level, use an editor and create
a recipe file named <filename>printhello.bb</filename> that
has the following:
<literallayout class='monospaced'>
<link linkend='var-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World"
<link linkend='var-PN'>PN</link> = 'printhello'
<link linkend='var-PV'>PV</link> = '1'
python do_build() {
bb.plain("********************");
bb.plain("* *");
bb.plain("* Hello, World! *");
bb.plain("* *");
bb.plain("********************");
}
</literallayout>
The recipe file simply provides a description of the
recipe, the name, version, and the <filename>do_build</filename>
task, which prints out "Hello World" to the console.
For more information on these variables, follow the links
to the glossary.
</para></listitem>
<listitem><para><emphasis>Run Bitbake With a Target:</emphasis>
Now that a BitBake target exists, run the command and provide
that target:
<literallayout class='monospaced'>
$ cd $HOME/hello
$ bitbake printhello
ERROR: no recipe files to build, check your BBPATH and BBFILES?
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
</literallayout>
We have created the layer with the recipe and the layer
configuration file but it still seems that BitBake cannot
find the recipe.
BitBake needs a <filename>conf/bblayers.conf</filename> that
lists the layers for the project.
Without this file, BitBake cannot find the recipe.
</para></listitem>
<listitem><para><emphasis>Creating <filename>conf/bblayers.conf</filename>:</emphasis>
BitBake uses the <filename>conf/bblayers.conf</filename> file
to locate layers needed for the project.
This file must reside in the <filename>conf</filename> directory
of the project (i.e. <filename>hello/conf</filename> for this
example).</para>
<para>Set your working directory to the <filename>hello/conf</filename>
directory and then create the <filename>bblayers.conf</filename>
file so that it contains the following:
<literallayout class='monospaced'>
BBLAYERS ?= " \
/home/&lt;you&gt;/mylayer \
"
</literallayout>
You need to provide your own information for
<filename>you</filename> in the file.
</para></listitem>
<listitem><para><emphasis>Run Bitbake With a Target:</emphasis>
Now that you have supplied the <filename>bblayers.conf</filename>
file, run the <filename>bitbake</filename> command and provide
the target:
<literallayout class='monospaced'>
$ bitbake printhello
Parsing recipes: 100% |##################################################################################|
Time: 00:00:00
Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing RunQueue Tasks
********************
* *
* Hello, World! *
* *
********************
NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
</literallayout>
BitBake finds the <filename>printhello</filename> recipe and
successfully runs the task.
<note>
After the first execution, re-running
<filename>bitbake printhello</filename> again will not
result in a BitBake run that prints the same console
output.
The reason for this is that the first time the
<filename>printhello.bb</filename> recipe's
<filename>do_build</filename> task executes
successfully, BitBake writes a stamp file for the task.
Thus, the next time you attempt to run the task
using that same <filename>bitbake</filename> command,
BitBake notices the stamp and therefore determines
that the task does not need to be re-run.
If you delete the <filename>tmp</filename> directory
or run <filename>bitbake -c clean printhello</filename>
and then re-run the build, the "Hello, World!" message will
be printed again.
</note>
</para></listitem>
</orderedlist>
</section>
</appendix>

View File

@@ -1,654 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
========
Overview
========
|
Welcome to the BitBake User Manual. This manual provides information on
the BitBake tool. The information attempts to be as independent as
possible regarding systems that use BitBake, such as OpenEmbedded and
the Yocto Project. In some cases, scenarios or examples within the
context of a build system are used in the manual to help with
understanding. For these cases, the manual clearly states the context.
.. _intro:
Introduction
============
Fundamentally, BitBake is a generic task execution engine that allows
shell and Python tasks to be run efficiently and in parallel while
working within complex inter-task dependency constraints. One of
BitBake's main users, OpenEmbedded, takes this core and builds embedded
Linux software stacks using a task-oriented approach.
Conceptually, BitBake is similar to GNU Make in some regards but has
significant differences:
- BitBake executes tasks according to the provided metadata that builds up
the tasks. Metadata is stored in recipe (``.bb``) and related recipe
"append" (``.bbappend``) files, configuration (``.conf``) and
underlying include (``.inc``) files, and in class (``.bbclass``)
files. The metadata provides BitBake with instructions on what tasks
to run and the dependencies between those tasks.
- BitBake includes a fetcher library for obtaining source code from
various places such as local files, source control systems, or
websites.
- The instructions for each unit to be built (e.g. a piece of software)
are known as "recipe" files and contain all the information about the
unit (dependencies, source file locations, checksums, description and
so on).
- BitBake includes a client/server abstraction and can be used from a
command line or used as a service over XML-RPC and has several
different user interfaces.
History and Goals
=================
BitBake was originally a part of the OpenEmbedded project. It was
inspired by the Portage package management system used by the Gentoo
Linux distribution. On December 7, 2004, OpenEmbedded project team
member Chris Larson split the project into two distinct pieces:
- BitBake, a generic task executor
- OpenEmbedded, a metadata set utilized by BitBake
Today, BitBake is the primary basis of the
`OpenEmbedded <https://www.openembedded.org/>`__ project, which is being
used to build and maintain Linux distributions such as the `Angstrom
Distribution <http://www.angstrom-distribution.org/>`__, and which is
also being used as the build tool for Linux projects such as the `Yocto
Project <https://www.yoctoproject.org>`__.
Prior to BitBake, no other build tool adequately met the needs of an
aspiring embedded Linux distribution. All of the build systems used by
traditional desktop Linux distributions lacked important functionality,
and none of the ad hoc Buildroot-based systems, prevalent in the
embedded space, were scalable or maintainable.
Some important original goals for BitBake were:
- Handle cross-compilation.
- Handle inter-package dependencies (build time on target architecture,
build time on native architecture, and runtime).
- Support running any number of tasks within a given package,
including, but not limited to, fetching upstream sources, unpacking
them, patching them, configuring them, and so forth.
- Be Linux distribution agnostic for both build and target systems.
- Be architecture agnostic.
- Support multiple build and target operating systems (e.g. Cygwin, the
BSDs, and so forth).
- Be self-contained, rather than tightly integrated into the build
machine's root filesystem.
- Handle conditional metadata on the target architecture, operating
system, distribution, and machine.
- Be easy to use the tools to supply local metadata and packages
against which to operate.
- Be easy to use BitBake to collaborate between multiple projects for
their builds.
- Provide an inheritance mechanism to share common metadata between
many packages.
Over time it became apparent that some further requirements were
necessary:
- Handle variants of a base recipe (e.g. native, sdk, and multilib).
- Split metadata into layers and allow layers to enhance or override
other layers.
- Allow representation of a given set of input variables to a task as a
checksum. Based on that checksum, allow acceleration of builds with
prebuilt components.
BitBake satisfies all the original requirements and many more with
extensions being made to the basic functionality to reflect the
additional requirements. Flexibility and power have always been the
priorities. BitBake is highly extensible and supports embedded Python
code and execution of any arbitrary tasks.
.. _Concepts:
Concepts
========
BitBake is a program written in the Python language. At the highest
level, BitBake interprets metadata, decides what tasks are required to
run, and executes those tasks. Similar to GNU Make, BitBake controls how
software is built. GNU Make achieves its control through "makefiles",
while BitBake uses "recipes".
BitBake extends the capabilities of a simple tool like GNU Make by
allowing for the definition of much more complex tasks, such as
assembling entire embedded Linux distributions.
The remainder of this section introduces several concepts that should be
understood in order to better leverage the power of BitBake.
Recipes
-------
BitBake Recipes, which are denoted by the file extension ``.bb``, are
the most basic metadata files. These recipe files provide BitBake with
the following:
- Descriptive information about the package (author, homepage, license,
and so on)
- The version of the recipe
- Existing dependencies (both build and runtime dependencies)
- Where the source code resides and how to fetch it
- Whether the source code requires any patches, where to find them, and
how to apply them
- How to configure and compile the source code
- How to assemble the generated artifacts into one or more installable
packages
- Where on the target machine to install the package or packages
created
Within the context of BitBake, or any project utilizing BitBake as its
build system, files with the ``.bb`` extension are referred to as
recipes.
.. note::
The term "package" is also commonly used to describe recipes.
However, since the same word is used to describe packaged output from
a project, it is best to maintain a single descriptive term -
"recipes". Put another way, a single "recipe" file is quite capable
of generating a number of related but separately installable
"packages". In fact, that ability is fairly common.
Configuration Files
-------------------
Configuration files, which are denoted by the ``.conf`` extension,
define various configuration variables that govern the project's build
process. These files fall into several areas that define machine
configuration, distribution configuration, possible compiler tuning,
general common configuration, and user configuration. The main
configuration file is the sample ``bitbake.conf`` file, which is located
within the BitBake source tree ``conf`` directory.
Classes
-------
Class files, which are denoted by the ``.bbclass`` extension, contain
information that is useful to share between metadata files. The BitBake
source tree currently comes with one class metadata file called
``base.bbclass``. You can find this file in the ``classes`` directory.
The ``base.bbclass`` class files is special since it is always included
automatically for all recipes and classes. This class contains
definitions for standard basic tasks such as fetching, unpacking,
configuring (empty by default), compiling (runs any Makefile present),
installing (empty by default) and packaging (empty by default). These
tasks are often overridden or extended by other classes added during the
project development process.
Layers
------
Layers allow you to isolate different types of customizations from each
other. While you might find it tempting to keep everything in one layer
when working on a single project, the more modular your metadata, the
easier it is to cope with future changes.
To illustrate how you can use layers to keep things modular, consider
customizations you might make to support a specific target machine.
These types of customizations typically reside in a special layer,
rather than a general layer, called a Board Support Package (BSP) layer.
Furthermore, the machine customizations should be isolated from recipes
and metadata that support a new GUI environment, for example. This
situation gives you a couple of layers: one for the machine
configurations and one for the GUI environment. It is important to
understand, however, that the BSP layer can still make machine-specific
additions to recipes within the GUI environment layer without polluting
the GUI layer itself with those machine-specific changes. You can
accomplish this through a recipe that is a BitBake append
(``.bbappend``) file.
.. _append-bbappend-files:
Append Files
------------
Append files, which are files that have the ``.bbappend`` file
extension, extend or override information in an existing recipe file.
BitBake expects every append file to have a corresponding recipe file.
Furthermore, the append file and corresponding recipe file must use the
same root filename. The filenames can differ only in the file type
suffix used (e.g. ``formfactor_0.0.bb`` and
``formfactor_0.0.bbappend``).
Information in append files extends or overrides the information in the
underlying, similarly-named recipe files.
When you name an append file, you can use the "``%``" wildcard character
to allow for matching recipe names. For example, suppose you have an
append file named as follows::
busybox_1.21.%.bbappend
That append file
would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
the append file would match the following recipe names::
busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb
.. note::
The use of the " % " character is limited in that it only works directly in
front of the .bbappend portion of the append file's name. You cannot use the
wildcard character in any other location of the name.
If the ``busybox`` recipe was updated to ``busybox_1.3.0.bb``, the
append name would not match. However, if you named the append file
``busybox_1.%.bbappend``, then you would have a match.
In the most general case, you could name the append file something as
simple as ``busybox_%.bbappend`` to be entirely version independent.
Obtaining BitBake
=================
You can obtain BitBake several different ways:
- **Cloning BitBake:** Using Git to clone the BitBake source code
repository is the recommended method for obtaining BitBake. Cloning
the repository makes it easy to get bug fixes and have access to
stable branches and the master branch. Once you have cloned BitBake,
you should use the latest stable branch for development since the
master branch is for BitBake development and might contain less
stable changes.
You usually need a version of BitBake that matches the metadata you
are using. The metadata is generally backwards compatible but not
forward compatible.
Here is an example that clones the BitBake repository::
$ git clone git://git.openembedded.org/bitbake
This command clones the BitBake
Git repository into a directory called ``bitbake``. Alternatively,
you can designate a directory after the ``git clone`` command if you
want to call the new directory something other than ``bitbake``. Here
is an example that names the directory ``bbdev``::
$ git clone git://git.openembedded.org/bitbake bbdev
- **Installation using your Distribution Package Management System:**
This method is not recommended because the BitBake version that is
provided by your distribution, in most cases, is several releases
behind a snapshot of the BitBake repository.
- **Taking a snapshot of BitBake:** Downloading a snapshot of BitBake
from the source code repository gives you access to a known branch or
release of BitBake.
.. note::
Cloning the Git repository, as described earlier, is the preferred
method for getting BitBake. Cloning the repository makes it easier
to update as patches are added to the stable branches.
The following example downloads a snapshot of BitBake version 1.17.0::
$ wget https://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
$ tar zxpvf bitbake-1.17.0.tar.gz
After extraction of the tarball using
the tar utility, you have a directory entitled ``bitbake-1.17.0``.
- **Using the BitBake that Comes With Your Build Checkout:** A final
possibility for getting a copy of BitBake is that it already comes
with your checkout of a larger BitBake-based build system, such as
Poky. Rather than manually checking out individual layers and gluing
them together yourself, you can check out an entire build system. The
checkout will already include a version of BitBake that has been
thoroughly tested for compatibility with the other components. For
information on how to check out a particular BitBake-based build
system, consult that build system's supporting documentation.
.. _bitbake-user-manual-command:
The BitBake Command
===================
The ``bitbake`` command is the primary interface to the BitBake tool.
This section presents the BitBake command syntax and provides several
execution examples.
Usage and syntax
----------------
Following is the usage and syntax for BitBake::
$ bitbake -h
Usage: bitbake [options] [recipename/target recipe:do_task ...]
Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
will provide the layer, BBFILES and other configuration information.
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-b BUILDFILE, --buildfile=BUILDFILE
Execute tasks from a specific .bb recipe directly.
WARNING: Does not handle any dependencies from other
recipes.
-k, --continue Continue as much as possible after an error. While the
target that failed and anything depending on it cannot
be built, as much as possible will be built before
stopping.
-f, --force Force the specified targets/task to run (invalidating
any existing stamp file).
-c CMD, --cmd=CMD Specify the task to execute. The exact options
available depend on the metadata. Some examples might
be 'compile' or 'populate_sysroot' or 'listtasks' may
give a list of the tasks available.
-C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
Invalidate the stamp for the specified task such as
'compile' and then run the default task for the
specified target(s).
-r PREFILE, --read=PREFILE
Read the specified file before bitbake.conf.
-R POSTFILE, --postread=POSTFILE
Read the specified file after bitbake.conf.
-v, --verbose Enable tracing of shell tasks (with 'set -x'). Also
print bb.note(...) messages to stdout (in addition to
writing them to ${T}/log.do_&lt;task&gt;).
-D, --debug Increase the debug level. You can specify this more
than once. -D sets the debug level to 1, where only
bb.debug(1, ...) messages are printed to stdout; -DD
sets the debug level to 2, where both bb.debug(1, ...)
and bb.debug(2, ...) messages are printed; etc.
Without -D, no debug messages are printed. Note that
-D only affects output to stdout. All debug messages
are written to ${T}/log.do_taskname, regardless of the
debug level.
-q, --quiet Output less log message data to the terminal. You can
specify this more than once.
-n, --dry-run Don't execute, just go through the motions.
-S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
Dump out the signature construction information, with
no task execution. The SIGNATURE_HANDLER parameter is
passed to the handler. Two common values are none and
printdiff but the handler may define more/less. none
means only dump the signature, printdiff means compare
the dumped signature with the cached one.
-p, --parse-only Quit after parsing the BB recipes.
-s, --show-versions Show current and preferred versions of all recipes.
-e, --environment Show the global or per-recipe environment complete
with information about where variables were
set/changed.
-g, --graphviz Save dependency tree information for the specified
targets in the dot syntax.
-I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
Assume these dependencies don't exist and are already
provided (equivalent to ASSUME_PROVIDED). Useful to
make dependency graphs more appealing
-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
Show debug logging for the specified logging domains
-P, --profile Profile the command and save reports.
-u UI, --ui=UI The user interface to use (knotty, ncurses, taskexp or
teamcity - default knotty).
--token=XMLRPCTOKEN Specify the connection token to be used when
connecting to a remote server.
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not.
--server-only Run bitbake without a UI, only starting a server
(cooker) process.
-B BIND, --bind=BIND The name/address for the bitbake xmlrpc server to bind
to.
-T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
Set timeout to unload bitbake server due to
inactivity, set to -1 means no unload, default:
Environment variable BB_SERVER_TIMEOUT.
--no-setscene Do not run any setscene tasks. sstate will be ignored
and everything needed, built.
--skip-setscene Skip setscene tasks if they would be executed. Tasks
previously restored from sstate will be kept, unlike
--no-setscene
--setscene-only Only run setscene tasks, don't run any real tasks.
--remote-server=REMOTE_SERVER
Connect to the specified server.
-m, --kill-server Terminate any running bitbake server.
--observe-only Connect to a server as an observing-only client.
--status-only Check the status of the remote bitbake server.
-w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
Writes the event log of the build to a bitbake event
json file. Use '' (empty string) to assign the name
automatically.
--runall=RUNALL Run the specified task for any recipe in the taskgraph
of the specified target (even if it wouldn't otherwise
have run).
--runonly=RUNONLY Run only the specified task within the taskgraph of
the specified targets (and any task dependencies those
tasks may have).
.. _bitbake-examples:
Examples
--------
This section presents some examples showing how to use BitBake.
.. _example-executing-a-task-against-a-single-recipe:
Executing a Task Against a Single Recipe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Executing tasks for a single recipe file is relatively simple. You
specify the file in question, and BitBake parses it and executes the
specified task. If you do not specify a task, BitBake executes the
default task, which is "build". BitBake obeys inter-task dependencies
when doing so.
The following command runs the build task, which is the default task, on
the ``foo_1.0.bb`` recipe file::
$ bitbake -b foo_1.0.bb
The following command runs the clean task on the ``foo.bb`` recipe file::
$ bitbake -b foo.bb -c clean
.. note::
The "-b" option explicitly does not handle recipe dependencies. Other
than for debugging purposes, it is instead recommended that you use
the syntax presented in the next section.
Executing Tasks Against a Set of Recipe Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a number of additional complexities introduced when one wants
to manage multiple ``.bb`` files. Clearly there needs to be a way to
tell BitBake what files are available and, of those, which you want to
execute. There also needs to be a way for each recipe to express its
dependencies, both for build-time and runtime. There must be a way for
you to express recipe preferences when multiple recipes provide the same
functionality, or when there are multiple versions of a recipe.
The ``bitbake`` command, when not using "--buildfile" or "-b" only
accepts a "PROVIDES". You cannot provide anything else. By default, a
recipe file generally "PROVIDES" its "packagename" as shown in the
following example::
$ bitbake foo
This next example "PROVIDES" the
package name and also uses the "-c" option to tell BitBake to just
execute the ``do_clean`` task::
$ bitbake -c clean foo
Executing a List of Task and Recipe Combinations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The BitBake command line supports specifying different tasks for
individual targets when you specify multiple targets. For example,
suppose you had two targets (or recipes) ``myfirstrecipe`` and
``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first
recipe and ``taskB`` for the second recipe::
$ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
Generating Dependency Graphs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BitBake is able to generate dependency graphs using the ``dot`` syntax.
You can convert these graphs into images using the ``dot`` tool from
`Graphviz <http://www.graphviz.org>`__.
When you generate a dependency graph, BitBake writes two files to the
current working directory:
- ``task-depends.dot``: Shows dependencies between tasks. These
dependencies match BitBake's internal task execution list.
- ``pn-buildlist``: Shows a simple list of targets that are to be
built.
To stop depending on common depends, use the "-I" depend option and
BitBake omits them from the graph. Leaving this information out can
produce more readable graphs. This way, you can remove from the graph
:term:`DEPENDS` from inherited classes such as ``base.bbclass``.
Here are two examples that create dependency graphs. The second example
omits depends common in OpenEmbedded from the graph::
$ bitbake -g foo
$ bitbake -g -I virtual/kernel -I eglibc foo
Executing a Multiple Configuration Build
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BitBake is able to build multiple images or packages using a single
command where the different targets require different configurations
(multiple configuration builds). Each target, in this scenario, is
referred to as a "multiconfig".
To accomplish a multiple configuration build, you must define each
target's configuration separately using a parallel configuration file in
the build directory. The location for these multiconfig configuration
files is specific. They must reside in the current build directory in a
sub-directory of ``conf`` named ``multiconfig``. Following is an example
for two separate targets:
.. image:: figures/bb_multiconfig_files.png
:align: center
The reason for this required file hierarchy is because the :term:`BBPATH`
variable is not constructed until the layers are parsed. Consequently,
using the configuration file as a pre-configuration file is not possible
unless it is located in the current working directory.
Minimally, each configuration file must define the machine and the
temporary directory BitBake uses for the build. Suggested practice
dictates that you do not overlap the temporary directories used during
the builds.
Aside from separate configuration files for each target, you must also
enable BitBake to perform multiple configuration builds. Enabling is
accomplished by setting the
:term:`BBMULTICONFIG` variable in the
``local.conf`` configuration file. As an example, suppose you had
configuration files for ``target1`` and ``target2`` defined in the build
directory. The following statement in the ``local.conf`` file both
enables BitBake to perform multiple configuration builds and specifies
the two extra multiconfigs::
BBMULTICONFIG = "target1 target2"
Once the target configuration files are in place and BitBake has been
enabled to perform multiple configuration builds, use the following
command form to start the builds::
$ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]
Here is an example for two extra multiconfigs: ``target1`` and ``target2``::
$ bitbake mc::target mc:target1:target mc:target2:target
.. _bb-enabling-multiple-configuration-build-dependencies:
Enabling Multiple Configuration Build Dependencies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes dependencies can exist between targets (multiconfigs) in a
multiple configuration build. For example, suppose that in order to
build an image for a particular architecture, the root filesystem of
another build for a different architecture needs to exist. In other
words, the image for the first multiconfig depends on the root
filesystem of the second multiconfig. This dependency is essentially
that the task in the recipe that builds one multiconfig is dependent on
the completion of the task in the recipe that builds another
multiconfig.
To enable dependencies in a multiple configuration build, you must
declare the dependencies in the recipe using the following statement
form::
task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
To better show how to use this statement, consider an example with two
multiconfigs: ``target1`` and ``target2``::
image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"
In this example, the
``from_multiconfig`` is "target1" and the ``to_multiconfig`` is "target2". The
task on which the image whose recipe contains image_task depends on the
completion of the rootfs_task used to build out image2, which is
associated with the "target2" multiconfig.
Once you set up this dependency, you can build the "target1" multiconfig
using a BitBake command as follows::
$ bitbake mc:target1:image1
This command executes all the tasks needed to create ``image1`` for the "target1"
multiconfig. Because of the dependency, BitBake also executes through
the ``rootfs_task`` for the "target2" multiconfig build.
Having a recipe depend on the root filesystem of another build might not
seem that useful. Consider this change to the statement in the image1
recipe::
image_task[mcdepends] = "mc:target1:target2:image2:image_task"
In this case, BitBake must create ``image2`` for the "target2" build since
the "target1" build depends on it.
Because "target1" and "target2" are enabled for multiple configuration
builds and have separate configuration files, BitBake places the
artifacts for each build in the respective temporary build directories.

View File

@@ -0,0 +1,644 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id="bitbake-user-manual-intro">
<title>Overview</title>
<para>
Welcome to the BitBake User Manual.
This manual provides information on the BitBake tool.
The information attempts to be as independent as possible regarding
systems that use BitBake, such as the Yocto Project and
OpenEmbedded.
In some cases, scenarios or examples that within the context of
a build system are used in the manual to help with understanding.
For these cases, the manual clearly states the context.
</para>
<section id="intro">
<title>Introduction</title>
<para>
Fundamentally, BitBake is a generic task execution
engine that allows shell and Python tasks to be run
efficiently and in parallel while working within
complex inter-task dependency constraints.
One of BitBake's main users, OpenEmbedded, takes this core
and builds embedded Linux software stacks using
a task-oriented approach.
</para>
<para>
Conceptually, BitBake is similar to GNU Make in
some regards but has significant differences:
<itemizedlist>
<listitem><para>
BitBake executes tasks according to provided
metadata that builds up the tasks.
Metadata is stored in recipe (<filename>.bb</filename>),
configuration (<filename>.conf</filename>), and class
(<filename>.bbclass</filename>) files and provides
BitBake with instructions on what tasks to run and
the dependencies between those tasks.
</para></listitem>
<listitem><para>
BitBake includes a fetcher library for obtaining source
code from various places such as source control
systems or websites.
</para></listitem>
<listitem><para>
The instructions for each unit to be built (e.g. a piece
of software) are known as recipe files and
contain all the information about the unit
(dependencies, source file locations, checksums, description
and so on).
</para></listitem>
<listitem><para>
BitBake includes a client/server abstraction and can
be used from a command line or used as a service over XMLRPC and
has several different user interfaces.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id="history-and-goals">
<title>History and Goals</title>
<para>
BitBake was originally a part of the OpenEmbedded project.
It was inspired by the Portage package management system
used by the Gentoo Linux distribution.
On December 7, 2004, OpenEmbedded project team member,
Chris Larson split the project into two distinct pieces:
<itemizedlist>
<listitem><para>BitBake, a generic task executor</para></listitem>
<listitem><para>OpenEmbedded, a metadata set utilized by
BitBake</para></listitem>
</itemizedlist>
Today, BitBake is the primary basis of the
<ulink url="http://www.openembedded.org/">OpenEmbedded</ulink>
project, which is being used to build and maintain Linux
distributions such as the Angstrom Distribution and which is used
as the build tool for Linux projects such as the Yocto Project.
</para>
<para>
Prior to BitBake, no other build tool adequately met the needs of
an aspiring embedded Linux distribution.
All of the build systems used by traditional desktop Linux
distributions lacked important functionality, and none of the
ad-hoc Buildroot-based systems, prevalent in the
embedded space, were scalable or maintainable.
</para>
<para>
Some important original goals for BitBake were:
<itemizedlist>
<listitem><para>
Handle cross-compilation.
</para></listitem>
<listitem><para>
Handle inter-package dependencies (build time on
target architecture, build time on native
architecture, and runtime).
</para></listitem>
<listitem><para>
Support running any number of tasks within a given
package, including, but not limited to, fetching
upstream sources, unpacking them, patching them,
configuring them, and so forth.
</para></listitem>
<listitem><para>
Be Linux distribution agnostic for both build and
target systems.
</para></listitem>
<listitem><para>
Be architecture agnostic.
</para></listitem>
<listitem><para>
Support multiple build and target operating systems
(e.g. Cygwin, the BSDs, and so forth).
</para></listitem>
<listitem><para>
Be self contained, rather than tightly
integrated into the build machine's root
filesystem.
</para></listitem>
<listitem><para>
Handle conditional metadata on the target architecture,
operating system, distribution, and machine.
</para></listitem>
<listitem><para>
Be easy to use the tools to supply local metadata and packages
against which to operate.
</para></listitem>
<listitem><para>
Be easy to use BitBake to collaborate between multiple
projects for their builds.
</para></listitem>
<listitem><para>
Provide an inheritance mechanism that share
common metadata between many packages.
</para></listitem>
</itemizedlist>
Over time it became apparent that some further requirements
were necessary:
<itemizedlist>
<listitem><para>
Handle variants of a base recipe (e.g. native, sdk,
and multilib).
</para></listitem>
<listitem><para>
Split metadata into layers and allow layers
to override each other.
</para></listitem>
<listitem><para>
Allow representation of a given set of input variables
to a task as a checksum.
Based on that checksum, allow acceleration of builds
with prebuilt components.
</para></listitem>
</itemizedlist>
BitBake satisfies all the original requirements and many more
with extensions being made to the basic functionality to
reflect the additional requirements.
Flexibility and power have always been the priorities.
BitBake is highly extensible and supports embedded Python code and
execution of any arbitrary tasks.
</para>
</section>
<section id="Concepts">
<title>Concepts</title>
<para>
BitBake is a program written in the Python language.
At the highest level, BitBake interprets metadata, decides
what tasks are required to run, and executes those tasks.
Similar to GNU Make, BitBake controls how software is
built.
GNU Make achieves its control through "makefiles".
BitBake uses "recipes".
</para>
<para>
BitBake extends the capabilities of a simple
tool like GNU Make by allowing for much more complex tasks
to be completed, such as assembling entire embedded Linux
distributions.
</para>
<para>
The remainder of this section introduces several concepts
that should be understood in order to better leverage
the power of BitBake.
</para>
<section id='recipes'>
<title>Recipes</title>
<para>
BitBake Recipes, which are denoted by the file extension
<filename>.bb</filename>, are the most basic metadata files.
These recipe files provide BitBake with the following:
<itemizedlist>
<listitem><para>Descriptive information about the package</para></listitem>
<listitem><para>The version of the recipe</para></listitem>
<listitem><para>Existing Dependencies</para></listitem>
<listitem><para>Where the source code resides</para></listitem>
<listitem><para>Whether the source code requires any patches</para></listitem>
<listitem><para>How to compile the source code</para></listitem>
<listitem><para>Where on the target machine to install the
package being compiled</para></listitem>
</itemizedlist>
</para>
<para>
Within the context of BitBake, or any project utilizing BitBake
as its build system, files with the <filename>.bb</filename>
extension are referred to as recipes.
<note>
The term "package" is also commonly used to describe recipes.
However, since the same word is used to describe packaged
output from a project, it is best to maintain a single
descriptive term, "recipes".
</note>
</para>
</section>
<section id='configuration-files'>
<title>Configuration Files</title>
<para>
Configuration files, which are denoted by the
<filename>.conf</filename> extension, define
various configuration variables that govern the project's build
process.
These files fall into several areas that define
machine configuration options, distribution configuration
options, compiler tuning options, general common
configuration options, and user configuration options.
The main configuration file is the sample
<filename>bitbake.conf</filename> file, which is
located within the BitBake source tree
<filename>conf</filename> directory.
</para>
</section>
<section id='classes'>
<title>Classes</title>
<para>
Class files, which are denoted by the
<filename>.bbclass</filename> extension, contain
information that is useful to share between metadata files.
The BitBake source tree currently comes with one class metadata file
called <filename>base.bbclass</filename>.
You can find this file in the
<filename>classes</filename> directory.
The <filename>base.bbclass</filename> is special since it
is always included automatically for all recipes
and classes.
This class contains definitions for standard basic tasks such
as fetching, unpacking, configuring (empty by default),
compiling (runs any Makefile present), installing (empty by
default) and packaging (empty by default).
These tasks are often overridden or extended by other classes
added during the project development process.
</para>
</section>
<section id='layers'>
<title>Layers</title>
<para>
Layers allow you to isolate different types of
customizations from each other.
While you might find it tempting to keep everything in one layer
when working on a single project, the more modular you organize
your metadata, the easier it is to cope with future changes.
</para>
<para>
To illustrate how you can use layers to keep things modular,
consider customizations you might make to support a specific target machine.
These types of customizations typically reside in a special layer,
rather than a general layer, called a Board Specific Package (BSP) Layer.
Furthermore, the machine customizations should be isolated from
recipes and metadata that support a new GUI environment, for
example.
This situation gives you a couple of layers: one for the machine
configurations and one for the GUI environment.
It is important to understand, however, that the BSP layer can still
make machine-specific additions to recipes within
the GUI environment layer without polluting the GUI layer itself
with those machine-specific changes.
You can accomplish this through a recipe that is a BitBake append
(<filename>.bbappend</filename>) file.
</para>
</section>
<section id='append-bbappend-files'>
<title>Append Files</title>
<para>
Append files, which are files that have the
<filename>.bbappend</filename> file extension, add or
extend build information to an existing
recipe file.
</para>
<para>
BitBake expects every append file to have a corresponding recipe file.
Furthermore, the append file and corresponding recipe file
must use the same root filename.
The filenames can differ only in the file type suffix used
(e.g. <filename>formfactor_0.0.bb</filename> and
<filename>formfactor_0.0.bbappend</filename>).
</para>
<para>
Information in append files overrides the information in the
similarly-named recipe file.
</para>
<para>
When you name an append file, you can use the
wildcard character (%) to allow for matching recipe names.
For example, suppose you have an append file named
as follows:
<literallayout class='monospaced'>
busybox_1.21.%.bbappend
</literallayout>
That append file would match any <filename>busybox_1.21.x.bb</filename>
version of the recipe.
So, the append file would match the following recipe names:
<literallayout class='monospaced'>
busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb
</literallayout>
If the <filename>busybox</filename> recipe was updated to
<filename>busybox_1.3.0.bb</filename>, the append name would not
match.
However, if you named the append file
<filename>busybox_1.%.bbappend</filename>, then you would have a match.
</para>
</section>
</section>
<section id='obtaining-bitbake'>
<title>Obtaining BitBake</title>
<para>
You can obtain BitBake several different ways:
<itemizedlist>
<listitem><para><emphasis>Cloning BitBake:</emphasis>
Using Git to clone the BitBake source code repository
is the recommended method for obtaining BitBake.
Cloning the repository makes it easy to get bug fixes
and have access to stable branches and the master
branch.
Once you have cloned BitBake, you should use
the latest stable
branch for development since the master branch is for
BitBake development and might contain less stable changes.
</para>
<para>You usually need a version of BitBake
that matches the metadata you are using.
The metadata is generally backwards compatible but
not forward compatible.</para>
<para>Here is an example that clones the BitBake repository:
<literallayout class='monospaced'>
$ git clone git://git.openembedded.org/bitbake
</literallayout>
This command clones the BitBake Git repository into a
directory called <filename>bitbake</filename>.
Alternatively, you can
designate a directory after the
<filename>git clone</filename> command
if you want to call the new directory something
other than <filename>bitbake</filename>.
Here is an example that names the directory
<filename>bbdev</filename>:
<literallayout class='monospaced'>
$ git clone git://git.openembedded.org/bitbake bbdev
</literallayout></para></listitem>
<listitem><para><emphasis>Installation using your Distribution
Package Management System:</emphasis>
This method is not
recommended because the BitBake version that is
provided by your distribution, in most cases,
is several
releases behind a snapshot of the BitBake repository.
</para></listitem>
<listitem><para><emphasis>Taking a snapshot of BitBake:</emphasis>
Downloading a snapshot of BitBake from the
source code repository gives you access to a known
branch or release of BitBake.
<note>
Cloning the Git repository, as described earlier,
is the preferred method for getting BitBake.
Cloning the repository makes it easier to update as
patches are added to the stable branches.
</note></para>
<para>The following example downloads a snapshot of
BitBake version 1.17.0:
<literallayout class='monospaced'>
$ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
$ tar zxpvf bitbake-1.17.0.tar.gz
</literallayout>
After extraction of the tarball using the tar utility,
you have a directory entitled
<filename>bitbake-1.17.0</filename>.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id="bitbake-user-manual-command">
<title>The BitBake Command</title>
<para>
The <filename>bitbake</filename> command is the primary interface
to the BitBake tool.
This section presents the BitBake command syntax and provides
several execution examples.
</para>
<section id='usage-and-syntax'>
<title>Usage and syntax</title>
<para>
Following is the usage and syntax for BitBake:
<literallayout class='monospaced'>
$ bitbake -h
Usage: bitbake [options] [recipename/target ...]
Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
will provide the layer, BBFILES and other configuration information.
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-b BUILDFILE, --buildfile=BUILDFILE
Execute tasks from a specific .bb recipe directly.
WARNING: Does not handle any dependencies from other
recipes.
-k, --continue Continue as much as possible after an error. While the
target that failed and anything depending on it cannot
be built, as much as possible will be built before
stopping.
-a, --tryaltconfigs Continue with builds by trying to use alternative
providers where possible.
-f, --force Force the specified targets/task to run (invalidating
any existing stamp file).
-c CMD, --cmd=CMD Specify the task to execute. The exact options
available depend on the metadata. Some examples might
be 'compile' or 'populate_sysroot' or 'listtasks' may
give a list of the tasks available.
-C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
Invalidate the stamp for the specified task such as
'compile' and then run the default task for the
specified target(s).
-r PREFILE, --read=PREFILE
Read the specified file before bitbake.conf.
-R POSTFILE, --postread=POSTFILE
Read the specified file after bitbake.conf.
-v, --verbose Output more log message data to the terminal.
-D, --debug Increase the debug level. You can specify this more
than once.
-n, --dry-run Don't execute, just go through the motions.
-S DUMP_SIGNATURES, --dump-signatures=DUMP_SIGNATURES
Dump out the signature construction information, with
no task execution. Parameters are passed to the
signature handling code, use 'none' if no specific
handler is required.
-p, --parse-only Quit after parsing the BB recipes.
-s, --show-versions Show current and preferred versions of all recipes.
-e, --environment Show the global or per-package environment complete
with information about where variables were
set/changed.
-g, --graphviz Save dependency tree information for the specified
targets in the dot syntax.
-I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
Assume these dependencies don't exist and are already
provided (equivalent to ASSUME_PROVIDED). Useful to
make dependency graphs more appealing
-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
Show debug logging for the specified logging domains
-P, --profile Profile the command and save reports.
-u UI, --ui=UI The user interface to use (e.g. knotty, hob, depexp).
-t SERVERTYPE, --servertype=SERVERTYPE
Choose which server to use, process or xmlrpc.
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not.
--server-only Run bitbake without a UI, only starting a server
(cooker) process.
-B BIND, --bind=BIND The name/address for the bitbake server to bind to.
--no-setscene Do not run any setscene tasks. sstate will be ignored
and everything needed, built.
--remote-server=REMOTE_SERVER
Connect to the specified server.
-m, --kill-server Terminate the remote server.
--observe-only Connect to a server as an observing-only client.
--status-only Check the status of the remote bitbake server.
</literallayout>
</para>
</section>
<section id='bitbake-examples'>
<title>Examples</title>
<para>
This section presents some examples showing how to use BitBake.
</para>
<section id='example-executing-a-task-against-a-single-recipe'>
<title>Executing a Task Against a Single Recipe</title>
<para>
Executing tasks for a single recipe file is relatively simple.
You specify the file in question, and BitBake parses
it and executes the specified task.
If you do not specify a task, BitBake executes the default
task, which is "build”.
BitBake obeys inter-task dependencies when doing
so.
</para>
<para>
The following command runs the build task, which is
the default task, on the <filename>foo_1.0.bb</filename>
recipe file:
<literallayout class='monospaced'>
$ bitbake -b foo_1.0.bb
</literallayout>
The following command runs the clean task on the
<filename>foo.bb</filename> recipe file:
<literallayout class='monospaced'>
$ bitbake -b foo.bb -c clean
</literallayout>
<note>
The "-b" option explicitly does not handle recipe
dependencies.
Other than for debugging purposes, it is instead
recommended that you use the syntax presented in the
next section.
</note>
</para>
</section>
<section id='executing-tasks-against-a-set-of-recipe-files'>
<title>Executing Tasks Against a Set of Recipe Files</title>
<para>
There are a number of additional complexities introduced
when one wants to manage multiple <filename>.bb</filename>
files.
Clearly there needs to be a way to tell BitBake what
files are available, and of those, which you
want to execute.
There also needs to be a way for each recipe
to express its dependencies, both for build-time and
runtime.
There must be a way for you to express recipe preferences
when multiple recipes provide the same functionality, or when
there are multiple versions of a recipe.
</para>
<para>
The <filename>bitbake</filename> command, when not using
"--buildfile" or "-b" only accepts a "PROVIDES".
You cannot provide anything else.
By default, a recipe file generally "PROVIDES" its
"packagename" as shown in the following example:
<literallayout class='monospaced'>
$ bitbake foo
</literallayout>
This next example "PROVIDES" the package name and also uses
the "-c" option to tell BitBake to just execute the
<filename>do_clean</filename> task:
<literallayout class='monospaced'>
$ bitbake -c clean foo
</literallayout>
</para>
</section>
<section id='generating-dependency-graphs'>
<title>Generating Dependency Graphs</title>
<para>
BitBake is able to generate dependency graphs using
the <filename>dot</filename> syntax.
You can convert these graphs into images using the
<filename>dot</filename> tool from
<ulink url='http://www.graphviz.org'>Graphviz</ulink>.
</para>
<para>
When you generate a dependency graph, BitBake writes four files
to the current working directory:
<itemizedlist>
<listitem><para><emphasis><filename>package-depends.dot</filename>:</emphasis>
Shows BitBake's knowledge of dependencies between
runtime targets.
</para></listitem>
<listitem><para><emphasis><filename>pn-depends.dot</filename>:</emphasis>
Shows dependencies between build-time targets
(i.e. recipes).
</para></listitem>
<listitem><para><emphasis><filename>task-depends.dot</filename>:</emphasis>
Shows dependencies between tasks.
</para></listitem>
<listitem><para><emphasis><filename>pn-buildlist</filename>:</emphasis>
Shows a simple list of targets that are to be built.
</para></listitem>
</itemizedlist>
</para>
<para>
To stop depending on common depends, use the "-I" depend
option and BitBake omits them from the graph.
Leaving this information out can produce more readable graphs.
This way, you can remove from the graph
<filename>DEPENDS</filename> from inherited classes
such as <filename>base.bbclass</filename>.
</para>
<para>
Here are two examples that create dependency graphs.
The second example omits depends common in OpenEmbedded from
the graph:
<literallayout class='monospaced'>
$ bitbake -g foo
$ bitbake -g -I virtual/kernel -I eglibc foo
</literallayout>
</para>
</section>
</section>
</section>
</chapter>

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,978 @@
/*
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/bitbake-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title,
div.article .titlepage .title
{
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-image: url("figures/yocto-project-bw.png");
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

View File

@@ -0,0 +1,88 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<book id='bitbake-user-manual' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='figures/bitbake-title.png'
format='SVG'
align='left' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>
BitBake User Manual
</title>
<authorgroup>
<author>
<firstname>Richard Purdie, Chris Larson, and </firstname> <surname>Phil Blundell</surname>
<affiliation>
<orgname>BitBake Community</orgname>
</affiliation>
<email>bitbake-devel@lists.openembedded.org</email>
</author>
</authorgroup>
<!--
# Add in some revision history if we want it here.
<revhistory>
<revision>
<revnumber>x.x</revnumber>
<date>dd month year</date>
<revremark>Some relevent comment</revremark>
</revision>
<revision>
<revnumber>x.x</revnumber>
<date>dd month year</date>
<revremark>Some relevent comment</revremark>
</revision>
<revision>
<revnumber>x.x</revnumber>
<date>dd month year</date>
<revremark>Some relevent comment</revremark>
</revision>
<revision>
<revnumber>x.x</revnumber>
<date>dd month year</date>
<revremark>Some relevent comment</revremark>
</revision>
</revhistory>
-->
<copyright>
<year>2004-2014</year>
<holder>Richard Purdie</holder>
<holder>Chris Larson</holder>
<holder>and Phil Blundell</holder>
</copyright>
<legalnotice>
<para>
This work is licensed under the Creative Commons Attribution License.
To view a copy of this license, visit
<ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink>
or send a letter to Creative Commons, 444 Castro Street,
Suite 900, Mountain View, California 94041, USA.
</para>
</legalnotice>
</bookinfo>
<xi:include href="bitbake-user-manual-intro.xml"/>
<xi:include href="bitbake-user-manual-execution.xml"/>
<xi:include href="bitbake-user-manual-metadata.xml"/>
<xi:include href="bitbake-user-manual-fetching.xml"/>
<xi:include href="bitbake-user-manual-ref-variables.xml"/>
<xi:include href="bitbake-user-manual-hello.xml"/>
</book>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

View File

@@ -0,0 +1,281 @@
/* Feuille de style DocBook du projet Traduc.org */
/* DocBook CSS stylesheet of the Traduc.org project */
/* (c) Jean-Philippe Gu<47>rard - 14 ao<61>t 2004 */
/* (c) Jean-Philippe Gu<47>rard - 14 August 2004 */
/* Cette feuille de style est libre, vous pouvez la */
/* redistribuer et la modifier selon les termes de la Licence */
/* Art Libre. Vous trouverez un exemplaire de cette Licence sur */
/* http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
/* This work of art is free, you can redistribute it and/or */
/* modify it according to terms of the Free Art license. You */
/* will find a specimen of this license on the Copyleft */
/* Attitude web site: http://artlibre.org as well as on other */
/* sites. */
/* Please note that the French version of this licence as shown */
/* on http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
/* is only official licence of this document. The English */
/* is only provided to help you understand this licence. */
/* La derni<6E>re version de cette feuille de style est toujours */
/* disponible sur<75>: http://tigreraye.org/style.css */
/* Elle est <20>galement disponible sur<75>: */
/* http://www.traduc.org/docs/HOWTO/lecture/style.css */
/* The latest version of this stylesheet is available from: */
/* http://tigreraye.org/style.css */
/* It is also available on: */
/* http://www.traduc.org/docs/HOWTO/lecture/style.css */
/* N'h<>sitez pas <20> envoyer vos commentaires et corrections <20> */
/* Jean-Philippe Gu<47>rard <jean-philippe.guerard@tigreraye.org> */
/* Please send feedback and bug reports to */
/* Jean-Philippe Gu<47>rard <jean-philippe.guerard@tigreraye.org> */
/* $Id: style.css,v 1.14 2004/09/10 20:12:09 fevrier Exp fevrier $ */
/* Pr<50>sentation g<>n<EFBFBD>rale du document */
/* Overall document presentation */
body {
/*
font-family: Apolline, "URW Palladio L", Garamond, jGaramond,
"Bitstream Cyberbit", "Palatino Linotype", serif;
*/
margin: 7%;
background-color: white;
}
/* Taille du texte */
/* Text size */
* { font-size: 100%; }
/* Gestion des textes mis en relief imbriqu<71>s */
/* Embedded emphasis */
em { font-style: italic; }
em em { font-style: normal; }
em em em { font-style: italic; }
/* Titres */
/* Titles */
h1 { font-size: 200%; font-weight: 900; }
h2 { font-size: 160%; font-weight: 900; }
h3 { font-size: 130%; font-weight: bold; }
h4 { font-size: 115%; font-weight: bold; }
h5 { font-size: 108%; font-weight: bold; }
h6 { font-weight: bold; }
/* Nom de famille en petites majuscules (uniquement en fran<61>ais) */
/* Last names in small caps (for French only) */
*[class~="surname"]:lang(fr) { font-variant: small-caps; }
/* Blocs de citation */
/* Quotation blocs */
div[class~="blockquote"] {
border: solid 2px #AAA;
padding: 5px;
margin: 5px;
}
div[class~="blockquote"] > table {
border: none;
}
/* Blocs lit<69>raux<75>: fond gris clair */
/* Literal blocs: light gray background */
*[class~="literallayout"] {
background: #f0f0f0;
padding: 5px;
margin: 5px;
}
/* Programmes et captures texte<74>: fond bleu clair */
/* Listing and text screen snapshots: light blue background */
*[class~="programlisting"], *[class~="screen"] {
background: #f0f0ff;
padding: 5px;
margin: 5px;
}
/* Les textes <20> remplacer sont surlign<67>s en vert p<>le */
/* Replaceable text in highlighted in pale green */
*[class~="replaceable"] {
background-color: #98fb98;
font-style: normal; }
/* Tables<65>: fonds gris clair & bords simples */
/* Tables: light gray background and solid borders */
*[class~="table"] *[class~="title"] { width:100%; border: 0px; }
table {
border: 1px solid #aaa;
border-collapse: collapse;
padding: 2px;
margin: 5px;
}
/* Listes simples en style table */
/* Simples lists in table presentation */
table[class~="simplelist"] {
background-color: #F0F0F0;
margin: 5px;
border: solid 1px #AAA;
}
table[class~="simplelist"] td {
border: solid 1px #AAA;
}
/* Les tables */
/* Tables */
*[class~="table"] table {
background-color: #F0F0F0;
border: solid 1px #AAA;
}
*[class~="informaltable"] table { background-color: #F0F0F0; }
th,td {
vertical-align: baseline;
text-align: left;
padding: 0.1em 0.3em;
empty-cells: show;
}
/* Alignement des colonnes */
/* Colunms alignment */
td[align=center] , th[align=center] { text-align: center; }
td[align=right] , th[align=right] { text-align: right; }
td[align=left] , th[align=left] { text-align: left; }
td[align=justify] , th[align=justify] { text-align: justify; }
/* Pas de marge autour des images */
/* No inside margins for images */
img { border: 0; }
/* Les liens ne sont pas soulign<67>s */
/* No underlines for links */
:link , :visited , :active { text-decoration: none; }
/* Prudence<63>: cadre jaune et fond jaune clair */
/* Caution: yellow border and light yellow background */
*[class~="caution"] {
border: solid 2px yellow;
background-color: #ffffe0;
padding: 1em 6px 1em ;
margin: 5px;
}
*[class~="caution"] th {
vertical-align: middle
}
*[class~="caution"] table {
background-color: #ffffe0;
border: none;
}
/* Note importante<74>: cadre jaune et fond jaune clair */
/* Important: yellow border and light yellow background */
*[class~="important"] {
border: solid 2px yellow;
background-color: #ffffe0;
padding: 1em 6px 1em;
margin: 5px;
}
*[class~="important"] th {
vertical-align: middle
}
*[class~="important"] table {
background-color: #ffffe0;
border: none;
}
/* Mise en <20>vidence<63>: texte l<>g<EFBFBD>rement plus grand */
/* Highlights: slightly larger texts */
*[class~="highlights"] {
font-size: 110%;
}
/* Note<74>: cadre bleu et fond bleu clair */
/* Notes: blue border and light blue background */
*[class~="note"] {
border: solid 2px #7099C5;
background-color: #f0f0ff;
padding: 1em 6px 1em ;
margin: 5px;
}
*[class~="note"] th {
vertical-align: middle
}
*[class~="note"] table {
background-color: #f0f0ff;
border: none;
}
/* Astuce<63>: cadre vert et fond vert clair */
/* Tip: green border and light green background */
*[class~="tip"] {
border: solid 2px #00ff00;
background-color: #f0ffff;
padding: 1em 6px 1em ;
margin: 5px;
}
*[class~="tip"] th {
vertical-align: middle;
}
*[class~="tip"] table {
background-color: #f0ffff;
border: none;
}
/* Avertissement<6E>: cadre rouge et fond rouge clair */
/* Warning: red border and light red background */
*[class~="warning"] {
border: solid 2px #ff0000;
background-color: #fff0f0;
padding: 1em 6px 1em ;
margin: 5px;
}
*[class~="warning"] th {
vertical-align: middle;
}
*[class~="warning"] table {
background-color: #fff0f0;
border: none;
}
/* Fin */
/* The End */

View File

@@ -89,7 +89,7 @@ quit after parsing the BB files (developers only)
show current and preferred versions of all packages
.TP
.B \-e, \-\-environment
show the global or per-recipe environment (this is what used to be bbread)
show the global or per-package environment (this is what used to be bbread)
.TP
.B \-g, \-\-graphviz
emit the dependency trees of the specified packages in the dot syntax
@@ -105,7 +105,7 @@ Show debug logging for the specified logging domains
profile the command and print a report
.TP
.B \-uUI, \-\-ui=UI
User interface to use. Currently, knotty, taskexp or ncurses can be specified as UI.
User interface to use. Currently, hob, depexp, goggle or ncurses can be specified as UI.
.TP
.B \-tSERVERTYPE, \-\-servertype=SERVERTYPE
Choose which server to use, none, process or xmlrpc.

View File

@@ -1,101 +0,0 @@
# Configuration file for the Sphinx documentation builder.
#
# This file only contains a selection of the most common options. For a full
# list see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html
# -- Path setup --------------------------------------------------------------
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
# import os
# import sys
# sys.path.insert(0, os.path.abspath('.'))
import sys
import datetime
current_version = "dev"
# String used in sidebar
version = 'Version: ' + current_version
if current_version == 'dev':
version = 'Version: Current Development'
# Version seen in documentation_options.js and hence in js switchers code
release = current_version
# -- Project information -----------------------------------------------------
project = 'Bitbake'
copyright = '2004-%s, Richard Purdie, Chris Larson, and Phil Blundell' \
% datetime.datetime.now().year
author = 'Richard Purdie, Chris Larson, and Phil Blundell'
# external links and substitutions
extlinks = {
'yocto_docs': ('https://docs.yoctoproject.org%s', None),
'oe_lists': ('https://lists.openembedded.org%s', None),
}
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
'sphinx.ext.autosectionlabel',
'sphinx.ext.extlinks',
]
autosectionlabel_prefix_document = True
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
# master document name. The default changed from contents to index. so better
# set it ourselves.
master_doc = 'index'
# create substitution for project configuration variables
rst_prolog = """
.. |project_name| replace:: %s
.. |copyright| replace:: %s
.. |author| replace:: %s
""" % (project, copyright, author)
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
try:
import sphinx_rtd_theme
html_theme = 'sphinx_rtd_theme'
except ImportError:
sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\
\nPlease make sure to install the sphinx_rtd_theme python package.\n")
sys.exit(1)
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['sphinx-static']
# Add customm CSS and JS files
html_css_files = ['theme_overrides.css']
html_js_files = ['switchers.js']
# Hide 'Created using Sphinx' text
html_show_sphinx = False
# Add 'Last updated' on each page
html_last_updated_fmt = '%b %d, %Y'
# Remove the trailing 'dot' in section numbers
html_secnumber_suffix = " "

View File

@@ -1,3 +0,0 @@
=====
Index
=====

View File

@@ -1,38 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
===================
BitBake User Manual
===================
|
.. toctree::
:caption: Table of Contents
:numbered:
bitbake-user-manual/bitbake-user-manual-intro
bitbake-user-manual/bitbake-user-manual-execution
bitbake-user-manual/bitbake-user-manual-metadata
bitbake-user-manual/bitbake-user-manual-fetching
bitbake-user-manual/bitbake-user-manual-ref-variables
bitbake-user-manual/bitbake-user-manual-hello
.. toctree::
:maxdepth: 1
:hidden:
genindex
releases
----
.. include:: <xhtml1-lat1.txt>
| BitBake Community
| Copyright |copy| |copyright|
| <bitbake-devel@lists.openembedded.org>
This work is licensed under the Creative Commons Attribution License. To view a
copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send
a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View,
California 94041, USA.

59
bitbake/doc/poky.ent Normal file
View File

@@ -0,0 +1,59 @@
<!ENTITY DISTRO "1.4">
<!ENTITY DISTRO_NAME "tbd">
<!ENTITY YOCTO_DOC_VERSION "1.4">
<!ENTITY POKYVERSION "8.0">
<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
<!ENTITY COPYRIGHT_YEAR "2010-2013">
<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
<!ENTITY OE_HOME_URL "http://www.openembedded.org">
<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
<!ENTITY OH_HOME_URL "http://o-hand.com">
<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads">
<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org">
<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;">
<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3">
<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
<!ENTITY ECLIPSE_JUNO_URL "&ECLIPSE_DL_URL;/releases/juno">
<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo">
<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html">
<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
<!ENTITY OE_INIT_FILE "oe-init-build-env">
<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \
build-essential chrpath">
<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
ccache">
<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
diffstat texinfo python-curses">
<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">

View File

@@ -1,130 +0,0 @@
.. SPDX-License-Identifier: CC-BY-2.5
=========================
Current Release Manuals
=========================
****************************
3.1 'dunfell' Release Series
****************************
- :yocto_docs:`3.1 BitBake User Manual </3.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.1.1 BitBake User Manual </3.1.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.1.2 BitBake User Manual </3.1.2/bitbake-user-manual/bitbake-user-manual.html>`
==========================
Previous Release Manuals
==========================
*************************
3.0 'zeus' Release Series
*************************
- :yocto_docs:`3.0 BitBake User Manual </3.0/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.1 BitBake User Manual </3.0.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.2 BitBake User Manual </3.0.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.3 BitBake User Manual </3.0.3/bitbake-user-manual/bitbake-user-manual.html>`
****************************
2.7 'warrior' Release Series
****************************
- :yocto_docs:`2.7 BitBake User Manual </2.7/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.1 BitBake User Manual </2.7.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.2 BitBake User Manual </2.7.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.3 BitBake User Manual </2.7.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.4 BitBake User Manual </2.7.4/bitbake-user-manual/bitbake-user-manual.html>`
*************************
2.6 'thud' Release Series
*************************
- :yocto_docs:`2.6 BitBake User Manual </2.6/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.1 BitBake User Manual </2.6.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.2 BitBake User Manual </2.6.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.3 BitBake User Manual </2.6.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.4 BitBake User Manual </2.6.4/bitbake-user-manual/bitbake-user-manual.html>`
*************************
2.5 'sumo' Release Series
*************************
- :yocto_docs:`2.5 BitBake User Manual </2.5/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.5.1 BitBake User Manual </2.5.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.5.2 BitBake User Manual </2.5.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.5.3 BitBake User Manual </2.5.3/bitbake-user-manual/bitbake-user-manual.html>`
**************************
2.4 'rocko' Release Series
**************************
- :yocto_docs:`2.4 BitBake User Manual </2.4/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.1 BitBake User Manual </2.4.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.2 BitBake User Manual </2.4.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.3 BitBake User Manual </2.4.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.4 BitBake User Manual </2.4.4/bitbake-user-manual/bitbake-user-manual.html>`
*************************
2.3 'pyro' Release Series
*************************
- :yocto_docs:`2.3 BitBake User Manual </2.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.1 BitBake User Manual </2.3.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.2 BitBake User Manual </2.3.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.3 BitBake User Manual </2.3.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.4 BitBake User Manual </2.3.4/bitbake-user-manual/bitbake-user-manual.html>`
**************************
2.2 'morty' Release Series
**************************
- :yocto_docs:`2.2 BitBake User Manual </2.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.1 BitBake User Manual </2.2.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.2 BitBake User Manual </2.2.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.3 BitBake User Manual </2.2.3/bitbake-user-manual/bitbake-user-manual.html>`
****************************
2.1 'krogoth' Release Series
****************************
- :yocto_docs:`2.1 BitBake User Manual </2.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.1 BitBake User Manual </2.1.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.2 BitBake User Manual </2.1.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.3 BitBake User Manual </2.1.3/bitbake-user-manual/bitbake-user-manual.html>`
***************************
2.0 'jethro' Release Series
***************************
- :yocto_docs:`1.9 BitBake User Manual </1.9/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0 BitBake User Manual </2.0/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.1 BitBake User Manual </2.0.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.2 BitBake User Manual </2.0.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.3 BitBake User Manual </2.0.3/bitbake-user-manual/bitbake-user-manual.html>`
*************************
1.8 'fido' Release Series
*************************
- :yocto_docs:`1.8 BitBake User Manual </1.8/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.8.1 BitBake User Manual </1.8.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.8.2 BitBake User Manual </1.8.2/bitbake-user-manual/bitbake-user-manual.html>`
**************************
1.7 'dizzy' Release Series
**************************
- :yocto_docs:`1.7 BitBake User Manual </1.7/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.1 BitBake User Manual </1.7.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.2 BitBake User Manual </1.7.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.3 BitBake User Manual </1.7.3/bitbake-user-manual/bitbake-user-manual.html>`
**************************
1.6 'daisy' Release Series
**************************
- :yocto_docs:`1.6 BitBake User Manual </1.6/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.1 BitBake User Manual </1.6.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.2 BitBake User Manual </1.6.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.3 BitBake User Manual </1.6.3/bitbake-user-manual/bitbake-user-manual.html>`

View File

@@ -1,233 +0,0 @@
(function() {
'use strict';
var all_versions = {
'dev': 'dev (3.2)',
'3.1.2': '3.1.2',
'3.0.3': '3.0.3',
'2.7.4': '2.7.4',
};
var all_doctypes = {
'single': 'Individual Webpages',
'mega': "All-in-one 'Mega' Manual",
};
// Simple version comparision
// Return 1 if a > b
// Return -1 if a < b
// Return 0 if a == b
function ver_compare(a, b) {
if (a == "dev") {
return 1;
}
if (a === b) {
return 0;
}
var a_components = a.split(".");
var b_components = b.split(".");
var len = Math.min(a_components.length, b_components.length);
// loop while the components are equal
for (var i = 0; i < len; i++) {
// A bigger than B
if (parseInt(a_components[i]) > parseInt(b_components[i])) {
return 1;
}
// B bigger than A
if (parseInt(a_components[i]) < parseInt(b_components[i])) {
return -1;
}
}
// If one's a prefix of the other, the longer one is greater.
if (a_components.length > b_components.length) {
return 1;
}
if (a_components.length < b_components.length) {
return -1;
}
// Otherwise they are the same.
return 0;
}
function build_version_select(current_series, current_version) {
var buf = ['<select>'];
$.each(all_versions, function(version, title) {
var series = version.substr(0, 3);
if (series == current_series) {
if (version == current_version)
buf.push('<option value="' + version + '" selected="selected">' + title + '</option>');
else
buf.push('<option value="' + version + '">' + title + '</option>');
if (version != current_version)
buf.push('<option value="' + current_version + '" selected="selected">' + current_version + '</option>');
} else {
buf.push('<option value="' + version + '">' + title + '</option>');
}
});
buf.push('</select>');
return buf.join('');
}
function build_doctype_select(current_doctype) {
var buf = ['<select>'];
$.each(all_doctypes, function(doctype, title) {
if (doctype == current_doctype)
buf.push('<option value="' + doctype + '" selected="selected">' +
all_doctypes[current_doctype] + '</option>');
else
buf.push('<option value="' + doctype + '">' + title + '</option>');
});
if (!(current_doctype in all_doctypes)) {
// In case we're browsing a doctype that is not yet in all_doctypes.
buf.push('<option value="' + current_doctype + '" selected="selected">' +
current_doctype + '</option>');
all_doctypes[current_doctype] = current_doctype;
}
buf.push('</select>');
return buf.join('');
}
function navigate_to_first_existing(urls) {
// Navigate to the first existing URL in urls.
var url = urls.shift();
// Web browsers won't redirect file:// urls to file urls using ajax but
// its useful for local testing
if (url.startsWith("file://")) {
window.location.href = url;
return;
}
if (urls.length == 0) {
window.location.href = url;
return;
}
$.ajax({
url: url,
success: function() {
window.location.href = url;
},
error: function() {
navigate_to_first_existing(urls);
}
});
}
function get_docroot_url() {
var url = window.location.href;
var root = DOCUMENTATION_OPTIONS.URL_ROOT;
var urlarray = url.split('/');
// Trim off anything after '/'
urlarray.pop();
var depth = (root.match(/\.\.\//g) || []).length;
for (var i = 0; i < depth; i++) {
urlarray.pop();
}
return urlarray.join('/') + '/';
}
function on_version_switch() {
var selected_version = $(this).children('option:selected').attr('value');
var url = window.location.href;
var current_version = DOCUMENTATION_OPTIONS.VERSION;
var docroot = get_docroot_url()
var new_versionpath = selected_version + '/';
if (selected_version == "dev")
new_versionpath = '';
// dev versions have no version prefix
if (current_version == "dev") {
var new_url = docroot + new_versionpath + url.replace(docroot, "");
var fallback_url = docroot + new_versionpath;
} else {
var new_url = url.replace('/' + current_version + '/', '/' + new_versionpath);
var fallback_url = new_url.replace(url.replace(docroot, ""), "");
}
console.log(get_docroot_url())
console.log(url + " to url " + new_url);
console.log(url + " to fallback " + fallback_url);
if (new_url != url) {
navigate_to_first_existing([
new_url,
fallback_url,
'https://www.yoctoproject.org/docs/',
]);
}
}
function on_doctype_switch() {
var selected_doctype = $(this).children('option:selected').attr('value');
var url = window.location.href;
if (selected_doctype == 'mega') {
var docroot = get_docroot_url()
var current_version = DOCUMENTATION_OPTIONS.VERSION;
// Assume manuals before 3.2 are using old docbook mega-manual
if (ver_compare(current_version, "3.2") < 0) {
var new_url = docroot + "mega-manual/mega-manual.html";
} else {
var new_url = docroot + "singleindex.html";
}
} else {
var new_url = url.replace("singleindex.html", "index.html")
}
if (new_url != url) {
navigate_to_first_existing([
new_url,
'https://www.yoctoproject.org/docs/',
]);
}
}
// Returns the current doctype based upon the url
function doctype_segment_from_url(url) {
if (url.includes("singleindex") || url.includes("mega-manual"))
return "mega";
return "single";
}
$(document).ready(function() {
var release = DOCUMENTATION_OPTIONS.VERSION;
var current_doctype = doctype_segment_from_url(window.location.href);
var current_series = release.substr(0, 3);
var version_select = build_version_select(current_series, release);
$('.version_switcher_placeholder').html(version_select);
$('.version_switcher_placeholder select').bind('change', on_version_switch);
var doctype_select = build_doctype_select(current_doctype);
$('.doctype_switcher_placeholder').html(doctype_select);
$('.doctype_switcher_placeholder select').bind('change', on_doctype_switch);
if (ver_compare(release, "3.1") < 0) {
$('#outdated-warning').html('Version ' + release + ' of the project is now considered obsolete, please select and use a more recent version');
$('#outdated-warning').css('padding', '.5em');
} else if (release != "dev") {
$.each(all_versions, function(version, title) {
var series = version.substr(0, 3);
if (series == current_series && version != release) {
$('#outdated-warning').html('This document is for outdated version ' + release + ', you should select the latest release version in this series, ' + version + '.');
$('#outdated-warning').css('padding', '.5em');
}
});
}
});
})();

View File

@@ -1,162 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
*/
body {
font-family: Verdana, Sans, sans-serif;
margin: 0em auto;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
em {
font-weight: bold;
}
.pre {
font-size: medium;
font-family: Courier, monospace;
}
.wy-nav-content a {
text-decoration: underline;
color: #444;
background: transparent;
}
.wy-nav-content a:hover {
text-decoration: underline;
background-color: #dedede;
}
.wy-nav-content a:visited {
color: #444;
}
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
@media screen {
/* content column
*
* RTD theme's default is 800px as max width for the content, but we have
* tables with tons of columns, which need the full width of the view-port.
*/
.wy-nav-content{max-width: none; }
/* inline literal: drop the borderbox, padding and red color */
code, .rst-content tt, .rst-content code {
color: inherit;
border: none;
padding: unset;
background: inherit;
font-size: 85%;
}
.rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
color: inherit;
}
/* Admonition should be gray, not blue or green */
.rst-content .note .admonition-title,
.rst-content .tip .admonition-title,
.rst-content .warning .admonition-title,
.rst-content .caution .admonition-title,
.rst-content .important .admonition-title {
background: #f0f0f2;
color: #00557D;
}
.rst-content .note,
.rst-content .tip,
.rst-content .important,
.rst-content .warning,
.rst-content .caution {
background: #f0f0f2;
}
/* Remove the icon in front of note/tip element, and before the logo */
.icon-home:before, .rst-content .admonition-title:before {
display: none
}
/* a custom informalexample container is used in some doc */
.informalexample {
border: 1px solid;
border-color: #aaa;
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
/* Remove the blue background in the top left corner, around the logo */
.wy-side-nav-search {
background: inherit;
}
}

1
bitbake/doc/template/Vera.xml vendored Normal file

File diff suppressed because one or more lines are too long

1
bitbake/doc/template/VeraMoBd.xml vendored Normal file

File diff suppressed because one or more lines are too long

1
bitbake/doc/template/VeraMono.xml vendored Normal file

File diff suppressed because one or more lines are too long

64
bitbake/doc/template/db-pdf.xsl vendored Normal file
View File

@@ -0,0 +1,64 @@
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl" />
<!-- check project-plan.sh for how this is generated, needed to tweak
the cover page
-->
<xsl:include href="/tmp/titlepage.xsl"/>
<!-- To force a page break in document, i.e per section add a
<?hard-pagebreak?> tag.
-->
<xsl:template match="processing-instruction('hard-pagebreak')">
<fo:block break-before='page' />
</xsl:template>
<!--Fix for defualt indent getting TOC all wierd..
See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html
FIXME: must be a better fix
-->
<xsl:param name="body.start.indent" select="'0'"/>
<!--<xsl:param name="title.margin.left" select="'0'"/>-->
<!-- stop long-ish header titles getting wrapped -->
<xsl:param name="header.column.widths">1 10 1</xsl:param>
<!-- customise headers and footers a little -->
<xsl:template name="head.sep.rule">
<xsl:if test="$header.rule != 0">
<xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute>
<xsl:attribute name="border-bottom-style">solid</xsl:attribute>
<xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute>
</xsl:if>
</xsl:template>
<xsl:template name="foot.sep.rule">
<xsl:if test="$footer.rule != 0">
<xsl:attribute name="border-top-width">0.5pt</xsl:attribute>
<xsl:attribute name="border-top-style">solid</xsl:attribute>
<xsl:attribute name="border-top-color">#cccccc</xsl:attribute>
</xsl:if>
</xsl:template>
<xsl:attribute-set name="header.content.properties">
<xsl:attribute name="color">#cccccc</xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="footer.content.properties">
<xsl:attribute name="color">#cccccc</xsl:attribute>
</xsl:attribute-set>
<!-- general settings -->
<xsl:param name="fop1.extensions" select="1"></xsl:param>
<xsl:param name="paper.type" select="'A4'"></xsl:param>
<xsl:param name="section.autolabel" select="1"></xsl:param>
<xsl:param name="body.font.family" select="'verasans'"></xsl:param>
<xsl:param name="title.font.family" select="'verasans'"></xsl:param>
<xsl:param name="monospace.font.family" select="'veramono'"></xsl:param>
</xsl:stylesheet>

58
bitbake/doc/template/fop-config.xml vendored Normal file
View File

@@ -0,0 +1,58 @@
<fop version="1.0">
<!-- Strict user configuration -->
<strict-configuration>true</strict-configuration>
<!-- Strict FO validation -->
<strict-validation>true</strict-validation>
<!--
Set the baseDir so common/openedhand.svg references in plans still
work ok. Note, relative file references to current dir should still work.
-->
<base>../template</base>
<font-base>../template</font-base>
<!-- Source resolution in dpi (dots/pixels per inch) for determining the
size of pixels in SVG and bitmap images, default: 72dpi -->
<!-- <source-resolution>72</source-resolution> -->
<!-- Target resolution in dpi (dots/pixels per inch) for specifying the
target resolution for generated bitmaps, default: 72dpi -->
<!-- <target-resolution>72</target-resolution> -->
<!-- default page-height and page-width, in case
value is specified as auto -->
<default-page-settings height="11in" width="8.26in"/>
<!-- <use-cache>false</use-cache> -->
<renderers>
<renderer mime="application/pdf">
<fonts>
<font metrics-file="VeraMono.xml"
kerning="yes"
embed-url="VeraMono.ttf">
<font-triplet name="veramono" style="normal" weight="normal"/>
</font>
<font metrics-file="VeraMoBd.xml"
kerning="yes"
embed-url="VeraMoBd.ttf">
<font-triplet name="veramono" style="normal" weight="bold"/>
</font>
<font metrics-file="Vera.xml"
kerning="yes"
embed-url="Vera.ttf">
<font-triplet name="verasans" style="normal" weight="normal"/>
<font-triplet name="verasans" style="normal" weight="bold"/>
<font-triplet name="verasans" style="italic" weight="normal"/>
<font-triplet name="verasans" style="italic" weight="bold"/>
</font>
<auto-detect/>
</fonts>
</renderer>
</renderers>
</fop>

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,51 @@
#!/bin/sh
if [ -z "$1" -o -z "$2" ]; then
echo "usage: [-v] $0 <docbook file> <templatedir>"
echo
echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets"
echo " installed for this to work!"
echo
exit 0
fi
FO=`echo $1 | sed s/.xml/.fo/` || exit 1
PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1
TEMPLATEDIR=$2
##
# These URI should be rewritten by your distribution's xml catalog to
# match your localy installed XSL stylesheets.
XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current"
# Creates a temporary XSL stylesheet based on titlepage.xsl
xsltproc -o /tmp/titlepage.xsl \
--xinclude \
$XSL_BASE_URI/template/titlepage.xsl \
$TEMPLATEDIR/titlepage.templates.xml || exit 1
# Creates the file needed for FOP
xsltproc --xinclude \
--stringparam hyphenate false \
--stringparam formal.title.placement "figure after" \
--stringparam ulink.show 1 \
--stringparam body.font.master 9 \
--stringparam title.font.master 11 \
--stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \
--stringparam chapter.autolabel 1 \
--stringparam appendix.autolabel A \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--output $FO \
$TEMPLATEDIR/db-pdf.xsl \
$1 || exit 1
# Invokes the Java version of FOP. Uses the additional configuration file common/fop-config.xml
fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1
rm -f $FO
rm -f /tmp/titlepage.xsl
echo
echo " #### Success! $PDF ready. ####"
echo

View File

@@ -1,33 +1,48 @@
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# This is a copy on write dictionary and set which abuses classes to try and be nice and fast.
#
# Copyright (C) 2006 Tim Ansell
# Copyright (C) 2006 Tim Amsell
#
# Please Note:
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
#Please Note:
# Be careful when using mutable types (ie Dict and Lists) - operations involving these are SLOW.
# Assign a file to __warn__ to get warnings about slow operations.
#
from __future__ import print_function
import copy
import types
ImmutableTypes = (
types.NoneType,
bool,
complex,
float,
int,
long,
tuple,
frozenset,
str
basestring
)
MUTABLE = "__mutable__"
class COWMeta(type):
pass
class COWDictMeta(COWMeta):
__warn__ = False
__hasmutable__ = False
@@ -36,20 +51,17 @@ class COWDictMeta(COWMeta):
def __str__(cls):
# FIXME: I have magic numbers!
return "<COWDict Level: %i Current Keys: %i>" % (cls.__count__, len(cls.__dict__) - 3)
__repr__ = __str__
def cow(cls):
class C(cls):
__count__ = cls.__count__ + 1
return C
copy = cow
__call__ = cow
def __setitem__(cls, key, value):
if value is not None and not isinstance(value, ImmutableTypes):
if not isinstance(value, ImmutableTypes):
if not isinstance(value, COWMeta):
cls.__hasmutable__ = True
key += MUTABLE
@@ -76,9 +88,8 @@ class COWDictMeta(COWMeta):
return value
__getmarker__ = []
def __getreadonly__(cls, key, default=__getmarker__):
"""
"""\
Get a value (even if mutable) which you promise not to change.
"""
return cls.__getitem__(key, default, True)
@@ -105,7 +116,7 @@ class COWDictMeta(COWMeta):
cls.__setitem__(key, cls.__marker__)
def __revertitem__(cls, key):
if key not in cls.__dict__:
if not cls.__dict__.has_key(key):
key += MUTABLE
delattr(cls, key)
@@ -141,33 +152,28 @@ class COWDictMeta(COWMeta):
yield value
if type == "items":
yield (key, value)
return
raise StopIteration()
def iterkeys(cls):
return cls.iter("keys")
def itervalues(cls, readonly=False):
if not cls.__warn__ is False and cls.__hasmutable__ and readonly is False:
print("Warning: If you aren't going to change any of the values call with True.", file=cls.__warn__)
print("Warning: If you arn't going to change any of the values call with True.", file=cls.__warn__)
return cls.iter("values", readonly)
def iteritems(cls, readonly=False):
if not cls.__warn__ is False and cls.__hasmutable__ and readonly is False:
print("Warning: If you aren't going to change any of the values call with True.", file=cls.__warn__)
print("Warning: If you arn't going to change any of the values call with True.", file=cls.__warn__)
return cls.iter("items", readonly)
class COWSetMeta(COWDictMeta):
def __str__(cls):
# FIXME: I have magic numbers!
return "<COWSet Level: %i Current Keys: %i>" % (cls.__count__, len(cls.__dict__) - 3)
return "<COWSet Level: %i Current Keys: %i>" % (cls.__count__, len(cls.__dict__) -3)
__repr__ = __str__
def cow(cls):
class C(cls):
__count__ = cls.__count__ + 1
return C
def add(cls, value):
@@ -177,7 +183,7 @@ class COWSetMeta(COWDictMeta):
COWDictMeta.__delitem__(cls, repr(hash(value)))
def __in__(cls, value):
return repr(hash(value)) in COWDictMeta
return COWDictMeta.has_key(repr(hash(value)))
def iterkeys(cls):
raise TypeError("sets don't have keys")
@@ -185,11 +191,133 @@ class COWSetMeta(COWDictMeta):
def iteritems(cls):
raise TypeError("sets don't have 'items'")
# These are the actual classes you use!
class COWDictBase(metaclass=COWDictMeta):
class COWDictBase(object):
__metaclass__ = COWDictMeta
__count__ = 0
class COWSetBase(metaclass=COWSetMeta):
class COWSetBase(object):
__metaclass__ = COWSetMeta
__count__ = 0
if __name__ == "__main__":
import sys
COWDictBase.__warn__ = sys.stderr
a = COWDictBase()
print("a", a)
a['a'] = 'a'
a['b'] = 'b'
a['dict'] = {}
b = a.copy()
print("b", b)
b['c'] = 'b'
print()
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems():
print(x)
print()
b['dict']['a'] = 'b'
b['a'] = 'c'
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems():
print(x)
print()
try:
b['dict2']
except KeyError as e:
print("Okay!")
a['set'] = COWSetBase()
a['set'].add("o1")
a['set'].add("o1")
a['set'].add("o2")
print("a", a)
for x in a['set'].itervalues():
print(x)
print("--")
print("b", b)
for x in b['set'].itervalues():
print(x)
print()
b['set'].add('o3')
print("a", a)
for x in a['set'].itervalues():
print(x)
print("--")
print("b", b)
for x in b['set'].itervalues():
print(x)
print()
a['set2'] = set()
a['set2'].add("o1")
a['set2'].add("o1")
a['set2'].add("o2")
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems(readonly=True):
print(x)
print()
del b['b']
try:
print(b['b'])
except KeyError:
print("Yay! deleted key raises error")
if b.has_key('b'):
print("Boo!")
else:
print("Yay - has_key with delete works!")
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems(readonly=True):
print(x)
print()
b.__revertitem__('b')
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems(readonly=True):
print(x)
print()
b.__revertitem__('dict')
print("a", a)
for x in a.iteritems():
print(x)
print("--")
print("b", b)
for x in b.iteritems(readonly=True):
print(x)
print()

View File

@@ -1,3 +1,5 @@
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# BitBake Build System Python Library
#
@@ -6,14 +8,24 @@
#
# Based on Gentoo's portage.py.
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
__version__ = "1.52.0"
__version__ = "1.22.0"
import sys
if sys.version_info < (3, 6, 0):
raise RuntimeError("Sorry, python 3.6.0 or later is required for this version of bitbake")
if sys.version_info < (2, 7, 3):
raise RuntimeError("Sorry, python 2.7.3 or later is required for this version of bitbake")
class BBHandledException(Exception):
@@ -21,8 +33,8 @@ class BBHandledException(Exception):
The big dilemma for generic bitbake code is what information to give the user
when an exception occurs. Any exception inheriting this base exception class
has already provided information to the user via some 'fired' message type such as
an explicitly fired event using bb.fire, or a bb.error message. If bitbake
encounters an exception derived from this class, no backtrace or other information
an explicitly fired event using bb.fire, or a bb.error message. If bitbake
encounters an exception derived from this class, no backtrace or other information
will be given to the user, its assumed the earlier event provided the relevant information.
"""
pass
@@ -35,32 +47,15 @@ class NullHandler(logging.Handler):
def emit(self, record):
pass
class BBLoggerMixin(object):
def __init__(self, *args, **kwargs):
# Does nothing to allow calling super() from derived classes
pass
def setup_bblogger(self, name):
Logger = logging.getLoggerClass()
class BBLogger(Logger):
def __init__(self, name):
if name.split(".")[0] == "BitBake":
self.debug = self._debug_helper
def _debug_helper(self, *args, **kwargs):
return self.bbdebug(1, *args, **kwargs)
def debug2(self, *args, **kwargs):
return self.bbdebug(2, *args, **kwargs)
def debug3(self, *args, **kwargs):
return self.bbdebug(3, *args, **kwargs)
self.debug = self.bbdebug
Logger.__init__(self, name)
def bbdebug(self, level, msg, *args, **kwargs):
loglevel = logging.DEBUG - level + 1
if not bb.event.worker_pid:
if self.name in bb.msg.loggerDefaultDomains and loglevel > (bb.msg.loggerDefaultDomains[self.name]):
return
if loglevel < bb.msg.loggerDefaultLogLevel:
return
return self.log(loglevel, msg, *args, **kwargs)
return self.log(logging.DEBUG - level + 1, msg, *args, **kwargs)
def plain(self, msg, *args, **kwargs):
return self.log(logging.INFO + 1, msg, *args, **kwargs)
@@ -68,59 +63,13 @@ class BBLoggerMixin(object):
def verbose(self, msg, *args, **kwargs):
return self.log(logging.INFO - 1, msg, *args, **kwargs)
def verbnote(self, msg, *args, **kwargs):
return self.log(logging.INFO + 2, msg, *args, **kwargs)
Logger = logging.getLoggerClass()
class BBLogger(Logger, BBLoggerMixin):
def __init__(self, name, *args, **kwargs):
self.setup_bblogger(name)
super().__init__(name, *args, **kwargs)
logging.raiseExceptions = False
logging.setLoggerClass(BBLogger)
class BBLoggerAdapter(logging.LoggerAdapter, BBLoggerMixin):
def __init__(self, logger, *args, **kwargs):
self.setup_bblogger(logger.name)
super().__init__(logger, *args, **kwargs)
if sys.version_info < (3, 6):
# These properties were added in Python 3.6. Add them in older versions
# for compatibility
@property
def manager(self):
return self.logger.manager
@manager.setter
def manager(self, value):
self.logger.manager = value
@property
def name(self):
return self.logger.name
def __repr__(self):
logger = self.logger
level = logger.getLevelName(logger.getEffectiveLevel())
return '<%s %s (%s)>' % (self.__class__.__name__, logger.name, level)
logging.LoggerAdapter = BBLoggerAdapter
logger = logging.getLogger("BitBake")
logger.addHandler(NullHandler())
logger.setLevel(logging.DEBUG - 2)
mainlogger = logging.getLogger("BitBake.Main")
class PrefixLoggerAdapter(logging.LoggerAdapter):
def __init__(self, prefix, logger):
super().__init__(logger, {})
self.__msg_prefix = prefix
def process(self, msg, kwargs):
return "%s%s" %(self.__msg_prefix, msg), kwargs
# This has to be imported after the setLoggerClass, as the import of bb.msg
# can result in construction of the various loggers.
import bb.msg
@@ -130,43 +79,32 @@ sys.modules['bb.fetch'] = sys.modules['bb.fetch2']
# Messaging convenience functions
def plain(*args):
mainlogger.plain(''.join(args))
logger.plain(''.join(args))
def debug(lvl, *args):
if isinstance(lvl, str):
mainlogger.warning("Passed invalid debug level '%s' to bb.debug", lvl)
if isinstance(lvl, basestring):
logger.warn("Passed invalid debug level '%s' to bb.debug", lvl)
args = (lvl,) + args
lvl = 1
mainlogger.bbdebug(lvl, ''.join(args))
logger.debug(lvl, ''.join(args))
def note(*args):
mainlogger.info(''.join(args))
logger.info(''.join(args))
#
# A higher prioity note which will show on the console but isn't a warning
#
# Something is happening the user should be aware of but they probably did
# something to make it happen
#
def verbnote(*args):
mainlogger.verbnote(''.join(args))
#
# Warnings - things the user likely needs to pay attention to and fix
#
def warn(*args):
mainlogger.warning(''.join(args))
logger.warn(''.join(args))
def error(*args, **kwargs):
mainlogger.error(''.join(args), extra=kwargs)
def error(*args):
logger.error(''.join(args))
def fatal(*args):
logger.critical(''.join(args))
sys.exit(1)
def fatal(*args, **kwargs):
mainlogger.critical(''.join(args), extra=kwargs)
raise BBHandledException()
def deprecated(func, name=None, advice=""):
"""This is a decorator which can be used to mark functions
as deprecated. It will result in a warning being emitted
as deprecated. It will result in a warning being emmitted
when the function is used."""
import warnings

View File

@@ -1,31 +0,0 @@
#
# SPDX-License-Identifier: GPL-2.0-only
#
import itertools
import json
# The Python async server defaults to a 64K receive buffer, so we hardcode our
# maximum chunk size. It would be better if the client and server reported to
# each other what the maximum chunk sizes were, but that will slow down the
# connection setup with a round trip delay so I'd rather not do that unless it
# is necessary
DEFAULT_MAX_CHUNK = 32 * 1024
def chunkify(msg, max_chunk):
if len(msg) < max_chunk - 1:
yield ''.join((msg, "\n"))
else:
yield ''.join((json.dumps({
'chunk-stream': None
}), "\n"))
args = [iter(msg)] * (max_chunk - 1)
for m in map(''.join, itertools.zip_longest(*args, fillvalue='')):
yield ''.join(itertools.chain(m, "\n"))
yield "\n"
from .client import AsyncClient, Client
from .serv import AsyncServer, AsyncServerConnection

View File

@@ -1,172 +0,0 @@
#
# SPDX-License-Identifier: GPL-2.0-only
#
import abc
import asyncio
import json
import os
import socket
import sys
from . import chunkify, DEFAULT_MAX_CHUNK
class AsyncClient(object):
def __init__(self, proto_name, proto_version, logger, timeout=30):
self.reader = None
self.writer = None
self.max_chunk = DEFAULT_MAX_CHUNK
self.proto_name = proto_name
self.proto_version = proto_version
self.logger = logger
self.timeout = timeout
async def connect_tcp(self, address, port):
async def connect_sock():
return await asyncio.open_connection(address, port)
self._connect_sock = connect_sock
async def connect_unix(self, path):
async def connect_sock():
return await asyncio.open_unix_connection(path)
self._connect_sock = connect_sock
async def setup_connection(self):
s = '%s %s\n\n' % (self.proto_name, self.proto_version)
self.writer.write(s.encode("utf-8"))
await self.writer.drain()
async def connect(self):
if self.reader is None or self.writer is None:
(self.reader, self.writer) = await self._connect_sock()
await self.setup_connection()
async def close(self):
self.reader = None
if self.writer is not None:
self.writer.close()
self.writer = None
async def _send_wrapper(self, proc):
count = 0
while True:
try:
await self.connect()
return await proc()
except (
OSError,
ConnectionError,
json.JSONDecodeError,
UnicodeDecodeError,
) as e:
self.logger.warning("Error talking to server: %s" % e)
if count >= 3:
if not isinstance(e, ConnectionError):
raise ConnectionError(str(e))
raise e
await self.close()
count += 1
async def send_message(self, msg):
async def get_line():
try:
line = await asyncio.wait_for(self.reader.readline(), self.timeout)
except asyncio.TimeoutError:
raise ConnectionError("Timed out waiting for server")
if not line:
raise ConnectionError("Connection closed")
line = line.decode("utf-8")
if not line.endswith("\n"):
raise ConnectionError("Bad message %r" % (line))
return line
async def proc():
for c in chunkify(json.dumps(msg), self.max_chunk):
self.writer.write(c.encode("utf-8"))
await self.writer.drain()
l = await get_line()
m = json.loads(l)
if m and "chunk-stream" in m:
lines = []
while True:
l = (await get_line()).rstrip("\n")
if not l:
break
lines.append(l)
m = json.loads("".join(lines))
return m
return await self._send_wrapper(proc)
async def ping(self):
return await self.send_message(
{'ping': {}}
)
class Client(object):
def __init__(self):
self.client = self._get_async_client()
self.loop = asyncio.new_event_loop()
# Override any pre-existing loop.
# Without this, the PR server export selftest triggers a hang
# when running with Python 3.7. The drawback is that there is
# potential for issues if the PR and hash equiv (or some new)
# clients need to both be instantiated in the same process.
# This should be revisited if/when Python 3.9 becomes the
# minimum required version for BitBake, as it seems not
# required (but harmless) with it.
asyncio.set_event_loop(self.loop)
self._add_methods('connect_tcp', 'ping')
@abc.abstractmethod
def _get_async_client(self):
pass
def _get_downcall_wrapper(self, downcall):
def wrapper(*args, **kwargs):
return self.loop.run_until_complete(downcall(*args, **kwargs))
return wrapper
def _add_methods(self, *methods):
for m in methods:
downcall = getattr(self.client, m)
setattr(self, m, self._get_downcall_wrapper(downcall))
def connect_unix(self, path):
# AF_UNIX has path length issues so chdir here to workaround
cwd = os.getcwd()
try:
os.chdir(os.path.dirname(path))
self.loop.run_until_complete(self.client.connect_unix(os.path.basename(path)))
self.loop.run_until_complete(self.client.connect())
finally:
os.chdir(cwd)
@property
def max_chunk(self):
return self.client.max_chunk
@max_chunk.setter
def max_chunk(self, value):
self.client.max_chunk = value
def close(self):
self.loop.run_until_complete(self.client.close())
if sys.version_info >= (3, 6):
self.loop.run_until_complete(self.loop.shutdown_asyncgens())
self.loop.close()

View File

@@ -1,286 +0,0 @@
#
# SPDX-License-Identifier: GPL-2.0-only
#
import abc
import asyncio
import json
import os
import signal
import socket
import sys
import multiprocessing
from . import chunkify, DEFAULT_MAX_CHUNK
class ClientError(Exception):
pass
class ServerError(Exception):
pass
class AsyncServerConnection(object):
def __init__(self, reader, writer, proto_name, logger):
self.reader = reader
self.writer = writer
self.proto_name = proto_name
self.max_chunk = DEFAULT_MAX_CHUNK
self.handlers = {
'chunk-stream': self.handle_chunk,
'ping': self.handle_ping,
}
self.logger = logger
async def process_requests(self):
try:
self.addr = self.writer.get_extra_info('peername')
self.logger.debug('Client %r connected' % (self.addr,))
# Read protocol and version
client_protocol = await self.reader.readline()
if client_protocol is None:
return
(client_proto_name, client_proto_version) = client_protocol.decode('utf-8').rstrip().split()
if client_proto_name != self.proto_name:
self.logger.debug('Rejecting invalid protocol %s' % (self.proto_name))
return
self.proto_version = tuple(int(v) for v in client_proto_version.split('.'))
if not self.validate_proto_version():
self.logger.debug('Rejecting invalid protocol version %s' % (client_proto_version))
return
# Read headers. Currently, no headers are implemented, so look for
# an empty line to signal the end of the headers
while True:
line = await self.reader.readline()
if line is None:
return
line = line.decode('utf-8').rstrip()
if not line:
break
# Handle messages
while True:
d = await self.read_message()
if d is None:
break
await self.dispatch_message(d)
await self.writer.drain()
except ClientError as e:
self.logger.error(str(e))
finally:
self.writer.close()
async def dispatch_message(self, msg):
for k in self.handlers.keys():
if k in msg:
self.logger.debug('Handling %s' % k)
await self.handlers[k](msg[k])
return
raise ClientError("Unrecognized command %r" % msg)
def write_message(self, msg):
for c in chunkify(json.dumps(msg), self.max_chunk):
self.writer.write(c.encode('utf-8'))
async def read_message(self):
l = await self.reader.readline()
if not l:
return None
try:
message = l.decode('utf-8')
if not message.endswith('\n'):
return None
return json.loads(message)
except (json.JSONDecodeError, UnicodeDecodeError) as e:
self.logger.error('Bad message from client: %r' % message)
raise e
async def handle_chunk(self, request):
lines = []
try:
while True:
l = await self.reader.readline()
l = l.rstrip(b"\n").decode("utf-8")
if not l:
break
lines.append(l)
msg = json.loads(''.join(lines))
except (json.JSONDecodeError, UnicodeDecodeError) as e:
self.logger.error('Bad message from client: %r' % lines)
raise e
if 'chunk-stream' in msg:
raise ClientError("Nested chunks are not allowed")
await self.dispatch_message(msg)
async def handle_ping(self, request):
response = {'alive': True}
self.write_message(response)
class AsyncServer(object):
def __init__(self, logger):
self._cleanup_socket = None
self.logger = logger
self.start = None
self.address = None
self.loop = None
def start_tcp_server(self, host, port):
def start_tcp():
self.server = self.loop.run_until_complete(
asyncio.start_server(self.handle_client, host, port)
)
for s in self.server.sockets:
self.logger.debug('Listening on %r' % (s.getsockname(),))
# Newer python does this automatically. Do it manually here for
# maximum compatibility
s.setsockopt(socket.SOL_TCP, socket.TCP_NODELAY, 1)
s.setsockopt(socket.SOL_TCP, socket.TCP_QUICKACK, 1)
name = self.server.sockets[0].getsockname()
if self.server.sockets[0].family == socket.AF_INET6:
self.address = "[%s]:%d" % (name[0], name[1])
else:
self.address = "%s:%d" % (name[0], name[1])
self.start = start_tcp
def start_unix_server(self, path):
def cleanup():
os.unlink(path)
def start_unix():
cwd = os.getcwd()
try:
# Work around path length limits in AF_UNIX
os.chdir(os.path.dirname(path))
self.server = self.loop.run_until_complete(
asyncio.start_unix_server(self.handle_client, os.path.basename(path))
)
finally:
os.chdir(cwd)
self.logger.debug('Listening on %r' % path)
self._cleanup_socket = cleanup
self.address = "unix://%s" % os.path.abspath(path)
self.start = start_unix
@abc.abstractmethod
def accept_client(self, reader, writer):
pass
async def handle_client(self, reader, writer):
# writer.transport.set_write_buffer_limits(0)
try:
client = self.accept_client(reader, writer)
await client.process_requests()
except Exception as e:
import traceback
self.logger.error('Error from client: %s' % str(e), exc_info=True)
traceback.print_exc()
writer.close()
self.logger.debug('Client disconnected')
def run_loop_forever(self):
try:
self.loop.run_forever()
except KeyboardInterrupt:
pass
def signal_handler(self):
self.logger.debug("Got exit signal")
self.loop.stop()
def _serve_forever(self):
try:
self.loop.add_signal_handler(signal.SIGTERM, self.signal_handler)
signal.pthread_sigmask(signal.SIG_UNBLOCK, [signal.SIGTERM])
self.run_loop_forever()
self.server.close()
self.loop.run_until_complete(self.server.wait_closed())
self.logger.debug('Server shutting down')
finally:
if self._cleanup_socket is not None:
self._cleanup_socket()
def serve_forever(self):
"""
Serve requests in the current process
"""
# Create loop and override any loop that may have existed in
# a parent process. It is possible that the usecases of
# serve_forever might be constrained enough to allow using
# get_event_loop here, but better safe than sorry for now.
self.loop = asyncio.new_event_loop()
asyncio.set_event_loop(self.loop)
self.start()
self._serve_forever()
def serve_as_process(self, *, prefunc=None, args=()):
"""
Serve requests in a child process
"""
def run(queue):
# Create loop and override any loop that may have existed
# in a parent process. Without doing this and instead
# using get_event_loop, at the very minimum the hashserv
# unit tests will hang when running the second test.
# This happens since get_event_loop in the spawned server
# process for the second testcase ends up with the loop
# from the hashserv client created in the unit test process
# when running the first testcase. The problem is somewhat
# more general, though, as any potential use of asyncio in
# Cooker could create a loop that needs to replaced in this
# new process.
self.loop = asyncio.new_event_loop()
asyncio.set_event_loop(self.loop)
try:
self.start()
finally:
queue.put(self.address)
queue.close()
if prefunc is not None:
prefunc(self, *args)
self._serve_forever()
if sys.version_info >= (3, 6):
self.loop.run_until_complete(self.loop.shutdown_asyncgens())
self.loop.close()
queue = multiprocessing.Queue()
# Temporarily block SIGTERM. The server process will inherit this
# block which will ensure it doesn't receive the SIGTERM until the
# handler is ready for it
mask = signal.pthread_sigmask(signal.SIG_BLOCK, [signal.SIGTERM])
try:
self.process = multiprocessing.Process(target=run, args=(queue,))
self.process.start()
self.address = queue.get()
queue.close()
queue.join_thread()
return self.process
finally:
signal.pthread_sigmask(signal.SIG_SETMASK, mask)

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -1,3 +1,5 @@
# ex:ts=4:sw=4:sts=4:et
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
#
# Extra RecipeInfo will be all defined in this file. Currently,
# Only Hob (Image Creator) Requests some extra fields. So
@@ -10,8 +12,18 @@
# Copyright (C) 2011, Intel Corporation. All rights reserved.
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
from bb.cache import RecipeInfoCommon

View File

@@ -2,11 +2,19 @@
#
# Copyright (C) 2012 Intel Corporation
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
import glob
import operator
import os
import stat
import bb.utils
@@ -15,6 +23,14 @@ from bb.cache import MultiProcessCache
logger = logging.getLogger("BitBake.Cache")
try:
import cPickle as pickle
except ImportError:
import pickle
logger.info("Importing cPickle failed. "
"Falling back to a very slow implementation.")
# mtime cache (non-persistent)
# based upon the assumption that files do not change during bitbake run
class FileMtimeCache(object):
@@ -72,55 +88,3 @@ class FileChecksumCache(MultiProcessCache):
dest[0][h] = source[0][h]
else:
dest[0][h] = source[0][h]
def get_checksums(self, filelist, pn, localdirsexclude):
"""Get checksums for a list of files"""
def checksum_file(f):
try:
checksum = self.get_checksum(f)
except OSError as e:
bb.warn("Unable to get checksum for %s SRC_URI entry %s: %s" % (pn, os.path.basename(f), e))
return None
return checksum
def checksum_dir(pth):
# Handle directories recursively
if pth == "/":
bb.fatal("Refusing to checksum /")
dirchecksums = []
for root, dirs, files in os.walk(pth, topdown=True):
[dirs.remove(d) for d in list(dirs) if d in localdirsexclude]
for name in files:
fullpth = os.path.join(root, name)
checksum = checksum_file(fullpth)
if checksum:
dirchecksums.append((fullpth, checksum))
return dirchecksums
checksums = []
for pth in filelist.split():
exist = pth.split(":")[1]
if exist == "False":
continue
pth = pth.split(":")[0]
if '*' in pth:
# Handle globs
for f in glob.glob(pth):
if os.path.isdir(f):
if not os.path.islink(f):
checksums.extend(checksum_dir(f))
else:
checksum = checksum_file(f)
if checksum:
checksums.append((f, checksum))
elif os.path.isdir(pth):
if not os.path.islink(pth):
checksums.extend(checksum_dir(pth))
else:
checksum = checksum_file(pth)
if checksum:
checksums.append((pth, checksum))
checksums.sort(key=operator.itemgetter(1))
return checksums

View File

@@ -1,41 +1,21 @@
#
# SPDX-License-Identifier: GPL-2.0-only
#
"""
BitBake code parser
Parses actual code (i.e. python and shell) for functions and in-line
expressions. Used mainly to determine dependencies on other functions
and variables within the BitBake metadata. Also provides a cache for
this information in order to speed up processing.
(Not to be confused with the code that parses the metadata itself,
see lib/bb/parse/ for that).
NOTE: if you change how the parsers gather information you will almost
certainly need to increment CodeParserCache.CACHE_VERSION below so that
any existing codeparser cache gets invalidated. Additionally you'll need
to increment __cache_version__ in cache.py in order to ensure that old
recipe caches don't trigger "Taskhash mismatch" errors.
"""
import ast
import sys
import codegen
import logging
import bb.pysh as pysh
import os.path
import bb.utils, bb.data
import hashlib
from itertools import chain
from bb.pysh import pyshyacc, pyshlex
from pysh import pyshyacc, pyshlex, sherrors
from bb.cache import MultiProcessCache
logger = logging.getLogger('BitBake.CodeParser')
def bbhash(s):
return hashlib.sha256(s.encode("utf-8")).hexdigest()
try:
import cPickle as pickle
except ImportError:
import pickle
logger.info('Importing cPickle failed. Falling back to a very slow implementation.')
def check_indent(codestr):
"""If the code is indented, add a top level piece of code to 'remove' the indentation"""
@@ -48,81 +28,14 @@ def check_indent(codestr):
return codestr
if codestr[i-1] == "\t" or codestr[i-1] == " ":
if codestr[0] == "\n":
# Since we're adding a line, we need to remove one line of any empty padding
# to ensure line numbers are correct
codestr = codestr[1:]
return "if 1:\n" + codestr
return codestr
# A custom getstate/setstate using tuples is actually worth 15% cachesize by
# avoiding duplication of the attribute names!
class SetCache(object):
def __init__(self):
self.setcache = {}
def internSet(self, items):
new = []
for i in items:
new.append(sys.intern(i))
s = frozenset(new)
h = hash(s)
if h in self.setcache:
return self.setcache[h]
self.setcache[h] = s
return s
codecache = SetCache()
class pythonCacheLine(object):
def __init__(self, refs, execs, contains):
self.refs = codecache.internSet(refs)
self.execs = codecache.internSet(execs)
self.contains = {}
for c in contains:
self.contains[c] = codecache.internSet(contains[c])
def __getstate__(self):
return (self.refs, self.execs, self.contains)
def __setstate__(self, state):
(refs, execs, contains) = state
self.__init__(refs, execs, contains)
def __hash__(self):
l = (hash(self.refs), hash(self.execs))
for c in sorted(self.contains.keys()):
l = l + (c, hash(self.contains[c]))
return hash(l)
def __repr__(self):
return " ".join([str(self.refs), str(self.execs), str(self.contains)])
class shellCacheLine(object):
def __init__(self, execs):
self.execs = codecache.internSet(execs)
def __getstate__(self):
return (self.execs)
def __setstate__(self, state):
(execs) = state
self.__init__(execs)
def __hash__(self):
return hash(self.execs)
def __repr__(self):
return str(self.execs)
class CodeParserCache(MultiProcessCache):
cache_file_name = "bb_codeparser.dat"
# NOTE: you must increment this if you change how the parsers gather information,
# so that an existing cache gets invalidated. Additionally you'll need
# to increment __cache_version__ in cache.py in order to ensure that old
# recipe caches don't trigger "Taskhash mismatch" errors.
CACHE_VERSION = 11
CACHE_VERSION = 6
def __init__(self):
MultiProcessCache.__init__(self)
@@ -131,38 +44,32 @@ class CodeParserCache(MultiProcessCache):
self.pythoncacheextras = self.cachedata_extras[0]
self.shellcacheextras = self.cachedata_extras[1]
# To avoid duplication in the codeparser cache, keep
# a lookup of hashes of objects we already have
self.pythoncachelines = {}
self.shellcachelines = {}
def newPythonCacheLine(self, refs, execs, contains):
cacheline = pythonCacheLine(refs, execs, contains)
h = hash(cacheline)
if h in self.pythoncachelines:
return self.pythoncachelines[h]
self.pythoncachelines[h] = cacheline
return cacheline
def newShellCacheLine(self, execs):
cacheline = shellCacheLine(execs)
h = hash(cacheline)
if h in self.shellcachelines:
return self.shellcachelines[h]
self.shellcachelines[h] = cacheline
return cacheline
def init_cache(self, d):
# Check if we already have the caches
if self.pythoncache:
return
MultiProcessCache.init_cache(self, d)
# cachedata gets re-assigned in the parent
self.pythoncache = self.cachedata[0]
self.shellcache = self.cachedata[1]
def compress_keys(self, data):
# When the dicts are originally created, python calls intern() on the set keys
# which significantly improves memory usage. Sadly the pickle/unpickle process
# doesn't call intern() on the keys and results in the same strings being duplicated
# in memory. This also means pickle will save the same string multiple times in
# the cache file. By interning the data here, the cache file shrinks dramatically
# meaning faster load times and the reloaded cache files also consume much less
# memory. This is worth any performance hit from this loops and the use of the
# intern() data storage.
# Python 3.x may behave better in this area
for h in data[0]:
data[0][h]["refs"] = self.internSet(data[0][h]["refs"])
data[0][h]["execs"] = self.internSet(data[0][h]["execs"])
for k in data[0][h]["contains"]:
data[0][h]["contains"][k] = self.internSet(data[0][h]["contains"][k])
for h in data[1]:
data[1][h]["execs"] = self.internSet(data[1][h]["execs"])
return
def create_cachedata(self):
data = [{}, {}]
return data
@@ -172,11 +79,11 @@ codeparsercache = CodeParserCache()
def parser_cache_init(d):
codeparsercache.init_cache(d)
def parser_cache_save():
codeparsercache.save_extras()
def parser_cache_save(d):
codeparsercache.save_extras(d)
def parser_cache_savemerge():
codeparsercache.save_merge()
def parser_cache_savemerge(d):
codeparsercache.save_merge(d)
Logger = logging.getLoggerClass()
class BufferedLogger(Logger):
@@ -191,15 +98,12 @@ class BufferedLogger(Logger):
def flush(self):
for record in self.buffer:
if self.target.isEnabledFor(record.levelno):
self.target.handle(record)
self.target.handle(record)
self.buffer = []
class PythonParser():
getvars = (".getVar", ".appendVar", ".prependVar", "oe.utils.conditional")
getvarflags = (".getVarFlag", ".appendVarFlag", ".prependVarFlag")
containsfuncs = ("bb.utils.contains", "base_contains")
containsanyfuncs = ("bb.utils.contains_any", "bb.utils.filter")
getvars = (".getVar", ".appendVar", ".prependVar")
containsfuncs = ("bb.utils.contains", "base_contains", "oe.utils.contains")
execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
def warn(self, func, arg):
@@ -212,43 +116,23 @@ class PythonParser():
funcstr = codegen.to_source(func)
argstr = codegen.to_source(arg)
except TypeError:
self.log.debug2('Failed to convert function and argument to source form')
self.log.debug(2, 'Failed to convert function and argument to source form')
else:
self.log.debug(self.unhandled_message % (funcstr, argstr))
self.log.debug(1, self.unhandled_message % (funcstr, argstr))
def visit_Call(self, node):
name = self.called_node_name(node.func)
if name and (name.endswith(self.getvars) or name.endswith(self.getvarflags) or name in self.containsfuncs or name in self.containsanyfuncs):
if name and name.endswith(self.getvars) or name in self.containsfuncs:
if isinstance(node.args[0], ast.Str):
varname = node.args[0].s
if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
if varname not in self.contains:
self.contains[varname] = set()
self.contains[varname].add(node.args[1].s)
elif name in self.containsanyfuncs and isinstance(node.args[1], ast.Str):
if varname not in self.contains:
self.contains[varname] = set()
self.contains[varname].update(node.args[1].s.split())
elif name.endswith(self.getvarflags):
if isinstance(node.args[1], ast.Str):
self.references.add('%s[%s]' % (varname, node.args[1].s))
else:
self.warn(node.func, node.args[1])
else:
self.references.add(varname)
else:
self.references.add(node.args[0].s)
else:
self.warn(node.func, node.args[0])
elif name and name.endswith(".expand"):
if isinstance(node.args[0], ast.Str):
value = node.args[0].s
d = bb.data.init()
parser = d.expandWithRefs(value, self.name)
self.references |= parser.references
self.execs |= parser.execs
for varname in parser.contains:
if varname not in self.contains:
self.contains[varname] = set()
self.contains[varname] |= parser.contains[varname]
elif name in self.execfuncs:
if isinstance(node.args[0], ast.Str):
self.var_execs.add(node.args[0].s)
@@ -271,7 +155,6 @@ class PythonParser():
break
def __init__(self, name, log):
self.name = name
self.var_execs = set()
self.contains = {}
self.execs = set()
@@ -281,31 +164,22 @@ class PythonParser():
self.unhandled_message = "in call of %s, argument '%s' is not a string literal"
self.unhandled_message = "while parsing %s, %s" % (name, self.unhandled_message)
def parse_python(self, node, lineno=0, filename="<string>"):
if not node or not node.strip():
return
h = bbhash(str(node))
def parse_python(self, node):
h = hash(str(node))
if h in codeparsercache.pythoncache:
self.references = set(codeparsercache.pythoncache[h].refs)
self.execs = set(codeparsercache.pythoncache[h].execs)
self.contains = {}
for i in codeparsercache.pythoncache[h].contains:
self.contains[i] = set(codeparsercache.pythoncache[h].contains[i])
self.references = codeparsercache.pythoncache[h]["refs"]
self.execs = codeparsercache.pythoncache[h]["execs"]
self.contains = codeparsercache.pythoncache[h]["contains"]
return
if h in codeparsercache.pythoncacheextras:
self.references = set(codeparsercache.pythoncacheextras[h].refs)
self.execs = set(codeparsercache.pythoncacheextras[h].execs)
self.contains = {}
for i in codeparsercache.pythoncacheextras[h].contains:
self.contains[i] = set(codeparsercache.pythoncacheextras[h].contains[i])
self.references = codeparsercache.pythoncacheextras[h]["refs"]
self.execs = codeparsercache.pythoncacheextras[h]["execs"]
self.contains = codeparsercache.pythoncacheextras[h]["contains"]
return
# We can't add to the linenumbers for compile, we can pad to the correct number of blank lines though
node = "\n" * int(lineno) + node
code = compile(check_indent(str(node)), filename, "exec",
code = compile(check_indent(str(node)), "<string>", "exec",
ast.PyCF_ONLY_AST)
for n in ast.walk(code):
@@ -314,7 +188,10 @@ class PythonParser():
self.execs.update(self.var_execs)
codeparsercache.pythoncacheextras[h] = codeparsercache.newPythonCacheLine(self.references, self.execs, self.contains)
codeparsercache.pythoncacheextras[h] = {}
codeparsercache.pythoncacheextras[h]["refs"] = self.references
codeparsercache.pythoncacheextras[h]["execs"] = self.execs
codeparsercache.pythoncacheextras[h]["contains"] = self.contains
class ShellParser():
def __init__(self, name, log):
@@ -330,31 +207,32 @@ class ShellParser():
commands it executes.
"""
h = bbhash(str(value))
h = hash(str(value))
if h in codeparsercache.shellcache:
self.execs = set(codeparsercache.shellcache[h].execs)
self.execs = codeparsercache.shellcache[h]["execs"]
return self.execs
if h in codeparsercache.shellcacheextras:
self.execs = set(codeparsercache.shellcacheextras[h].execs)
self.execs = codeparsercache.shellcacheextras[h]["execs"]
return self.execs
self._parse_shell(value)
self.execs = set(cmd for cmd in self.allexecs if cmd not in self.funcdefs)
codeparsercache.shellcacheextras[h] = codeparsercache.newShellCacheLine(self.execs)
codeparsercache.shellcacheextras[h] = {}
codeparsercache.shellcacheextras[h]["execs"] = self.execs
return self.execs
def _parse_shell(self, value):
try:
tokens, _ = pyshyacc.parse(value, eof=True, debug=False)
except Exception:
bb.error('Error during parse shell code, the last 5 lines are:\n%s' % '\n'.join(value.split('\n')[-5:]))
raise
except pyshlex.NeedMore:
raise sherrors.ShellSyntaxError("Unexpected EOF")
self.process_tokens(tokens)
for token in tokens:
self.process_tokens(token)
def process_tokens(self, tokens):
"""Process a supplied portion of the syntax tree as returned by
@@ -400,24 +278,18 @@ class ShellParser():
"case_clause": case_clause,
}
def process_token_list(tokens):
for token in tokens:
if isinstance(token, list):
process_token_list(token)
continue
name, value = token
try:
more_tokens, words = token_handlers[name](value)
except KeyError:
raise NotImplementedError("Unsupported token type " + name)
for token in tokens:
name, value = token
try:
more_tokens, words = token_handlers[name](value)
except KeyError:
raise NotImplementedError("Unsupported token type " + name)
if more_tokens:
self.process_tokens(more_tokens)
if more_tokens:
self.process_tokens(more_tokens)
if words:
self.process_words(words)
process_token_list(tokens)
if words:
self.process_words(words)
def process_words(self, words):
"""Process a set of 'words' in pyshyacc parlance, which includes
@@ -450,7 +322,7 @@ class ShellParser():
cmd = word[1]
if cmd.startswith("$"):
self.log.debug(self.unhandled_template % cmd)
self.log.debug(1, self.unhandled_template % cmd)
elif cmd == "eval":
command = " ".join(word for _, word in words[1:])
self._parse_shell(command)

View File

@@ -6,8 +6,18 @@ Provide an interface to interact with the bitbake server through 'commands'
# Copyright (C) 2006-2007 Richard Purdie
#
# SPDX-License-Identifier: GPL-2.0-only
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License along
# with this program; if not, write to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
"""
The bitbake server takes 'commands' from its UI/commandline.
@@ -18,16 +28,8 @@ and must not trigger events, directly or indirectly.
Commands are queued in a CommandQueue
"""
from collections import OrderedDict, defaultdict
import io
import bb.event
import bb.cooker
import bb.remotedata
class DataStoreConnectionHandle(object):
def __init__(self, dsindex=0):
self.dsindex = dsindex
class CommandCompleted(bb.event.Event):
pass
@@ -41,8 +43,6 @@ class CommandFailed(CommandExit):
def __init__(self, message):
self.error = message
CommandExit.__init__(self, 1)
def __str__(self):
return "Command execution failed: %s" % self.error
class CommandError(Exception):
pass
@@ -55,47 +55,24 @@ class Command:
self.cooker = cooker
self.cmds_sync = CommandsSync()
self.cmds_async = CommandsAsync()
self.remotedatastores = None
# FIXME Add lock for this
self.currentAsyncCommand = None
def runCommand(self, commandline, ro_only = False):
command = commandline.pop(0)
# Ensure cooker is ready for commands
if command != "updateConfig" and command != "setFeatures":
try:
self.cooker.init_configdata()
if not self.remotedatastores:
self.remotedatastores = bb.remotedata.RemoteDatastores(self.cooker)
except (Exception, SystemExit) as exc:
import traceback
if isinstance(exc, bb.BBHandledException):
# We need to start returning real exceptions here. Until we do, we can't
# tell if an exception is an instance of bb.BBHandledException
return None, "bb.BBHandledException()\n" + traceback.format_exc()
return None, traceback.format_exc()
if hasattr(CommandsSync, command):
# Can run synchronous commands straight away
command_method = getattr(self.cmds_sync, command)
if ro_only:
if not hasattr(command_method, 'readonly') or not getattr(command_method, 'readonly'):
if not hasattr(command_method, 'readonly') or False == getattr(command_method, 'readonly'):
return None, "Not able to execute not readonly commands in readonly mode"
try:
self.cooker.process_inotify_updates()
if getattr(command_method, 'needconfig', True):
self.cooker.updateCacheSync()
result = command_method(self, commandline)
except CommandError as exc:
return None, exc.args[0]
except (Exception, SystemExit) as exc:
except Exception:
import traceback
if isinstance(exc, bb.BBHandledException):
# We need to start returning real exceptions here. Until we do, we can't
# tell if an exception is an instance of bb.BBHandledException
return None, "bb.BBHandledException()\n" + traceback.format_exc()
return None, traceback.format_exc()
else:
return result, None
@@ -104,16 +81,12 @@ class Command:
if command not in CommandsAsync.__dict__:
return None, "No such command"
self.currentAsyncCommand = (command, commandline)
self.cooker.idleCallBackRegister(self.cooker.runCommands, self.cooker)
self.cooker.configuration.server_register_idlecallback(self.cooker.runCommands, self.cooker)
return True, None
def runAsyncCommand(self):
try:
self.cooker.process_inotify_updates()
if self.cooker.state in (bb.cooker.state.error, bb.cooker.state.shutdown, bb.cooker.state.forceshutdown):
# updateCache will trigger a shutdown of the parser
# and then raise BBHandledException triggering an exit
self.cooker.updateCache()
if self.cooker.state == bb.cooker.state.error:
return False
if self.currentAsyncCommand is not None:
(command, options) = self.currentAsyncCommand
@@ -132,7 +105,7 @@ class Command:
return False
except SystemExit as exc:
arg = exc.args[0]
if isinstance(arg, str):
if isinstance(arg, basestring):
self.finishAsyncCommand(arg)
else:
self.finishAsyncCommand("Exited with %s" % arg)
@@ -147,18 +120,14 @@ class Command:
def finishAsyncCommand(self, msg=None, code=None):
if msg or msg == "":
bb.event.fire(CommandFailed(msg), self.cooker.data)
bb.event.fire(CommandFailed(msg), self.cooker.event_data)
elif code:
bb.event.fire(CommandExit(code), self.cooker.data)
bb.event.fire(CommandExit(code), self.cooker.event_data)
else:
bb.event.fire(CommandCompleted(), self.cooker.data)
bb.event.fire(CommandCompleted(), self.cooker.event_data)
self.currentAsyncCommand = None
self.cooker.finishcommand()
def reset(self):
if self.remotedatastores:
self.remotedatastores = bb.remotedata.RemoteDatastores(self.cooker)
class CommandsSync:
"""
A class of synchronous commands
@@ -205,19 +174,8 @@ class CommandsSync:
"""
varname = params[0]
value = str(params[1])
command.cooker.extraconfigdata[varname] = value
command.cooker.data.setVar(varname, value)
def getSetVariable(self, command, params):
"""
Read the value of a variable from data and set it into the datastore
which effectively expands and locks the value.
"""
varname = params[0]
result = self.getVariable(command, params)
command.cooker.data.setVar(varname, result)
return result
def setConfig(self, command, params):
"""
Set the value of variable in configuration
@@ -243,21 +201,54 @@ class CommandsSync:
postfiles = params[1].split()
command.cooker.configuration.prefile = prefiles
command.cooker.configuration.postfile = postfiles
setPrePostConfFiles.needconfig = False
def getCpuCount(self, command, params):
"""
Get the CPU count on the bitbake server
"""
return bb.utils.cpu_count()
getCpuCount.readonly = True
def matchFile(self, command, params):
fMatch = params[0]
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.matchFile(fMatch, mc)
matchFile.needconfig = False
return command.cooker.matchFile(fMatch)
def getUIHandlerNum(self, command, params):
return bb.event.get_uihandler()
getUIHandlerNum.needconfig = False
getUIHandlerNum.readonly = True
def generateNewImage(self, command, params):
image = params[0]
base_image = params[1]
package_queue = params[2]
timestamp = params[3]
description = params[4]
return command.cooker.generateNewImage(image, base_image,
package_queue, timestamp, description)
def ensureDir(self, command, params):
directory = params[0]
bb.utils.mkdirhier(directory)
def setVarFile(self, command, params):
"""
Save a variable in a file; used for saving in a configuration file
"""
var = params[0]
val = params[1]
default_file = params[2]
op = params[3]
command.cooker.modifyConfigurationVar(var, val, default_file, op)
def removeVarFile(self, command, params):
"""
Remove a variable declaration from a file
"""
var = params[0]
command.cooker.removeConfigurationVar(var)
def createConfigFile(self, command, params):
"""
Create an extra configuration file
"""
name = params[0]
command.cooker.createConfigFile(name)
def setEventMask(self, command, params):
handlerNum = params[0]
@@ -265,8 +256,6 @@ class CommandsSync:
debug_domains = params[2]
mask = params[3]
return bb.event.set_UIHmask(handlerNum, llevel, debug_domains, mask)
setEventMask.needconfig = False
setEventMask.readonly = True
def setFeatures(self, command, params):
"""
@@ -274,305 +263,11 @@ class CommandsSync:
"""
features = params[0]
command.cooker.setFeatures(features)
setFeatures.needconfig = False
# although we change the internal state of the cooker, this is transparent since
# we always take and leave the cooker in state.initial
setFeatures.readonly = True
def updateConfig(self, command, params):
options = params[0]
environment = params[1]
cmdline = params[2]
command.cooker.updateConfigOpts(options, environment, cmdline)
updateConfig.needconfig = False
def parseConfiguration(self, command, params):
"""Instruct bitbake to parse its configuration
NOTE: it is only necessary to call this if you aren't calling any normal action
(otherwise parsing is taken care of automatically)
"""
command.cooker.parseConfiguration()
parseConfiguration.needconfig = False
def getLayerPriorities(self, command, params):
command.cooker.parseConfiguration()
ret = []
# regex objects cannot be marshalled by xmlrpc
for collection, pattern, regex, pri in command.cooker.bbfile_config_priorities:
ret.append((collection, pattern, regex.pattern, pri))
return ret
getLayerPriorities.readonly = True
def getRecipes(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return list(command.cooker.recipecaches[mc].pkg_pn.items())
getRecipes.readonly = True
def getRecipeDepends(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return list(command.cooker.recipecaches[mc].deps.items())
getRecipeDepends.readonly = True
def getRecipeVersions(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].pkg_pepvpr
getRecipeVersions.readonly = True
def getRecipeProvides(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].fn_provides
getRecipeProvides.readonly = True
def getRecipePackages(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].packages
getRecipePackages.readonly = True
def getRecipePackagesDynamic(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].packages_dynamic
getRecipePackagesDynamic.readonly = True
def getRProviders(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].rproviders
getRProviders.readonly = True
def getRuntimeDepends(self, command, params):
ret = []
try:
mc = params[0]
except IndexError:
mc = ''
rundeps = command.cooker.recipecaches[mc].rundeps
for key, value in rundeps.items():
if isinstance(value, defaultdict):
value = dict(value)
ret.append((key, value))
return ret
getRuntimeDepends.readonly = True
def getRuntimeRecommends(self, command, params):
ret = []
try:
mc = params[0]
except IndexError:
mc = ''
runrecs = command.cooker.recipecaches[mc].runrecs
for key, value in runrecs.items():
if isinstance(value, defaultdict):
value = dict(value)
ret.append((key, value))
return ret
getRuntimeRecommends.readonly = True
def getRecipeInherits(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].inherits
getRecipeInherits.readonly = True
def getBbFilePriority(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].bbfile_priority
getBbFilePriority.readonly = True
def getDefaultPreference(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.recipecaches[mc].pkg_dp
getDefaultPreference.readonly = True
def getSkippedRecipes(self, command, params):
# Return list sorted by reverse priority order
import bb.cache
def sortkey(x):
vfn, _ = x
realfn, _, mc = bb.cache.virtualfn2realfn(vfn)
return (-command.cooker.collections[mc].calc_bbfile_priority(realfn)[0], vfn)
skipdict = OrderedDict(sorted(command.cooker.skiplist.items(), key=sortkey))
return list(skipdict.items())
getSkippedRecipes.readonly = True
def getOverlayedRecipes(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return list(command.cooker.collections[mc].overlayed.items())
getOverlayedRecipes.readonly = True
def getFileAppends(self, command, params):
fn = params[0]
try:
mc = params[1]
except IndexError:
mc = ''
return command.cooker.collections[mc].get_file_appends(fn)
getFileAppends.readonly = True
def getAllAppends(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.collections[mc].bbappends
getAllAppends.readonly = True
def findProviders(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return command.cooker.findProviders(mc)
findProviders.readonly = True
def findBestProvider(self, command, params):
(mc, pn) = bb.runqueue.split_mc(params[0])
return command.cooker.findBestProvider(pn, mc)
findBestProvider.readonly = True
def allProviders(self, command, params):
try:
mc = params[0]
except IndexError:
mc = ''
return list(bb.providers.allProviders(command.cooker.recipecaches[mc]).items())
allProviders.readonly = True
def getRuntimeProviders(self, command, params):
rprovide = params[0]
try:
mc = params[1]
except IndexError:
mc = ''
all_p = bb.providers.getRuntimeProviders(command.cooker.recipecaches[mc], rprovide)
if all_p:
best = bb.providers.filterProvidersRunTime(all_p, rprovide,
command.cooker.data,
command.cooker.recipecaches[mc])[0][0]
else:
best = None
return all_p, best
getRuntimeProviders.readonly = True
def dataStoreConnectorCmd(self, command, params):
dsindex = params[0]
method = params[1]
args = params[2]
kwargs = params[3]
d = command.remotedatastores[dsindex]
ret = getattr(d, method)(*args, **kwargs)
if isinstance(ret, bb.data_smart.DataSmart):
idx = command.remotedatastores.store(ret)
return DataStoreConnectionHandle(idx)
return ret
def dataStoreConnectorVarHistCmd(self, command, params):
dsindex = params[0]
method = params[1]
args = params[2]
kwargs = params[3]
d = command.remotedatastores[dsindex].varhistory
return getattr(d, method)(*args, **kwargs)
def dataStoreConnectorVarHistCmdEmit(self, command, params):
dsindex = params[0]
var = params[1]
oval = params[2]
val = params[3]
d = command.remotedatastores[params[4]]
o = io.StringIO()
command.remotedatastores[dsindex].varhistory.emit(var, oval, val, o, d)
return o.getvalue()
def dataStoreConnectorIncHistCmd(self, command, params):
dsindex = params[0]
method = params[1]
args = params[2]
kwargs = params[3]
d = command.remotedatastores[dsindex].inchistory
return getattr(d, method)(*args, **kwargs)
def dataStoreConnectorRelease(self, command, params):
dsindex = params[0]
if dsindex <= 0:
raise CommandError('dataStoreConnectorRelease: invalid index %d' % dsindex)
command.remotedatastores.release(dsindex)
def parseRecipeFile(self, command, params):
"""
Parse the specified recipe file (with or without bbappends)
and return a datastore object representing the environment
for the recipe.
"""
fn = params[0]
mc = bb.runqueue.mc_from_tid(fn)
appends = params[1]
appendlist = params[2]
if len(params) > 3:
config_data = command.remotedatastores[params[3]]
else:
config_data = None
if appends:
if appendlist is not None:
appendfiles = appendlist
else:
appendfiles = command.cooker.collections[mc].get_file_appends(fn)
else:
appendfiles = []
# We are calling bb.cache locally here rather than on the server,
# but that's OK because it doesn't actually need anything from
# the server barring the global datastore (which we have a remote
# version of)
if config_data:
# We have to use a different function here if we're passing in a datastore
# NOTE: we took a copy above, so we don't do it here again
envdata = bb.cache.parse_recipe(config_data, fn, appendfiles, mc)['']
else:
# Use the standard path
parser = bb.cache.NoCache(command.cooker.databuilder)
envdata = parser.loadDataFull(fn, appendfiles)
idx = command.remotedatastores.store(envdata)
return DataStoreConnectionHandle(idx)
parseRecipeFile.readonly = True
class CommandsAsync:
"""
A class of asynchronous commands
@@ -586,15 +281,8 @@ class CommandsAsync:
"""
bfile = params[0]
task = params[1]
if len(params) > 2:
internal = params[2]
else:
internal = False
if internal:
command.cooker.buildFileInternal(bfile, task, fireevents=False, quietlog=True)
else:
command.cooker.buildFile(bfile, task)
command.cooker.buildFile(bfile, task)
buildFile.needcache = False
def buildTargets(self, command, params):
@@ -644,6 +332,17 @@ class CommandsAsync:
command.finishAsyncCommand()
generateTargetsTree.needcache = True
def findCoreBaseFiles(self, command, params):
"""
Find certain files in COREBASE directory. i.e. Layers
"""
subdir = params[0]
filename = params[1]
command.cooker.findCoreBaseFiles(subdir, filename)
command.finishAsyncCommand()
findCoreBaseFiles.needcache = False
def findConfigFiles(self, command, params):
"""
Find config files which provide appropriate values
@@ -667,16 +366,6 @@ class CommandsAsync:
command.finishAsyncCommand()
findFilesMatchingInDir.needcache = False
def testCookerCommandEvent(self, command, params):
"""
Dummy command used by OEQA selftest to test tinfoil without IO
"""
pattern = params[0]
command.cooker.testCookerCommandEvent(pattern)
command.finishAsyncCommand()
testCookerCommandEvent.needcache = False
def findConfigFilePath(self, command, params):
"""
Find the path of the requested configuration file
@@ -753,22 +442,3 @@ class CommandsAsync:
command.finishAsyncCommand()
resetCooker.needcache = False
def clientComplete(self, command, params):
"""
Do the right thing when the controlling client exits
"""
command.cooker.clientComplete()
command.finishAsyncCommand()
clientComplete.needcache = False
def findSigInfo(self, command, params):
"""
Find signature info files via the signature generator
"""
(mc, pn) = bb.runqueue.split_mc(params[0])
taskname = params[1]
sigs = params[2]
res = bb.siggen.find_siginfo(pn, taskname, sigs, command.cooker.databuilder.mcdata[mc])
bb.event.fire(bb.event.FindSigInfoResult(res), command.cooker.databuilder.mcdata[mc])
command.finishAsyncCommand()
findSigInfo.needcache = False

6
bitbake/lib/bb/compat.py Normal file
View File

@@ -0,0 +1,6 @@
"""Code pulled from future python versions, here for compatibility"""
from collections import MutableMapping, KeysView, ValuesView, ItemsView, OrderedDict
from functools import total_ordering

View File

@@ -1,194 +0,0 @@
#
# SPDX-License-Identifier: GPL-2.0-only
#
# Helper library to implement streaming compression and decompression using an
# external process
#
# This library should be used directly by end users; a wrapper library for the
# specific compression tool should be created
import builtins
import io
import os
import subprocess
def open_wrap(
cls, filename, mode="rb", *, encoding=None, errors=None, newline=None, **kwargs
):
"""
Open a compressed file in binary or text mode.
Users should not call this directly. A specific compression library can use
this helper to provide it's own "open" command
The filename argument can be an actual filename (a str or bytes object), or
an existing file object to read from or write to.
The mode argument can be "r", "rb", "w", "wb", "x", "xb", "a" or "ab" for
binary mode, or "rt", "wt", "xt" or "at" for text mode. The default mode is
"rb".
For binary mode, this function is equivalent to the cls constructor:
cls(filename, mode). In this case, the encoding, errors and newline
arguments must not be provided.
For text mode, a cls object is created, and wrapped in an
io.TextIOWrapper instance with the specified encoding, error handling
behavior, and line ending(s).
"""
if "t" in mode:
if "b" in mode:
raise ValueError("Invalid mode: %r" % (mode,))
else:
if encoding is not None:
raise ValueError("Argument 'encoding' not supported in binary mode")
if errors is not None:
raise ValueError("Argument 'errors' not supported in binary mode")
if newline is not None:
raise ValueError("Argument 'newline' not supported in binary mode")
file_mode = mode.replace("t", "")
if isinstance(filename, (str, bytes, os.PathLike)):
binary_file = cls(filename, file_mode, **kwargs)
elif hasattr(filename, "read") or hasattr(filename, "write"):
binary_file = cls(None, file_mode, fileobj=filename, **kwargs)
else:
raise TypeError("filename must be a str or bytes object, or a file")
if "t" in mode:
return io.TextIOWrapper(
binary_file, encoding, errors, newline, write_through=True
)
else:
return binary_file
class CompressionError(OSError):
pass
class PipeFile(io.RawIOBase):
"""
Class that implements generically piping to/from a compression program
Derived classes should add the function get_compress() and get_decompress()
that return the required commands. Input will be piped into stdin and the
(de)compressed output should be written to stdout, e.g.:
class FooFile(PipeCompressionFile):
def get_decompress(self):
return ["fooc", "--decompress", "--stdout"]
def get_compress(self):
return ["fooc", "--compress", "--stdout"]
"""
READ = 0
WRITE = 1
def __init__(self, filename=None, mode="rb", *, stderr=None, fileobj=None):
if "t" in mode or "U" in mode:
raise ValueError("Invalid mode: {!r}".format(mode))
if not "b" in mode:
mode += "b"
if mode.startswith("r"):
self.mode = self.READ
elif mode.startswith("w"):
self.mode = self.WRITE
else:
raise ValueError("Invalid mode %r" % mode)
if fileobj is not None:
self.fileobj = fileobj
else:
self.fileobj = builtins.open(filename, mode or "rb")
if self.mode == self.READ:
self.p = subprocess.Popen(
self.get_decompress(),
stdin=self.fileobj,
stdout=subprocess.PIPE,
stderr=stderr,
close_fds=True,
)
self.pipe = self.p.stdout
else:
self.p = subprocess.Popen(
self.get_compress(),
stdin=subprocess.PIPE,
stdout=self.fileobj,
stderr=stderr,
close_fds=True,
)
self.pipe = self.p.stdin
self.__closed = False
def _check_process(self):
if self.p is None:
return
returncode = self.p.wait()
if returncode:
raise CompressionError("Process died with %d" % returncode)
self.p = None
def close(self):
if self.closed:
return
self.pipe.close()
if self.p is not None:
self._check_process()
self.fileobj.close()
self.__closed = True
@property
def closed(self):
return self.__closed
def fileno(self):
return self.pipe.fileno()
def flush(self):
self.pipe.flush()
def isatty(self):
return self.pipe.isatty()
def readable(self):
return self.mode == self.READ
def writable(self):
return self.mode == self.WRITE
def readinto(self, b):
if self.mode != self.READ:
import errno
raise OSError(
errno.EBADF, "read() on write-only %s object" % self.__class__.__name__
)
size = self.pipe.readinto(b)
if size == 0:
self._check_process()
return size
def write(self, data):
if self.mode != self.WRITE:
import errno
raise OSError(
errno.EBADF, "write() on read-only %s object" % self.__class__.__name__
)
data = self.pipe.write(data)
if not data:
self._check_process()
return data

Some files were not shown because too many files have changed in this diff Show More