Compare commits

...

655 Commits

Author SHA1 Message Date
Holger Hans Peter Freyther a72a9ad911 Merge branch 'hfreyther/tmp' of git://git.sysmocom.de/poky/meta-sysmocom-bsp into edison 2012-09-15 17:08:33 +02:00
Jan Luebbe dabdc1f5d2 Attempt to target multiple versions of Poky at the same time
The idea is that the basic extension resides inside the the normal
recipe directories. Depending on the version of poky the bbappends
need to be included. Appends applying to all versions will be put
into the shared folder, specific ones into the specific directory.
Once a bbappend can not be shared anymore it needs to be copied.
2012-09-15 17:03:20 +02:00
Holger Hans Peter Freyther a5c48367a6 Merge git://gitorious.org/sysmocom-openembedded/meta-telephony into edison 2012-09-15 16:40:09 +02:00
Holger Hans Peter Freyther 2ae26ee3fa openbsc: Improve the init scripts, do not write counters
Make the start/stop of the NITB, BSC and MGCP HW work, remove the
force-reload option as it didn't do anything and omit writing counters
into the database.
2012-09-15 16:34:21 +02:00
Holger Hans Peter Freyther 3be74372be Merge git://gitorious.org/sysmocom-openembedded/meta-telephony into edison 2012-09-15 15:43:20 +02:00
Holger Hans Peter Freyther 46ea81ade5 Merge commit 'd6415c8069714519ab242f7bb1d493d7744529cb' into edison 2012-09-15 15:37:19 +02:00
Holger Hans Peter Freyther aeb390d1cf libosmocore: Upgrade to newer version with libosmovty improvements 2012-09-13 21:20:19 +02:00
Holger Hans Peter Freyther 6a4abb5830 lmsensors-apps: Package the *.a into a new -staticdev package 2012-09-04 14:14:00 +02:00
Holger Hans Peter Freyther b8b0dff3d4 watchdog: Target both edison and HEAD in this overlay
One needs to use BBMASK or delete depending on the targeted
OE-Core/Poky version.
2012-09-04 14:13:26 +02:00
Holger Hans Peter Freyther 4f78b6ef78 netbase: Target both edison and HEAD in this overlay
One needs to use BBMASK or delete depending on the targeted
OE-Core/Poky version.
2012-09-04 14:12:38 +02:00
Holger Hans Peter Freyther 97ba83f17a busybox: Target both edison and HEAD in this overlay
One needs to use BBMASK or delete depending on the targeted
OE-Core/Poky version.
2012-09-04 14:11:51 +02:00
Holger Hans Peter Freyther 4f61482461 openggsn: Package the *.a into a new -staticdev package 2012-09-04 14:08:36 +02:00
Holger Hans Peter Freyther a6cbcf75d5 libdbi-drivers: Introduce INC_PR for this recipe 2012-09-04 14:07:17 +02:00
Holger Hans Peter Freyther 25a726eea5 libdbi-drivers: Package the *.a into a new -staticdev package 2012-09-04 14:06:23 +02:00
Holger Hans Peter Freyther 1579cdf0fe libdbi-drivers: Add checksums for version 0.8.3 2012-09-03 13:37:41 +02:00
Holger Hans Peter Freyther c0cbc30d4c libdbi: Add checksums for version 0.8.3 2012-09-03 12:18:54 +02:00
Holger Hans Peter Freyther d6415c8069 sysmocom: Make dvnixload and ubl accessible via public git
dvnixload and ubl are available via public git.
2012-08-21 15:14:47 +02:00
Holger Hans Peter Freyther a4331e9bee openggsn-config: Fix the name of the ggsn.conf for the sysmocom-bsc 2012-08-20 23:41:48 +02:00
Holger Hans Peter Freyther 138ac3bc45 libgsm_1.0.13: Add necessary " for the variable assignment
Newer versions of BitBake are more picky about it. Add the quotes.
2012-08-20 21:26:19 +02:00
Holger Hans Peter Freyther c35fa18841 linux-sysmocom.inc: Add quotes around the value for newer versions of bitbake
BitBake is finally more picky about variable assignments. Add the
necessary quotes.
2012-08-20 21:25:04 +02:00
Holger Hans Peter Freyther d9150d375c openggsn-config: Add the GGSN configuration to this layer 2012-08-20 19:34:56 +02:00
Holger Hans Peter Freyther fd604f8497 sysmocom-*-image: Add the IP and E1 image to this layer
Add a BSC IP and BSC E1 image to the meta-sysmocom-bsp.
2012-08-20 19:30:02 +02:00
Holger Hans Peter Freyther bbbc805a2d femtobts: Drop the old femtobts calibration utility
A new version can be found inside the osmo-bts repository.
2012-08-20 19:26:31 +02:00
Holger Hans Peter Freyther ba44e70c38 sysmocom-bsc-e1: Introduce a sysmocom-bsc-e1 machine type 2012-08-20 18:50:58 +02:00
Holger Hans Peter Freyther f5b92b4bf2 u-boot: Upgrade to a version with the recovery mode 2012-08-15 21:34:25 +02:00
Holger Hans Peter Freyther 2d8f097946 openvpn: Introduce OpenVPN from meta-openembedded 2012-08-15 17:50:48 +02:00
Holger Hans Peter Freyther f88c9a6fbd libosmocore: Build a 0.5.3+ version and force rebuild
The behavior of the OSMO_MIN/OSMO_MAX has been fixed. Update
the library and force the rebuild.
2012-08-15 17:09:28 +02:00
Holger Hans Peter Freyther 62e7f7f1bc osmo-bts: Build the latest version of osmo-bts
This has a GSM band selection fix. GSM1900 band is now working properly.
2012-08-15 16:40:03 +02:00
Holger Hans Peter Freyther d03aa9c516 osmo-bts,osmo-pcu: Both applications should be rebuild on osmocore upgrades
Rebuild the BTS and PCU when the SOVERSION of a libosmocore library
is changing. Do that by adding the ${META_TELEPHONY_OSMO_INC} into
the PR.
2012-08-15 16:35:58 +02:00
Harald Welte 2be99ac429 Add a new task 'task-gprscore' containing sgsn/ggsn/routing 2012-08-15 16:34:10 +02:00
Harald Welte 6734e9a695 add osmo-pcu for GPRS support on sysmobts 2012-08-15 16:33:29 +02:00
Harald Welte 5928a0374a update to firware + api version 2.4 2012-08-15 16:30:41 +02:00
Holger Hans Peter Freyther 8479f83f39 libosmocore: Introduce 0.5.3 and bump the META_TELEPHONY_OSMO_INC
META_TELEPHONY_OSMO_INC functions as kind of a reverse dependency,
packages using libosmocore will now rebuild and link to the newer
soversion of the libraries. Upgrade OpenBSC due an ABI change in
the GPRS/GB code.
2012-08-15 16:28:09 +02:00
Harald Welte 73295758f9 libosmocore: update to more recent version including a BSSGP fix 2012-08-15 16:23:56 +02:00
Holger Hans Peter Freyther a641873503 Merge commit '4e2ab7017f80c42a2b112693fa589ac29cee405d' into edison 2012-08-15 09:17:30 +02:00
Holger Hans Peter Freyther 9805fb9f81 Merge commit 'f4320dd67f9681e24bcfbe112832cac2ceacebd0' into edison 2012-08-15 09:17:29 +02:00
Holger Hans Peter Freyther 50dba82586 update: Use the git instead of the ssh protocol 2012-08-15 09:16:54 +02:00
Holger Hans Peter Freyther 4e2ab7017f misc: Move from SSH to Git protocol for the sysmocom source 2012-08-15 08:18:53 +02:00
Holger Hans Peter Freyther 9f0744ce76 debootstrap: Add a version of debootstrap to bootstrap debian images 2012-07-21 18:10:27 +02:00
Holger Hans Peter Freyther 21c475ae4a gnupg/libksba: Add gnupg/libksba from openembedded-contrib for debootstrap 2012-07-21 18:10:27 +02:00
Holger Hans Peter Freyther f4320dd67f dahdi-tools: Build dahdi_pcap and fix the installation of the perl modules 2012-07-21 18:05:25 +02:00
Holger Hans Peter Freyther 1f71735516 dahdi-linux: Enable the mirror mode required for dahdi_pcap, cleanups
Enable the mirror mode to be able to use the dahdi_pcap utility of
dahdi_tools.
2012-07-21 18:05:25 +02:00
Holger Hans Peter Freyther fe53a9d4aa dahdi: Upgrade from 2.5.0.1 to 2.6.0 2012-07-21 18:05:25 +02:00
Holger Hans Peter Freyther 9416f178b1 dvnixload: Deal with UBL being gone but U-Boot is present.
Upgrade the dvnixload to a version that will always flash the
UBL payload to the device.
2012-07-11 14:26:51 +02:00
Holger Hans Peter Freyther d838ac6e80 ubl/dvnixload: Update both ubl and dvnixload for recovery
The UBL allows to interrupt the NAND boot mode and switch to the
UART mode for recovery. Everyone with physical access will be able
to interrupt the boot.
2012-07-11 09:05:53 +02:00
Holger Hans Peter Freyther e2ab56be8f ubl: Initialize the UART0/UART1 on the sysmobts-v2
This is fixing the early printf inside u-boot.
2012-07-11 07:33:19 +02:00
Holger Hans Peter Freyther e0bf4c7fea sysmobts-calib: Build, package and make sure it is installed
Install the sysmobts calibration utility. task-sysmocom-bts is
installed on every bts and will now pull in the calibration utility.
The sysmobts screen needs to be stopped before this application
can run.
2012-07-10 00:17:15 +02:00
Holger Hans Peter Freyther 4166201d03 Merge commit 'a6ae74f721439ddbb6e2c0d23c4e227b4634935d' into edison 2012-07-09 17:06:17 +02:00
Holger Hans Peter Freyther a6ae74f721 ca-cacert-rootcert.bb: Have the complete root for CACert 2012-07-09 17:05:52 +02:00
Holger Hans Peter Freyther 94fa2d9623 Merge commit 'be68ad33d2b2d2df2908a9e5d186c0d0df82f4a6' into edison 2012-07-09 16:39:03 +02:00
Holger Hans Peter Freyther be68ad33d2 ca-cacert-rootcert.bb: Create symlinks for all fingerprints of the cert 2012-07-09 16:38:38 +02:00
Holger Hans Peter Freyther 4cfac93114 Merge commit '4df56218263913830d71b4c48be866279702c78a' into edison 2012-07-09 16:20:06 +02:00
Holger Hans Peter Freyther 4df5621826 ca-cacert-root: Do not use the full-blown ca-certificates
First ca-certificates does not create a symlink from /etc/ssl/certs
to /usr/lib/ssl/certs, second it does not run the c_rehash perl utility
making the recipe pretty useless and third it trusts way too many
cert authorities.
2012-07-09 16:19:40 +02:00
Holger Hans Peter Freyther 5d46944934 Merge commit 'e423b30a83bf4ad14a0a3db619faccd979aa4573' into edison 2012-07-09 14:51:12 +02:00
Holger Hans Peter Freyther d5f6ae1142 sysmocom-upload.sh: Sync all sources and do not expire old sources
We need to keep old sources around for some time and need to remove
them with another script after we stopped distributing them.
2012-07-09 14:50:27 +02:00
Holger Hans Peter Freyther e423b30a83 task-sysmocom: Install wget and certificates for ssl 2012-07-09 14:49:46 +02:00
Holger Hans Peter Freyther ae891be609 ca-certificates: Taken from meta-openembedded needed for wget
I upgraded it to 20120623 and updated checksums.
2012-07-09 14:49:41 +02:00
Holger Hans Peter Freyther 4d8fef32c9 Merge commit 'e568fa2c271a13144811c62fedc72977df8ad9e8' into edison 2012-07-09 10:40:59 +02:00
Holger Hans Peter Freyther a6f1cb82a7 Merge commit '33fe48f3b792563ad99d575750e36dffc9ac808a' into edison 2012-07-09 10:40:57 +02:00
Holger Hans Peter Freyther 33fe48f3b7 openbsc: Upgrade to version v0.12.0 of OpenBSC
This has split out the GPRS library and some bugfixes.
2012-07-09 10:35:55 +02:00
Holger Hans Peter Freyther 794c0e73e6 libosmocore: Upgrade to version 0.5.2 for the libgb split
libosmocore gained a new GPRS helper library.
2012-07-09 10:35:55 +02:00
Holger Hans Peter Freyther d1d9f99eb6 libosmo-abis: Add 0.1.3 with buildsystem changes and minor bugfixes 2012-07-09 10:35:55 +02:00
Holger Hans Peter Freyther e568fa2c27 osmo-bts: The start script is using nice, depend on coreutils for that
Our version of busybox does not provide the nice command, use the
fullblown coreutils instead.
2012-07-09 10:28:22 +02:00
Holger Hans Peter Freyther e6ec2228da osmo-bts: Upgrade the osmo-bts version for various bugfixes
This is fixing the GSMTAP debug support and permanent paging.
2012-07-09 10:25:00 +02:00
Holger Hans Peter Freyther 9257e4b8a1 femtobts-api: Force an upgrade due some local modifications for supporting RevB hardware 2012-07-09 10:08:47 +02:00
Holger Hans Peter Freyther 0f6a89c788 linux-sysmocom: Build the kernel with MMC support, package the modules
Autoload mmc_block and the davinci_mmc module. This will load the mmc_core
module as another dependency.
2012-07-09 10:08:42 +02:00
Holger Hans Peter Freyther c1625ee284 openmoko-gsmd: Package the cell_log separately and respawn 2012-07-09 10:07:46 +02:00
Holger Hans Peter Freyther 40355ff62e Initialize repositories with scripts 2012-06-27 01:12:32 +08:00
Holger Hans Peter Freyther a7befd603b Add 'meta-sysmocom-bsp/' from commit '90a211eb560d7c984a444f9697ff1d06e4bca838'
git-subtree-dir: meta-sysmocom-bsp
git-subtree-mainline: 88c1293c49
git-subtree-split: 90a211eb56
2012-06-27 01:10:49 +08:00
Holger Hans Peter Freyther 88c1293c49 Add 'meta-telephony/' from commit '4fed144378a38115805f986c56d883763f6dab79'
git-subtree-dir: meta-telephony
git-subtree-mainline: e94c542d7c
git-subtree-split: 4fed144378
2012-06-27 01:10:34 +08:00
Jan Luebbe e94c542d7c libpcap: use binconfig class to deploy pcap-config
This fixes building of tcpdump on hosts where libpcap-dev is installed.
Also introduce INC_PR.

(From OE-Core rev: 942cdda2194078755a11efef3ba3f502f72e4f5e)

Signed-off-by: Jan Luebbe <jluebbe@debian.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-27 01:09:52 +08:00
Holger Hans Peter Freyther 90a211eb56 meta-sysmocom-bsp: Backport the archives 2012-06-26 19:07:11 +02:00
Elizabeth Flanagan 06072024be poky.conf: Flipping for edison point release
Prior to final build, we need to flip DISTRO_* and SDK_VERSION
to new values.

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
2012-06-21 13:07:09 -07:00
Robert Yang 107ec95659 apt 0.7.14: do_compile failed with gcc 4.7
apt do_compile failed with gcc 4.7:

deb/deblistparser.cc: In member function 'virtual short unsigned int debListParser::VersionHash()':
deb/deblistparser.cc:212:13: error: redeclaration of 'char* I'
deb/deblistparser.cc:202:22: error: 'const char** I' previously declared here

Backport the patch from the upstream would fix the problem, both target and
native apt need it.

[YOCTO #2488]

(From OE-Core rev: 80c1ab1248ff38ba97cf5780fc05ff1321e14e10)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-21 12:04:39 +01:00
Richard Purdie af3e5039e8 apt: Fix parallel make race
I was just going to turn off parallel make but ended up fixing this properly.

(From OE-Core rev: 440a6d5aacf7807536feee5d09484712ba34ca80)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-21 12:04:30 +01:00
Richard Purdie 08d70734d5 apt: Fix locale header and hardcoded libname issues
apt wasn't building on modern libc/compiler combinations due to missing
header includes.

The libcpp version was also being hardcoded, this patch generates it
dynamically to work on different host systems which no longer have
this.

(From OE-Core rev: 4bcffbcd05c86903fbdf47bb46bf1a52b888dfeb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-21 12:04:16 +01:00
Holger Hans Peter Freyther f3f2d7149d u-boot: Modified the configuration in regrd to boot interruption
Typing bts-delay will interrupt the boot and enter the command
line of the bootloader.
2012-06-15 23:42:24 +02:00
Yi Zhao 164a4d1bac scripts/qemuimage-testlib: fix typos
(From OE-Core rev: 30c6ec403e1696b5fd94b92328ef9edec535a57a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-14 11:18:51 +01:00
Richard Purdie 7e0dd59e30 ghostscript-native: Ensure the sys/time/h fix is applied for native builds
On my system, the sys/time.h header is in a subdir off /usr/include
which causes a build failure. Apply the target CFLAGS fix to native
builds as well to address this.

(From OE-Core rev: 8968db5fcc99c6580de91f9d6c55478c735ca375)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-06-14 11:18:40 +01:00
Holger Hans Peter Freyther 4fed144378 openmoko-gsmd: Add support for the sysmobts_v2 with a modem daughterboard 2012-06-11 08:39:36 +02:00
Holger Hans Peter Freyther 914296ad20 sysmobts-v1: Change the defconfig to hide a kallsysms issue 2012-06-10 20:23:33 +02:00
Holger Hans Peter Freyther c0663ce337 osmo-bts: Upgrade the osmo-bts version for a sysmobts-v1 fix and v2 improvement 2012-06-10 20:01:12 +02:00
Holger Hans Peter Freyther 420ea289a2 linux-sysmocom: Upgrade to 3.2.19, this requires a manual symlink
Kernel upgrades on a live system is not well tested, right now the
symlink is not updated but for some reason the old uImage is kept
installed.
2012-06-10 17:16:55 +02:00
Holger Hans Peter Freyther d9a77eb641 task-core-boot.bbappend: Increase PR due the moving of the watchdog
Make sure that on opkg upgrade the watchdog will now be installed due
the new task-core-boot package.
2012-06-10 16:48:00 +02:00
Holger Hans Peter Freyther 17acc4a562 task-sysmocom-bts: Do not package the femtobts-example
This is not available in this layer, remove it.
2012-06-10 15:53:20 +02:00
Holger Hans Peter Freyther 45580f23e8 Merge remote-tracking branch 'origin/master' 2012-06-09 23:21:53 +02:00
Holger Hans Peter Freyther 62ac580831 sysmobts: Upgrade to a BTS version with fixed 2bis SI scheduling
This is a hot fix for the 2bis case, the more generic scheduling
patch needs to be tested a bit more.
2012-06-09 23:17:07 +02:00
Holger Hans Peter Freyther be8f70e8a1 linux: Change the sysmocom-bsc kernel config in regard to USB and FS
* Enable verbose detection, add CP2012 based serial adapter support
* Only enable USB1.1 HCD for now to fix the detection of the USB serial
  adapters
* Enable more filesystems in the config to allow upgrading the boot
  partition during the runtime (after installing the right codepage)
2012-06-09 23:17:07 +02:00
Holger Hans Peter Freyther c29b5d8bb4 pkgconfig: Place the pkg.m4 into the main package
The pkg.m4 should be in the main package, the -dev package will attempt
to pull in X11 header files and will require too much filesystem space.
2012-06-09 23:17:07 +02:00
Holger Hans Peter Freyther 03c9643695 watchdog: Let the machine provide the watchdog dependency
Not every machine has a hardware watchog, let the machine decide
if a watchdog should end up in every image.
2012-06-09 23:17:07 +02:00
Harald Welte ce6f4b0bce update osmo-bts to recent git which adds RF ACTIVE LED support 2012-06-09 23:17:07 +02:00
Holger Hans Peter Freyther 9f86fa35a2 openmoko-gsmd: Add the Openmoko GSMD recipe
This is based on the gsmd recipe from OE classic. There will be
some more tweaking for respawn and the cell log utility.
2012-06-09 22:59:13 +02:00
Harald Welte 242922ceae SDK: make sure to include libosmo-abis, libdbi and libgtp headers
This enables the SDK to do a full openbsc build.
2012-06-09 22:59:05 +02:00
Harald Welte a79df5e650 update osmo-bts to include RF LED / rf_lock support 2012-06-02 01:08:10 +02:00
Harald Welte df89bf00e7 add ntpdate to task-sysmocom-tools 2012-06-02 01:06:43 +02:00
Harald Welte a3c1f02557 import ntp recipe from OE (we need ntpdate) 2012-06-01 16:44:35 +02:00
Lianhao Lu aca161f8a0 bitbake/persist_data: Reconnect when DB is locked
[YOCTO #1761]
Reconnect to the backend Sqlite DB in 'database is locked' exception so
the timeout can be leveraged in each time retry.

(Bitbake rev: b310382764367b573c84f33d847c6eb821266f9e)

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
2012-05-31 13:16:41 -07:00
Richard Purdie 94c8d01eba runqueue.py: Add inter setscene task dependency handling
This is being added to resolve setscene race issues where we do have
particular dependencies required between setscene tasks. This allows
specific dependencies to be specified. This allows us to fix the races
in sstate with the useradd class in OE-Core.

Any tasks being depended upon have their reverse dependencies cleared to
ensure we don't have circular references.

(Bitbake rev: e1b157d26374a70e6274edcb4c0b9f3bc48f765c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
2012-05-31 13:16:41 -07:00
Richard Purdie e1e0dd932b runqueue.py: Fix missing setscene dependencies
When constructing the setscene inter-dependencies, we need to account for all task,
not just the last one found. This patch corrects this oversight and ensures all
dependencies are added, not just the first one found.

(Bitbake rev: b9b5b5129d066e1ff7d3effda116afc3c6657beb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
2012-05-31 13:16:41 -07:00
Richard Purdie 6c335846d9 populate_sdk_ipk.bbclass: Ensure the correct environment is setup for postinstalls
Without this, various postinstalls get run with incorrect environments
leading to various failures when building the toolchains.

This adds some duplication and some variables we'd be better off
removing. It does unbreak the SDK ipk code for now though. This needs
revisiting.

(From OE-Core rev: c5e6a533eab2f5af4a52d22f8efe5b49b77cd26c)

(From OE-Core rev: ab2a4591c4c3926a960f18fa7e848f5d41255e14)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:47 +01:00
Beth 'pidge' Flanagan 774f93e8d3 common-licenses: Adding/updating to current
[YOCTO #2230]

1.1+ had some incorrect license text. This corrects that text and
adds licenses that didn't exist in 1.1+.

(From OE-Core rev: 43bd89eb195f56afef12e52ed58a2f0cad9c73db)

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:47 +01:00
Joshua Lock 535cfa538b icon-naming-utils-native: add SRC_URI checksums
[YOCTO #1866] reported errors with fetching icon-naming-utils. This turned out
to be an issue with upstream which was impaired by the recipe not containing
checksums.

Without a checksum failure we were trying to decompress the error page we
received from upstream.

(From OE-Core rev: 0af0591e25b35beb9dd10f9d5de8bc2e63f7731e)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:47 +01:00
Joshua Lock ac63b3f8ef zlib: install pc file
Joshua Immanuel reported, and provided a patch to fix, that our custom
autotooling for zlib does not install the pc file.

Fixes [YOCTO #1983]

Patch-from: Joshua Immanuel <josh@hipro.co.in>
(From OE-Core rev: 37fbe2e1a706af634f400213b9fb4c6f0670c15e)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:46 +01:00
Scott Garman 4039b5b97c package_rpm.bbclass: ensure base-passwd and shadow get installed first
When generating images, we need to make sure that base-passwd and
shadow get installed before other packages, which might need to create
custom user accounts.

Thanks to Richard Purdie for the initial version of this fix.

This fixes [YOCTO #2127]

(From OE-Core rev: 3d2d3cb379608301b17ce57787d324c2f06bf4f9)

(From OE-Core rev: f35902844c5c1de06c9a1b2111abf0d8b5687a9b)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:46 +01:00
Richard Purdie 67334bfb26 sstate.bbclass: Remove possibility of file corruption and make package writing atomic
There is currently a race window when creating sstate packages since we don't
atomically write the files to SSTATE_DIR. This change ensures we do so by writing
to a temporary file and then doing an atomic move.

(From OE-Core rev: 52bf113e786a57123a9da98f64442afbc2f1471e)

(From OE-Core rev: d527f68bdf167b4a3dcc035968da59677abb70bb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:46 +01:00
Richard Purdie 36e13dd42f sstate.bbclass: Add support for sstate preinst functions
(From OE-Core rev: f2b0a71b3100a0d2ceb80300d7f3823a31eb907a)

(From OE-Core rev: 8ca7387ff2dd788221a16021ec98b4aee946a187)

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

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:46 +01:00
Richard Purdie de485f4973 sstate: Add SSTATE_SCAN_FILES
We process all files in the native/cross cases for finding and
fixing relocation issues. In the target case we've only processed
.la and binconfig files. Since there are other files which are
in need of this processing, this change allows recipes to specify
files that may be outside the normal set. This means hardcoded
paths that need to be fixmepathed to work correctly are handled
and addresses some sstate relocation bugs that have been seen.

Based on a patch from Saul Wold <sgw@linux.intel.com>

(From OE-Core rev: 6ffdcd9120b572fa41659029c3bda7bf00ebcb77)

(From OE-Core rev: c6148b8dde3e0fddc4135b48fd6d01e2de662919)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:45 +01:00
Darren Hart 56310cbc4c syslinux: Avoid using linux.ext2_fs.h if possible
Fixes [YOCTO 2236]

With recent Linux kernel headers, such as 3.3 in Fedora 16, the linux/ext2_fs.h
header has been removed. This causes compile failures for syslinux-native.
Backport a fix to address this from syslinux-4.06-pre3.

(From OE-Core rev: d61c5fc67780b552fcf3d78ebcf9bd3888af4e0a)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Ross Burton <ross.burton@intel.com>
CC: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:45 +01:00
Scott Garman 68cd8deadc useradd.bbclass: retry useradd/groupadd commands to avoid lock race issues
A race condition can occur when adding users and groups to the
passwd and group files, causing errors like the following:

 ERROR: Function 'useradd_sysroot' failed
 Tried to access "/etc/group" but this was locked.

This fix will cause the useradd code to retry the useradd and
groupadd commands up to 10 times (with a 1s sleep in between
attempts) before failing.

This fixes [YOCTO #1794]

(From OE-Core rev: 68c589f1b5ee36f0aff151b728447ffdae14622c)

(From OE-Core rev: fb9f5feaa49b78d03d25d96254a5ce04079ce594)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:45 +01:00
Zhai Edwin b2a0243f05 shadow-sysroot: Fix for multilib
Fix following error in multilib build:
"ERROR: Task do_package_setscene depends upon nonexistant task
poky/meta/recipes-extended/shadow/shadow-sysroot_4.1.4.3.bb:do_populate_sysroot_setscene"

>From richard.purdie@linuxfoundation.org

(From OE-Core rev: 5de2c22fb42c12783abc090a81f10db9eb39732f)

(From OE-Core rev: 8a8b1a49e3c7f96d76f6457a1f9a14e1eb4d5302)

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:45 +01:00
Otavio Salvador a99b7d39dc useradd.bbclass: override USERADDSETSCENEDEPS to empty when building cross packages
(From OE-Core rev: 5650eb44ea28c87f2f87ea3c5a557b9f08d58775)

(From OE-Core rev: fa0f0052b49b7809b9b55df6049a0dfedbc94560)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:44 +01:00
Otavio Salvador 755508c423 useradd.bbclass: skip processing on virtclass-cross extended packages
(From OE-Core rev: 4308acbbd43e6b8b37123d95df6675233007dae4)

(From OE-Core rev: 4a338c552d989d37a26eb6cc0c1da95a6928af9f)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:44 +01:00
Richard Purdie adbf38414e useradd.bbclass: Fix missing quote
(From OE-Core rev: d7b13cd42ab8d5f44f97e119b73ec2e363677d26)

(From OE-Core rev: 6e21a379542ef5428d6005782f1ad4a8c764eb47)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:44 +01:00
Richard Purdie c3be61e204 useradd: Ensure dependencies are only added for target recipes, not native or nativesdk
(From OE-Core rev: 63d006b2d3fc2223c74f81b91f70f5c841108c80)

(From OE-Core rev: d6c43fdc815347a0adfee590da56f8b332540da6)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:44 +01:00
Richard Purdie 490753f440 useradd.bbclass: Add explict setscene dependencies to ensure correct ordering of setscene tasks
(From OE-Core rev: ffc7bbcf0011de3f1f6e8d95f1de0b8f7164fa51)

(From OE-Core rev: a9aae582a6068a946cf177ce33e54cb0aee6c6e5)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:43 +01:00
Richard Purdie f3fc5e1e3f useradd.bbclass: Ensure pseudo can load in the pseudo unloaded case
In the do_populate_sysroot_setscene case, pseudo has been unloaded and we need
to reload it. This code change ensures all the pseudo options are specified
so pseudo loads correctly.

It also improves some of the comments so all the different contexts are listed.

(From OE-Core rev: 76345cd61c9523ce6755ef8e923dec37800b7a98)

(From OE-Core rev: 6f25ede827ee469464ca2db72bf05c75fa7c11f3)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:43 +01:00
Richard Purdie e2c5e5a513 useradd.bbclass: Execute user addition code before do_package_setscene, not after do_populate_sysroot_setscene
The user addition needs to happen before the do_package files are extracted
by do_package_setscene since those are the ones we need to preserve the file
ownership information for. This patch ensures this happens.

(From OE-Core rev: 34282c1b996ef008384af456735692d66ddabc13)

(From OE-Core rev: b571766ffc7ec5aa78035557c25a0e8b244c17c8)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:43 +01:00
Richard Purdie c5a9efca96 useradd: Ensure -native recipes don't depend on target recipes
Without this change, dbus-native can end up depending upon base-passwd
for example. This change mirrors the existing nativesdk code.

Based on a patch from Henning Heinold <heinold@inf.fu-berlin.de>
but with some additions from me.

(From OE-Core rev: eba81d1c606ec29ffb793c1cb3cfed9562d552bc)

(From OE-Core rev: b325378930655beeec03bbc5ce6ccf2b29f408fd)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 21:11:43 +01:00
Holger Hans Peter Freyther 5508643b52 wget: Be more specific about the version of GPL 2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther 910852c052 linux-sysmocom: Be more specific about the license of linux 2012-05-31 14:46:57 +08:00
Dexuan Cui 842d3ece07 socat: add the latest stable version 1.7.2.0
socat is useful for the self-hosted-image work.

The original recipe is from OE:
http://git.openembedded.org/openembedded/tree/recipes/socat/
and I upgraded it to 1.7.2.0.

Thank Koen Kooi <koen@dominion.thruhere.net> for suggesting
how to assign the LICENSE field with a proper value.

(From OE-Core rev: b1771ff0ad39250678bd53b0ae7543c9365572f5)

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther 7aaa4cc880 watchdog: Start the watchdog script in rcS.d as early as possible
This needs to be started after udev, after loading modules.
2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther 6d69dba610 watchdog: Install a init script and add config file to conffiles 2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther aed232262e watchdog: Add machine specific watchdog file 2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther 6dcaf7d614 osmo-bts: Upgrade to a version that reloads the firmware on every start 2012-05-31 14:46:57 +08:00
Harald Welte 77f660aa0d update to sysmobts-v2 API/firmware version v2.1 2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther 39d7350b90 sysmobts-v2: Allow to override the flash parameters
RevB and RevC feature different kind of nand flash. RevB is still
pre-production hardware so for the few units allow to set the right
flash parameters in the local.conf.
2012-05-31 14:46:57 +08:00
Harald Welte 967184aef7 sysmobts-v2 has the same NAND flash as -v1, so use same UBI parameters 2012-05-31 14:46:57 +08:00
Holger Hans Peter Freyther bdbd14a8d5 u-boot: Fix the u-boot git version in our public git repository 2012-05-31 14:46:57 +08:00
Harald Welte b9d489c543 add the sysmobts-remot program to the "task-sysmocom-bts"
This is primarily used for development, but as it is such a small tool, it
makes sense to always include it in the build.
2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther 2a378aa333 firmware: The package depends on the machine, set the right arch 2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther f1ce2c13e5 image: Make sure that everything from the machine rdepends is built
Make sure that everything the machine needs to install is built.
2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther 999cf4843e image: Depend on wget to have password authentication for the feeds
wget implements HTTP authentication, this means one can use opkg to
access password protected feeds for upgrades.
2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther b863e59aa6 wget: Add wget from meta-oe
Having wget available will allow to use it for online updates with opkg.
2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther 73bcda3f97 bts: Build a jffs2 image as well, make sure the firmware is built 2012-05-31 14:46:56 +08:00
Holger Hans Peter Freyther dd6f9356b1 meta-sysmocom-bsp: Create bsp for the sysmocom hardware
This layer will power our hardware. This includes the sysmoBSC, sysmoBTS v1
and the sysmoBTS v2.
2012-05-31 14:46:42 +08:00
Holger Hans Peter Freyther 1e224b39ae libdbi-drivers: Remove redundant LICENSE assignment 2012-05-30 19:23:22 +08:00
Holger Hans Peter Freyther 39b09a8849 dahdi: Be more specific about the version of GPL. 2012-05-30 19:23:06 +08:00
Holger Hans Peter Freyther 8caa70df0a ortp: Be more specific about the version of the LGPL 2012-05-30 19:23:01 +08:00
Holger Hans Peter Freyther 5a11d46c4e libdbi: Be more precise about the license of libdbi and libdbi-drivers 2012-05-30 19:17:49 +08:00
Holger Hans Peter Freyther d24c97d308 osmocom: Fix the license of the libraries
GPL is too unspecific, point to the right versions
2012-05-30 17:51:30 +08:00
Saul Wold 15905aec48 grub: Add SRC_URI Checksums for sanity
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-06 09:53:38 +01:00
Saul Wold 2b92d9f6d3 image.bbclass: add check for live and convert to ext3
The live image type depends on ext3 which has it's own
dependencies, while the live type has none, this is a
backport change to fix [YOCTO #2246]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-05-06 09:53:27 +01:00
Holger Hans Peter Freyther 96a864f527 libosmocore: Upgrade to get GSM_LCHAN_PDTCH 2012-04-28 22:38:54 +08:00
Richard Purdie bfa48c3c09 dosfstools: Add patch to disable fat32 autoselection and behave as 2.10
It appears msdos image population and fat32 images are incompatible.
This reverts to the 2.10 behaviour of defaulting to fat16 instead of
using fat32 for large images, allowing image generation to work
correctly. This is a workaround and a proper fix is really needed.

(From OE-Core rev: c2de8d41236cf1293db9e6c69d69e8d14f55ffd1)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:12:08 +01:00
Otavio Salvador ef6062981b dosfstools: update native to 2.11
This unify recipes for target and native builds and also drops the the
already merged patches.

(From OE-Core rev: 3a401ddce55e185c8ccfdc43c1440fd77daff9ae)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:12:04 +01:00
Scott Garman f57eca6f28 dosfstools: add Upstream-Status to patches
(From OE-Core rev: 735a3e5d3399e29e4d6fa82dabbdd1687eaa29e9)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:12:00 +01:00
Saul Wold 885ebdae10 dosfstools: Add SRC_URI Checksum
(From OE-Core rev: a19bfc10e60ddc7e9317654ca7565d39acbc3987)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:11:56 +01:00
Darren Hart 33561a5417 bootimg: Do not force FAT32 on all images, it violates the FAT specification
Fixes [YOCTO #1940]

do_bootimg was performing the FAT overhead calculations assuming FAT32 and then
forcing the use of FAT32 with "-F 32" to mkdosfs. The FAT specification is clear
on cluster count being the determining factor for FAT size (even if the fs
string is set to FAT32, go figure). Syslinux follows this spec, and rightly so,
resulting in a failure on core-image-minimal:

	syslinux: zero FAT sectors (FAT12/16)

Drop the "-F 32" from mkdosfs to allow it to select the appropriate FAT size
based on cluster count. Leave the FAT overhead calculation in FAT32. This will
result in a little extra padding for really small images, but not enough extra
to justify recalculating for FAT12 and FAT16.

Tested with a core-image-minimal build for atom-pc. do_bootimg completed
successfully, and the resulting image was FAT16.

(From OE-Core rev: 634137704dd1a205e377a1131ef708f1c981f6b2)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Backported to edison by Darren Hart.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:11:51 +01:00
Darren Hart bb31c819be bootimg: Fix a math thinko in the block count calculation
Fixes [YOCTO #1852] ... again.

The conversion from sectors to blocks was multiplying by 2 instead
of dividing by 2. Blocks are 1024 bytes, sectors are 512 bytes. The
result was images being much larger than intended.

Reported-by: Tom Zanussi <tom.zanussi@intel.com>
(From OE-Core rev: b35384fa3ca96b31c63d764322215abced2066e4)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Backported to edison by Darren Hart.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:11:43 +01:00
Darren Hart d1c5de9ccb bootimg: Account for FAT filesystem overhead in image size
Fixes [YOCTO #1852]

The bootimg class wasn't accounting for non-trivial amount of space
required by the directory entries and FATs for the FAT filesystem.

This patch attempts to make an accurate prediction of FAT overhead and
adjusts the image size accordingly. It assumes no more than 16 directory
entries per directory (which fit in a single sector). It also assumes
8.3 filenames. With the ceiling functions rounding up to full sectors
and tracks, these assumptions seem reasonable.

In order to ensure the calculations are accurate, this patch forces the
FAT size to 32, rather than allowing mkdosfs to automatically select 12,
16, or 32 depending on the image being built.

Tested by setting BOOTIMG_EXTRA_SPACE=0 and building core-image-minimal
and core-image-sato for fri2-noemgd from meta-intel.

(From OE-Core rev: 68aa18609c10a3ae2f738930c933fa2a95ce8959)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Backported to edison by Darren Hart.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:11:38 +01:00
Darren Hart 4274ebdd00 bootimg: Use mcopy to construct the hddimg
Fixes [YOCTO 2138]

The initial directory support (-d) added to mkdosfs has proven to be incomplete
and non-compliant with FAT. Rather than continue to maintain this feature and
work around the various issues, we can use mcopy to construct the image.

bootimg.bbclass already depends on mtools-native (although it may not have
needed to previously). No new dependencies are introduced. The image created
passes dosfsck cleanly. Remove the call to dosfsck.

mcopy reported an error with the image we were creating:
Total number of sectors (107574) not a multiple of sectors per track (32)!

Add some logic to ensure the total sector count is an integral number of sectors
per track, including forcing the logical sector size to 512 in the mkdosfs
command.

The du -bks arguments are contradictory, -b is equivalent to "--apparent-size
--block-size=1" and -k is --block-size=1K. If reordered, -kbs will report the
disk usage in bytes insteadk of 1k blocks. Eliminate the ambiguity by using:
du --apparent-size -ks

(From OE-Core rev: 92d2ea1a306354c6565a1b05b51b5719e481840f)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Nitin A. Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Backported to poky edison by Darren Hart.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-04-14 23:10:49 +01:00
Holger Hans Peter Freyther e005f8d60e openbsc: Fix the name of the MGCP MGW start script
The binary was renamed in the master branch, catch up.
2012-04-14 19:39:29 +08:00
Holger Hans Peter Freyther fab01cc657 osmocom: Upgrade libosmocore and openbsc to newer versions
Build newer versions of libosmocore and openbsc.
2012-04-13 03:21:01 +08:00
Holger Hans Peter Freyther 9d939cbe6c ortp: Move back to the savannah infrastructure
mirror.its.uidaho.edu is not reachable anymore and savannah appears
to be working again.
2012-04-07 21:57:42 +08:00
Holger Hans Peter Freyther aeca0842f3 osmocom-tcpdump: Correct the provides name in the start script 2012-04-06 21:00:44 +08:00
Elizabeth Flanagan 0fbd6a1615 poky.conf: Bumping SKD_VERSION
SDK_VERSION needs a bump for 1.1.1 release

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
2012-03-14 15:49:33 -07:00
Scott Rifenbark bda8a084f5 documentation: Updated copyright dates and release dates.
All six manuals updated.

(From yocto-docs rev: 753e3eb80b1fa6148e12f9eb93d23f4613b6be05)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-14 22:34:57 +00:00
Beth Flanagan 939ec1ca1e distro.conf: Bump for edison 1.1.1 release build
In preparation for edison 1.1.1, we need to bump DISTRO
and DISTRO_VERSION

Signed-off-by: Beth Flanagan <elizabeth.flanagan@intel.com>
2012-03-05 14:28:36 -08:00
Holger Hans Peter Freyther e08238ed3d osmocom-tcpdump: Add a tcpdump wrapper that logs to finite space
tcpdump can create a new log file every couple of bytes, it can also
be asked to limit the number of logfiles and wraps the counter back to
zero, and at least tcpdump 4.1 can also compress the log file with an
external script. Create a start script around this feature to log to
a given directory but not use more space than allowed to. The script
was created by Jan Luebbe and then modified.
2012-03-05 02:47:43 +08:00
Richard Purdie 69b307523c gnu-config: Only apply path transformations in the non-native/non-nativesdk case
The BUILD_ARCH != TARGET_ARCH check isn't a safe one to detect native builds
and doesn't cover the nativesdk case. This converts the recipe to use PN
instead which is more accurate and ensures the correct entries making it
into the correct packages.

(From OE-Core rev: 4a601314604e8428d9dace95c32a71a57eacaaf5)

(From OE-Core rev: 4066c7a3940df2740ad40b21e3ad517a9af20690)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:39:04 -08:00
Joshua Lock 6482c0e20d m4-native: explicitly set an empty BBCLASSEXTEND
The BBCLASSEXTEND from the included target results in an
m4-native-nativesdk which causes problems when running a
universe fetch.

(From OE-Core rev: 8bd88113ec7b962b570cdc90efa9f8b405730677)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:38:48 -08:00
Saul Wold ac9c62c907 eds-tools: Convert from BZR to GIT Repo
(From OE-Core rev: b83e4e1aeed115a2b495e54b0122ccf76b4d2eed)

(From OE-Core rev: b6b0fe6747453b57fe8cab666727a650639c3a6e)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:38:36 -08:00
Saul Wold 806c23ef2e libgpg-error: add BBCLASSEXTEND native for libgcrypts and gnutls-native
(From OE-Core rev: 3094a844f1ceb77153ac1a733623e6aca770b64b)

(From OE-Core rev: df48313f74e36c190cc2c25b6bdd98544acd2a28)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:38:22 -08:00
Saul Wold 4c496a970f libgcrypt: add BBCLASSEXTEND native for gnutls-native
(From OE-Core rev: 796b06e7bd4c336a5d256d54d1d16a1a9058144c)

(From OE-Core rev: d4803a9e6e661fe50da03ac04ab024cbe84a5541)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:38:09 -08:00
Richard Purdie fa6eb32a5a binutils-cross-canadian: Clear BBCLASSEXTEND as a native version of this recipe makes no sense
(From OE-Core rev: 5980cd6af7b5260558cb234288a426c091b5de2a)

(From OE-Core rev: 3611bbe4eb7b851c4d2275e9507785d734651777)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-04 05:37:44 -08:00
Joshua Lock eaec7e9624 sudo: backport patch to address CVE 2012-0809
This is a format string vulnerability "that can be used to crash
sudo or potentially allow an unauthorized user to elevate privileges."

(From OE-Core rev: 286cdd5db60b4f668e75cd9e05efb97acb08b7a6)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-03-01 15:59:58 +00:00
Wenzong Fan e6ea83fece task-sdk-host-nativesdk: add autotools nativesdk to meta-toolchain
Add automake-nativesdk and autoconf-nativesdk to meta-toolchain for
fixing the configure issue:
    WARNING: unrecognized options: --with-libtool-sysroot

This will allow user to run 'autoreconf' under their projects and
process the libtool m4 macros correctly.

[YOCTO #1603]

(From OE-Core rev: d1aabea25aa7ac46a7693acb52ccfe465c63f9bf)

(From OE-Core rev: 660f7ea484d503a49fc8bdf870398ae346304b05)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:56:28 +00:00
Nitin A Kamble 613e985811 autoconf: fix nativesdk rdepends
Fixes this build error:

| error: Failed dependencies:
| 	m4 is needed by autoconf-nativesdk-2.68-r4.x86_64
| 	gnu-config is needed by autoconf-nativesdk-2.68-r4.x86_64
NOTE: package meta-toolchain-1.0-r6: task do_populate_sdk: Failed
ERROR: Task 8 (.../meta/recipes-core/meta/meta-toolchain.bb,
do_populate_sdk) failed with exit code '1'

(From OE-Core rev: df8d88e864fb6bdecf5c82b25c0252c3d54157ad)

(From OE-Core rev: )

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:56:08 +00:00
Wenzong Fan b900d54f57 autoconf: Extend to provide nativesdk recipe
As the same reason with automake, extend autoconf to provide
nativesdk recipe too.

This patch was only used for autoconf that running on target:
    * path_prog_fixes.patch: replace '@PERL@' with '@bindir@/env perl'

It's unavailable for autoconf-native and autoconf-nativesdk, so
exclude it for those two recipes.

(From OE-Core rev: a16cf1b67f6559b182e6bb31abc1371162b04428)

(From OE-Core rev: 0b30e122e40472f5f1609cd9a513e6c4d198ac35)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:55:58 +00:00
Wenzong Fan 83e5279d62 automake: Extend to provide nativesdk recipe
We will provide autotools nativesdk in meta-tookchain for reconfigure
any autotools supported projects, as a part of the plan we should extend
their recipes first.

(From OE-Core rev: 2074285e84267f9f929ed6424f35cc4b2a00c335)

(From OE-Core rev: 4450aa5f0f757a3694db6123f6afe57a833ae986)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:55:49 +00:00
Wenzong Fan b36cde2308 m4: Extend to provide nativesdk recipe
We need to provide autoconf-natviesdk in meta-toolchain, the
m4-nativesdk is required by it.

Both extend the m4 recipes for GPLv2 and GPLv3.

(From OE-Core rev: 3e0a0db3559ee9b15a99a95dd3b0c343dca4b2ec)

(From OE-Core rev: 139f0171432eddf67039dde3bfad402cba3cc1a6)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:55:41 +00:00
Wenzong Fan c1a2249c96 gnu-config: Extend to provide nativesdk recipe
We need to provide autoconf-natviesdk in meta-toolchain, the
gnu-config-nativesdk is required by it.

(From OE-Core rev: 5e134b60773fa948c586dae777a6e75dce29d27d)

(From OE-Core rev: 378b9b5a9c8cda30c13bb1681fa9f0b02ef95655)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-28 14:55:32 +00:00
Joshua Lock e3afb1ebc8 linux-tools: don't build perf when GPLv3 in INCOMPATIBLE_LICENSE
As binutils is required by perf to build and is GPLv3 licensed adding
GPLv3 to INCOMPATIBLE_LICENSE will cause linux-yocto to be skipped.

Long term we should look at moving perf to a separate recipe but as a
short term solution this patch will ensure that when GPLv3 is in
INCOMPATIBLE_LICENSE perf is not built and it's dependencies are not
added to build.

Fixes [YOCTO #1879]

(From OE-Core rev: ce61f9031b54067bffa304dab90c31278631dcdf)

(From OE-Core rev: 8c1a2fa)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-24 17:39:59 +00:00
Saul Wold 686345f1d0 ed: Fix EXTRA_OECONF to ensure right compiler is found
(From OE-Core rev: b23ab297906d7241d737f7c5e81c674deca45e32)

(From OE-Core rev: f46d9423499c2474f935728df8906d8d7346dad7)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-24 17:21:58 +00:00
Saul Wold 7b15a9372c ed: remove unsupported option
(From OE-Core rev: 65fa6a9039043a59a236d28aacce3c424a734158)

(From OE-Core rev: 05349e9323df0094904b6f4aa159e79124301d6e)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-24 17:21:47 +00:00
Saul Wold b52792d84d ed: Add SRC_URI Checksums for GPLv2
(From OE-Core rev: c30c89c8dc449cf7642565f2e35c7b1a922fcc33)

(From OE-Core rev: 7ad2af875e1d1c2d17d66c9e59d6bb85471ad2eb)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-23 17:16:57 +00:00
Nitin A Kamble a684aa1df4 site/ix86-common: fix an error
Fixed this line
ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_int=1}

as this line
ac_cv_sizeof_unsigned_char=${ac_cv_sizeof_unsigned_char=1}

This issue was causing guile recipe to compile-fail for x86 target.

(From OE-Core rev: d71df3cc2ff2504d61078c578c0e73bbf53b6651)

(From OE-Core rev: 69ac1ad415634e125d9c366efc91353624225ad2)

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-23 17:16:47 +00:00
Holger Hans Peter Freyther 904300e21a openggsn_git: Upgrade to the latest git revision
This version includes a libgtp.pc that is required to compile the
osmo-sgsn.
2012-02-16 03:44:32 +08:00
Matthew McClintock 69a3fba2aa distutils.bbclass: override LDSHARED so we use the linker for this build and not the one used in sstate-cache
Without this fix, when packages are being built using distutils and
the python packages were deployed from sstate-cache is it possible
that the LD command will contain an invalid sysroot override.

We can fix this by always exported LDSHARED, which is the env var
that distutil looks for to override creating shared libraries.

(From OE-Core rev: 3f6b859a29ba7f570b9dae3b5bb7ab4bd7b8cee4)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-10 17:10:17 +00:00
Jessica Zhang c6ec5a0d9e Fix the issue that adt-installer tar ball is not regenerated if sstate is on, and other minor bug fixes
(From OE-Core rev: 61da952fdc2996c27c56234c36116a69a23a378d)

Signed-off-by: Jessica Zhang <jessica.zhang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Conflicts:

	meta/recipes-devtools/installer/adt-installer_1.0.bb
2012-02-10 17:10:08 +00:00
Lianhao Lu de68393270 adt-installer: install autoconf(/automake)-nativesdk
[YOCTO #1909]
Install autoconf-nativesdk and automake-nativesdk to host.

(From OE-Core rev: 0b3842f5c3c1587d25e70bc8223e2b144b9043cb)

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-10 17:10:03 +00:00
Richard Purdie 12e5797e51 fetch2/git: Add workaround for clone using alternates problem
To quote my report of this to the git mailing list:
"""

I have a problem with git clone commands using alternates failing by
mixing up different repositories. I have a situation where I could end
up with both:

/srv/mirrors/repo
/srv/mirrors/repo.git

as bare clones.

I then try cloning "repo" with alternates with the command:

$ git clone -s -n /srv/mirrors/repo /tmp/foo
Cloning into /tmp/foo...
done.

$ cat /tmp/foo/.git/objects/info/alternates
/srv/mirrors/repo.git/objects

Note how I'm now referencing repo.git, not repo. This doesn't work as
expected giving some very bizarre results when actually using the
repository.

I appreciate this is a rather bizarre corner case but its one that is
breaking the build system I work with. Ideally people would use a
consistent URL for the same repository but we have an example where they
haven't and this really shouldn't break like this.

Looking at the code, the cause seems to be

clone.c:get_repo_path():
        static char *suffix[] = { "/.git", ".git", "" };

since its looking in order for:
 repo/.git (fails)
 repo.git (suceeds, incorrect)
 repo (never looked at)

I'm not sure what would break if that order were to change, swapping the
last two options.

I can "force" the issue by running:

git clone -s -n /srv/mirrors/repo/ /tmp/foo

but this results in the slightly odd looking:

$ cat /tmp/foo/.git/objects/info/alternates

/srv/mirrors/repo//objects

which does at least work.
"""

This patch adds the trailing slash to ensure the correct repository is
referenced at the expense of some ugliness in the alternates file.

(Bitbake rev: d978e7b35550e3785c7c567ffe4c40a3c3947450)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-02-03 17:42:14 +00:00
Bruce Ashfield 6c65263f8d linux-yocto: bump kver to v3.0.18
Updating the kernel SRCREVs to pickup the stable 3.0.18 release.

(From OE-Core rev: b1a4d1a912af39dc3be7433a1e2ed4c48d5ffb93)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:49:49 +00:00
Joshua Lock 32f0a45c33 multilib.conf: add missing entry for shadow-sysroot
(From OE-Core rev: 31aff4c3db9ce985313ff9b4fc7fbe8015973749)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:49:48 +00:00
Jean-François Dagenais 726f3bce5a buildstats: tolerate absence of /proc/diskstats
In OpenVZ containers (and probably lx containers as well),
the diskstats entry is not even present. Use the "NoLogicalDrive"
introduced by Elizabeth Flanagan in such case.

This allows the bitbaking to occure within such containers.

(From OE-Core rev: 16e09b850dcb44cb1afe411439e40a4bae7e8002)

(From OE-Core rev: 84bd443d82d8022027180b6ef1f7b7cfc7d06420)

Signed-off-by: Jean-François Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:49:48 +00:00
Saul Wold 75f253d7d2 openssl-0.9.8: Update to 0.9.8s
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4108

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

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

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

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

[YOCTO #1904]

(From OE-Core rev: 980ba5e77438c3a22c295f56ffb71f1d290db50a)

(From OE-Core rev: 3e93af369d70d20a53bd7849a62b177b910e6a36)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:49:48 +00:00
Wolfgang Denk a5c04850e6 clutter-1.6: make build for armv4t
GCC will define __ARM_ARCH_4T__ when building with "-march=armv4t" so
we can check this to turn off the use of 'clz' instructions, which
otherwise would cause compile errors like "selected processor does
not support ARM mode `clz r3,r0'".

(From OE-Core rev: 6859e3fc34269620146d26eeecc9b93c3a9d7055)

Signed-off-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:51 +00:00
Joshua Lock cef4500611 linux-tools: add binutils to perf DEPENDS
We have witnessed non-deterministic failures of perf for some platforms
whilst looking for bfd.h, a header provided by binutils.

(From OE-Core rev: ab56f27d96cbd2c79ca16d12333687ca9720934c)

(From OE-Core rev: eb014a992e0f3e6ddb4eee8e1287d28ac2f09e00)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:51 +00:00
Saul Wold df2da07184 intltool: remove XML::Parser check
Add Patch to disable the XML::Parser check in the target
intltool.m4, this check will find the host (not native)
XML::Parser if it's installed possibly causing Host
contamination, but will also fail configuration if XML::Parser
is not installed on the host.

Since we know that XML::Parser is installed on the image, we don't
really need this check, so comment it out.

From RP in mail thread:
> If the recipe needs perl for
> some other reason than intltool, it needs perlnative but it if only
> needs perl for intltool, we shouldn't need the dependency. The .m4 macro
> checks are well intended but don't fit the way we use perl. I really
> don't want to end up in a position where intltool automatically means we
> have to add perlnative as a dependency and we've previously seen many
> problems related to that.

(From OE-Core rev: 264fb6c5a4875cd8969a24a9f0301ed916ab827b)

(From OE-Core rev: 085c76298891dc0b0e2207ef929569672c9cb254)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:51 +00:00
Matthew McClintock 77912d65c7 rpm_5.4.0.bb: Build rpm without xz
This fixes the following issue:

Log data follows:
| NOTE: Creating RPM package for perf-dbg
| NOTE: Creating RPM package for perf
| NOTE: Creating EMPTY RPM Package for kernel
| NOTE: Creating EMPTY RPM Package for kernel-3.0.9-00348-gec4b357
| NOTE: Creating RPM package for kernel-image-3.0.9-00348-gec4b357
| NOTE: Creating RPM package for kernel-dev
| NOTE: Creating RPM package for kernel-vmlinux
| NOTE: Not creating empty RPM package for kernel-misc
| NOTE: Creating RPM package for kernel-devicetree
| NOTE: Creating RPM package for kernel-module-libcrc32c
| NOTE: Creating RPM package for kernel-module-crc-itu-t
| NOTE: Creating RPM package for kernel-module-sctp
| NOTE: Creating RPM package for kernel-module-pcbc
| NOTE: Creating RPM package for kernel-module-crc32c
| NOTE: Creating RPM package for kernel-module-binfmt-misc
| NOTE: Creating RPM package for kernel-module-nfsd
| NOTE: Creating RPM package for kernel-module-exportfs
| NOTE: Creating RPM package for kernel-module-msdos
| NOTE: Creating RPM package for kernel-module-nls-utf8
| NOTE: Creating RPM package for kernel-module-udf
| NOTE: Creating RPM package for kernel-module-isofs
| NOTE: Creating RPM package for kernel-module-usbhid
| NOTE: Creating RPM package for kernel-module-scsi-wait-scan
| NOTE: Creating EMPTY RPM Package for kernel-modules
| /local/home/mattsm/git/fsl-local-sdk/build_p4080ds_release/tmp/sysroots/x86_64-linux/usr/bin/rpmbuild.real: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
| ERROR: Function 'BUILDSPEC' failed (see /local/home/mattsm/git/fsl-local-sdk/build_p4080ds_release/tmp/work/p4080ds-fsl-linux/linux-qoriq-sdk-3.0.6-r2/temp/log.do_package_write_rpm.18943 for further information)

(From OE-Core rev: 1f55b31bdc8cf1da04ef29f4e44c1be6c0286ee2)

(From OE-Core rev: 3b0239ab2c36d7227ec4e81d2aaf93c273cdc292)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Saul Wold 878425f147 coreutils: ensure --color works so DEPEND on libcap
[YOCTO #1860]

(From OE-Core rev: 6abf6054ac5a464cfa6f1040bb166765558a1eb8)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Richard Purdie fa9ad15e41 which: Disable iberty since its not listed in DEPENDS
(From OE-Core rev: 4d6420d0aa1d6e8aecc8ec0526144f9c4396a822)

(From OE-Core rev: 778330071bcab83baff8ec8f22367f5dd0a71d35)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Nitin A Kamble 961f75d11b site/x86_64-linux: add cvs config variables
configure of cvs packages was failing on the meta-toolchain for a x86_64 target.

Configure error reported:
checking whether printf supports %p... configure: error: cannot run test program while cross compiling

This fixes [YOCTO #1781]

(From OE-Core rev: 061818adbea1af9e98fe0fdf81b21f1e7f210c00)

(From OE-Core rev: 5e0e0cf5b9d380120187d368683e9f95c1b8f6d1)

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Matthew McClintock 60c5ef3508 Nothing uses USERNAME, remove it - can cause sstate-cache conflicts
USER is the correct variable to use, also this can affect sstate
cache as well.

(From OE-Core rev: 898bf0294d01172b0990d218ecc5fecdba962711)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Matthew McClintock e5e7a913c2 Remove EGLIBPARALLELISM from deps for EXTRA_OEMAKE
Without this simply changing the number of threads via
PARALLEL_MAKE can invalidate sstate-cache

(From OE-Core rev: b2411e12f9ea32012af20ecee1e09d95db129b75)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:50 +00:00
Richard Purdie 165e39a0bb bitbake.conf Exclude MACHINE from MACHINEOVERRIDE variable dependencies
(From OE-Core rev: 362512b83775ad7020e5870a594f0e7ca9ef83ba)

(From OE-Core rev: 3ef7e82a8b0121e2b7200179176e39ef4315971d)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:49 +00:00
Khem Raj 09d5966e46 gcc-4.6: Fix gcc ICE on qt4-x11-free/armv7-a
Backport fix for PR 47551 fixes the ICE seen on armv7-a/qt4-x11-free
Bump up SRCREV past gcc 4.6.2 release

(From OE-Core rev: dd2fdf9f5a3923c37e4ea2e46e347bb0657c2f5b)

(From OE-Core rev: 320f6b71e502d65421a01a2f280c9e2c8f046619)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:49 +00:00
Richard Purdie 0bd433ebf5 opkg: Fix installation order in feeds with mutiple providers of packages
If two packages were available of differing priority, this would confuse
opkg and it was ignoring the dependency in the new dependency ordering
code. This changes it not to ignore these cases by setting the badly
named 'quiet' parameter accordingly.

(From OE-Core rev: c38693f78c968ab5f4bb557c20d1c8c55393ed6b)

(From OE-Core rev: 4c75318b75c4776cc469cc2c6511596bc7befbb4)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:49 +00:00
Richard Purdie c2e003ecd5 populate_*.bbclass: Correct INSTALL variable name after recent multilib changes
(From OE-Core rev: 379c77d1516fe8fdbd1cd7063f709b5266872b03)

(From OE-Core rev: a300e9e45f4570f0aa47fb3fabcee95433ffad99)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:49 +00:00
Richard Purdie 9f51e226dc populate_*.bbclass: Drop pointless fakeroot attribute (fakeroot is at the task level)
(From OE-Core rev: 2cac20439d4eb0b3a21ce37e2fa670941e6356c4)

(From OE-Core rev: f070a2bf7e689345ea6d9386f7298bf5d36d576f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:48 +00:00
Richard Purdie 681499ebfe scripts/runqemu-ifup: Ensure netmask is set correctly
Without this the command will add a route for the subnet 192.168.7.0 which
means multiple qemu instances can't operate correctly since all but the last
one will be masked out.

(From OE-Core rev: 9e00d6b343120496ec0dd72240c7b04e0a8b7eaa)

(From OE-Core rev: f5bcd56dcca7daad6aa6b4371d4e331d8ffd11eb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:48 +00:00
Richard Purdie 5d96094939 opkg: Drop the offlineroot_varname patch
This break things for on target opkg usage since $D must remain
unset there.

(From OE-Core rev: 746ae269a475857ae57095b1fd164fe195b3d051)

(From OE-Core rev: aa632292cc55b997a5b808b6c4a70ce33a3b9e7e)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:48 +00:00
Richard Purdie 10d9e0805e opkg: Add logic to detect and creak circular dependencies
This addresses some of the concerns about the previous opkg changes
allowing it to break out of circular dependency loops with just a notice
in the logs rather than effectively going OOM.

(From OE-Core rev: 5a2b67b8faad3dd5417ba89d8e82ca564753ccc9)

(From OE-Core rev: 29f77f865434cc956e6bbccaee81ff458492ec46)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:48 +00:00
Richard Purdie c1c6613ddd opkg: Update svn 625 -> 633 and fix preinst issues
There is a major issue with opkg images at the moment as preinst
functions are not being executed before their dependencies are installed
and this is leading to corruption of images containing avahi/dbus in
particular.

There are various changes in upstream opkg in the last 8 revisions which
make changes in this area but sadly these aren't enough to get things
working for us. I've updated to the latest svn revision with this patch
since it makes sense to pull in those changes first and then supplement
them with the attached patches.

There is a full description of the patches in the patch headers but in
summary they:

a) Ensure preinst functions execute with their dependencies installed.
   This is a pretty invasive change as it changes the package install
   ordering in general.
b) Ensure opkg sets $D, not $PKG_ROOT which we don't use
c) Change opkg to allow execution of postinstall functions which fail
   resulting in execution on the target device as rootfs_ipk.bbclass
   currently does manually.

The remaining changes interface this with the rest of the OE build
infrastructure, adding in the option to tell opkg to run the preinst and
postinst functions, ensure the correct environment is present for the
postinst scripts and removing the now unneeded rootfs_ipk class code
which opkg now does itself.

[YOCTO #1711]

(From OE-Core rev: 2feba313c991170747381c7cf821a45c2cd04632)

(From OE-Core rev: b7e2eff8c18bc59605fb711ac4540985c71f155a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:48 +00:00
Richard Purdie 5db4eaac2d update-alternatives: Various fixes
dpkg-native's update-alternatives is broken for offline work so
don't install it.

Also list update-alternatives in the multiprovider whitelist to
avoid unwanted multiple provider warnings when multiple package
backends are enabled.

(From OE-Core rev: 300336fc4a310ed16a14ad041744708d54aae189)

(From OE-Core rev: c90b1faa34e908c7f63e1a64027873858e6d7e8a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:47 +00:00
Richard Purdie f99f36f637 package_rpm: Set _tmppath to avoid races over tmp files
Occasionally we keep seeing "unable to open temp file" messages during
do_package_write_rpm tasks. This appears to happen when multiple
processes are writing rpm files and is likely due to using the
shared system temp directory. This patch changes the tmp path
to the package work directory meaning conflicts should become
a non-issue.

(From OE-Core rev: b2ef543284c8c8d0d3badb2e1bcadad1106982d2)

(From OE-Core rev: 018442ed2cd251f85212dfa1d03c0b24a0750bfa)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:47 +00:00
Jiajun Xu 7705d9a8cc sanitytest: remove rpm/zypper tests if PACKAGE_CLASSES does not set package_rpm
If PACKAGE_CLASSES does not set package_rpm as the first item, the root filesystem
will not be generated based on rpm. We need remove rpm/zypper tests against
non-rpm filesystem.

[YOCTO #1757]

(From OE-Core rev: 43adb8dcf4461b68a7ce0ba9d8acdb2012a70416)

(From OE-Core rev: f541517be97e27951157e1dd10256e132c31ab1f)

Signed-off-by: Jiajun Xu <jiajun.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:47 +00:00
Richard Purdie bcec98bf1c package.bbclass: Ensure paths to rpmmarcos and rpmpopt are set
If rpm-native was built in an alternative location, it may not relocate correctly
unless the rpmpopt and macros paths are explicitly specified.

This fixes errors seen on the Yocto autobuilder where pkgconfig
"provides" entries could disappear leading to image dependency failures.

(From OE-Core rev: fb01bd81197057e62106aac966f9ebc4c5054f97)

(From OE-Core rev: 15f50ab3ee454dc3510801d61bb09bf37d78d1af)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:47 +00:00
Matthew McClintock 0d9809c4ec populate_sdk.bbclass: remap packages when generating sdk tarball
This fixes the issue below:

| Generating solve db for /local/home/mattsm/git/poky/build_p4080ds_release/tmp/deploy/rpm/all...
|    total:               1      0.000000 MB      0.093784 secs
|    fingerprint:         9      0.000012 MB      0.000252 secs
|    install:             3      0.000000 MB      0.039092 secs
|    dbadd:               3      0.000000 MB      0.034837 secs
|    dbget:              12      0.000000 MB      0.000062 secs
|    dbput:               3      0.009532 MB      0.002731 secs
|    readhdr:            31      0.019160 MB      0.000084 secs
|    hdrload:            15      0.027924 MB      0.000116 secs
|    hdrget:            494      0.000000 MB      0.000691 secs
| Processing task-core-standalone-sdk-target...
| Processing glib-2.0...
| Unable to find package glib-2.0 (glib-2.0)!
| ERROR: Function 'do_populate_sdk' failed (see /local/home/mattsm/git/poky/build_p4080ds_release/tmp/work/ppce500mc-fsl-linux/fsl-toolchain-1.0-r6/temp/log.do_populate_sdk.16975 for further information)

If you have:

TOOLCHAIN_TARGET_TASK += "glib-2.0"

The package name was not getting remapped correctly for the do_populate_sdk
case.

(From OE-Core rev: 0b803ac3627c238aa7d19a23b7621f55779f2557)

(From OE-Core rev: e1a07a5fcba93b3ab127c7c6588cab5799a5df45)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:46 +00:00
Saul Wold dcf64630f8 bitbake.conf: remove texinfo-native from ASSUME_PROVIDED
We need to build texinfo-native to get and install the makedoc tool

[YOCTO #1664]

(From OE-Core rev: 8899f4840787ef043d952f8ea2ce5d78e5cc41ab)

(From OE-Core rev: 8e802c0ed491967cd254dce1555a960382a79247)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:46 +00:00
Saul Wold fa610f7f20 texinfo: fix compile failure due target makedoc binary being used
Need to have the texinfo-native build and install a host sysroot makedoc
binary and then patch the target build to use this binary. This requires
that we don't ASSUME_PROVIDED texinfo-native any longer since we need to
install this makedoc tool which is not part of the normal distrubtion.

[YOCTO #1664]

(From OE-Core rev: 9fa98de54a73465f06484ba863eccf1e07cc1e2a)

(From OE-Core rev: 007bbb23808cc5b036829915e3dfa04f590a05d8)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:46 +00:00
Paul Eggleton d97ad36d90 qemu: for native, do not fail if kvm is unavailable
When building qemu-native, if the linux kvm header is unavailable (as
it is on CentOS 5.x 32-bit) then do not pass the --enable-kvm switch to
the configure script, thus avoiding failed do_configure.

(From OE-Core rev: 8c21c71f005b601f58925e9912f2cf44127e291d)

(From OE-Core rev: 44d9e208c97ec1e3c5ba0a8dc6c10cef12dc270d)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:46 +00:00
Paul Eggleton de7377a170 scripts/bitbake: add a version >= 2.6 check
Unfortunately we now have code in BitBake which is parsed before the
current version check and is incompatible with Python < 2.6. Rather than
fixing this and being eternally vigilant for >= 2.6 feature usage, just
add a version check to the wrapper script.

(From OE-Core rev: 9b8a48efa3b80fea34efa51de44d10ff2b1e3193)

(From OE-Core rev: c3ba7e8f7aca8b49739b3b92aec723c5f3375bc0)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:45 +00:00
Paul Eggleton c471ec56b4 scripts/runqemu: show an error if /dev/net/tun is unusable
If /dev/net/tun is either not present or is not writable by the
user, then show an appropriate error message. (QEMU needs access to this
device in order to enable networking; it may be missing if it is not
enabled or loaded into the kernel, and some distributions such as CentOS
5.x set restrictive permissions upon it.)

(From OE-Core rev: a00b94900d437828f25debce1c30ffcc0bbf29e9)

(From OE-Core rev: b66fa6238a8f9c0972a60932941997517826ff03)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:45 +00:00
Mei Lei 9d55534cc7 rpm: Flush old logs by change the DB_CONFIG
Fixes [YOCTO #1174]

Rpm logs will grow indefinitely, so change the config to flush those old logs.

(From OE-Core rev: e2c4dff079722f256ddcab9630b5b3f8f6421cc9)

(From OE-Core rev: f235c7a320c401fea70a578186c5cf80dd597fcd)

Signed-off-by: Mei Lei <lei.mei@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:45 +00:00
Richard Purdie 54f4e9b66c package.bbclass: Ensure we tell rpmdeps where to find its magic file
Without this, if rpmddeps came from a sstate package which was relocated
it might not find its magic file and if that happens, requires/provides
in packages could get corrupted. This leads to failures at rootfs time
during builds with messages like:

libdbus-1.so.3 is needed by libdbus-glib-1-2-0.92-r1.armv5te

since the provides would be missing in the dbus package.

(From OE-Core rev: abe2a948905a997314c61a8fcd35e2b42a3f4408)

(From OE-Core rev: 5ee145ebbb32824e3870b6dd689ce2b3f9bf3f17)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:45 +00:00
Zhai Edwin 3e783002b3 matchbox-wm: Fix variable type in _NET_WORKAREA setting
According to XChangeProperty doc, array of "long" should be used when format is
32. Wrong _NET_WORKAREA parameter caused blank screen in matchbox-desktop on 64
bit platform.

[YOCTO #1689] got fixed.

(From OE-Core rev: 381c7857a5b303bf9eadd7fffc39d17a2b8e31f2)

(From OE-Core rev: 869601da9aa43d77564c37d291d9072b9896d3e6)

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:44 +00:00
Martin Jansa 935678cbe1 bitbake.conf: add default PRINC 0 to be able to increment it
(From OE-Core rev: 656793c706d84460f397b10ceb23ebb721ed3960)

(From OE-Core rev: 32f0ad32d901ae5a97d912d8d36d4d9a2b502919)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:44 +00:00
Matthew McClintock ee75b5020b openjade-native_1.3.2.bb: remove CONFIGUREOPTS as vardep for do_configure
This variable was being expanded immediately and pulling in
paths to the variable dependecies which causes it's sstate-cache
to never be reused

(From OE-Core rev: ddb8d3de34f809b9c72eb3a2223a74f75eff7911)

(From OE-Core rev: 8f616810b868a30fc01550c017f9fc14220ae7d8)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:44 +00:00
Richard Purdie 5f21a24580 dpkg-native: Fix perl path
The path to the native perl was incorrect leading to rootfs failures. This
patch corrects that problem.

(From OE-Core rev: 044324465bd54d53ae768f3c1e7468ae0e0c6200)

(From OE-Core rev: 8fa40eb1c2a32782b8a74bee70fa81b2c3e5cbaf)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:44 +00:00
Richard Purdie 100002e4c6 bitbake.conf: We only care about the absolute value of baselib
The value of baselib can be constructed in several different ways
and from a sstate perspective we don't care how it was made up,
we only care what the final value is. This uses the new functionality
in bitbake to ensure we only include the value of baselib and not
any intermediate dependencies.

[YOCTO #1583]

(From OE-Core rev: c38567894ebc31ac977f2bc89a076d0380bddcf8)

(From OE-Core rev: 8b70cfe7a1768b8bf1e5b7e390276518e16f14af)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:44 +00:00
Richard Purdie 71824019fb eglibc-initial: Ensure symlinks point to the correct location when built from sstate cache
If the sstate files are installed into a sysroot from the sstate cache,
the directory to the main sysroot can change and the symlinks aren't
adjusted to account for this. This is a problem specific to the toolchain
bootstrap process. This patch adds up a function to recreate the
symlinks, hence ensuring they always point at the correct location.

(From OE-Core rev: ad0baa7d2f33a865011e0c6afe29f22aa1beea32)

(From OE-Core rev: bc8a384c49c60feab9d01f8277e92ac0603c8f93)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:43 +00:00
Matthew McClintock 3400b3d2df patch.bbclass: Add PATCHRESOLVE to excluded vars for generating sstate-cache
The method of resolving the patch should not effect the sstate-cache
signature.

(From OE-Core rev: b64cbe0b511de8d8943ce34cbb4901239d9f0cb0)

(From OE-Core rev: 896bd7d1442dcd3f080dc741a72f50ab95d7c38f)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:43 +00:00
Richard Purdie 745d83f968 sstate.bbclass: Ensure we expand stamp-extra-info
Without this change we can end up looking for <stamp>.${MACHINE}
instead of the expected expanded value.

(From OE-Core rev: 9f743b5033177216fe0e1d3e43ba831f356df08e)

(From OE-Core rev: de9f47b09d5434642ba925182ae21a8e77e7e429)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:43 +00:00
Richard Purdie 340a680de2 sstate: No need to spew out a debug message per file, summarise instead
(From OE-Core rev: c7b02c6e80819e30a0818282ab8d960243a2d0e8)

(From OE-Core rev: 6df929c8b58daa19423e5994bbf8bb68c912707f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:43 +00:00
Matthew McClintock 3048bd79b3 sudo_1.8.1p2.bb: Pull patch from upstream to fix parallel build issue
(From OE-Core rev: 255588da1834b45325cf6677906aef2687a3b5f6)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:42 +00:00
Michael Brown ef37926f31 gcc-4.6: fix toolchain build for SH4
(From OE-Core rev: da7bf75bcdd5759a0f551dcb7a0326aa2f40921c)

(From OE-Core rev: 3c9fd383965f883129cf35d0e307d3bbbd5d4908)

Signed-off-by: Michael Brown <Michael_E_Brown@dell.com>

Port patch from base openembedded. Since 4.6 already has fixes for config.gcc,
the fix only requires a one line change to gcc-cross4.inc.

The patch was imported from the OpenEmbedded git server
(git://git.openembedded.org/openembedded) as of commit id
3aa8afe97e9cf1340feb9c4442a6ed88b7e32c96.

gcc-4.5: Fix toolchain builds for SH4/SH3

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:42 +00:00
Richard Purdie 4c30bcfbfe libconvert-asn1-perl/libtimedate-perl: Convert to use allarch
Both these recipes generate architecture independent packages.
They can safely use the allarch class to ensure they really
are indepentent from the target compiler and so forth and
hence ensure sstate packages with good dependencies.

[YOCTO #1075]

(From OE-Core rev: 2856d3f6aca0c20acd40f7f8970ec8590e4889a8)

(From OE-Core rev: 676a5c44fb621ae428f8ac1fc466469914cbc864)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:42 +00:00
Phil Blundell 709ad80662 libnss-mdns: avoid race condition in postinst
Writing to "/tmp/nsswitch.conf" leads to a race condition if two
copies of the postinst are running simultaneously.  Fix this by
modifying /etc/nsswitch.conf in place using sed -i.  Also make the
same change to the prerm for consistency although the race will not
occur here in practice.

(From OE-Core rev: 689884653938b98899fb3ba791221fdbe2f40e7f)

(From OE-Core rev: 2a2741c12196c34c5e6127488a8eeec7118b2952)

Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:42 +00:00
Martin Jansa 08a834a08a alsa-lib: use PKGSUFFIX for every package to resolve multiple runtime providers from target and nativesdk
(From OE-Core rev: 60738953f6fee24de447cd0f9cf81cce6f8966a5)

(From OE-Core rev: 4c2a9e410c46fbf52f3d64767baf06c7146d001e)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:41 +00:00
Martin Jansa 6c3dd24e59 webkit-gtk: force arm mode to work around binutils segfault
* this is just work around, would be better to fix in toolchain

(From OE-Core rev: 2df59dad90f31aa48113ad8afe1af084b71a6a2c)

(From OE-Core rev: 3648cf8f02601ac57787f81cb199677434970b34)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:41 +00:00
Martin Jansa 66d6c031b0 aspell: force ARM mode
* this is just work around for ICE, better fix would be to fix gcc
| ./common/fstream.hpp:23:9: note: the mangling of 'va_list' has changed in GCC 4.4
| modules/speller/default/typo_editdist.cpp: In function 'short int aspeller::typo_edit_distance(acommon::ParmString, acommon::ParmString, const aspeller::TypoEditDistanceInfo&)':
| modules/speller/default/typo_editdist.cpp:77:3: internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5937
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://gcc.gnu.org/bugs.html> for instructions.
| make[1]: *** [modules/speller/default/typo_editdist.lo] Error 1
| make[1]: *** Waiting for unfinished jobs....
| make[1]: Leaving directory `/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/aspell-0.60.6.1-r0/aspell-0.60.6.1'

(From OE-Core rev: eff532ea13a270c0e4ffaf4ab059403d612a3197)

(From OE-Core rev: 9fa76ebe080ec729af429cf2a77b4aba814c2b61)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:41 +00:00
Martin Jansa 957882caef pulseaudio-0.9.23: force ARM mode
* this is just work around, should be tested again after upgrade to
  pulseaudio-1.1
* otherwise build for armv4t (om-gta02) fails with this:
| /bin/sh ../arm-oe-linux-gnueabi-libtool  --tag=CC   --mode=compile
arm-oe-linux-gnueabi-gcc  -march=armv4t -mthumb -mthumb-interwork
-mtune=arm920t --sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -std=gnu99
-DHAVE_CONFIG_H -I. -I..    -I../src -I../src -I../src/modules
-I../src/modules -I../src/modules/rtp -I../src/modules/rtp
-I../src/modules/gconf -I../src/modules/gconf -I../src/modules/bluetooth
-I../src/modules/bluetooth -I../src/modules/oss -I../src/modules/oss
-I../src/modules/alsa -I../src/modules/alsa -I../src/modules/raop
-I../src/modules/raop -I../src/modules/x11 -I../src/modules/x11
-I../src/modules/jack -I../src/modules/jack -I../src/modules/echo-cancel
-I../src/modules/echo-cancel -pthread -D_POSIX_PTHREAD_SEMANTICS
-DPA_BUILDDIR=\"/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23/src\"
-DPA_DLSEARCHPATH=\"/usr/lib/pulse-0.9.23/modules\"
-DPA_DEFAULT_CONFIG_DIR=\"/etc/pulse\"
-DPA_BINARY=\"/usr/bin/pulseaudio\"
-DPA_SYSTEM_RUNTIME_PATH=\"/var/run/pulse\"
-DPA_SYSTEM_CONFIG_PATH=\"/var/lib/pulse\"
-DPA_SYSTEM_STATE_PATH=\"/var/lib/pulse\" -DAO_REQUIRE_CAS
-DPULSE_LOCALEDIR=\"/usr/share/locale\"
-DPA_MACHINE_ID=\"/var/lib/dbus/machine-id\"
-DPA_ALSA_PATHS_DIR=\"/usr/share/pulseaudio/alsa-mixer/paths\"
-DPA_ALSA_PROFILE_SETS_DIR=\"/usr/share/pulseaudio/alsa-mixer/profile-sets\"
-O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wextra -pipe
-Wno-long-long -Winline -Wvla -Wno-overlength-strings
-Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op
-Wsign-compare -Wformat-security -Wmissing-include-dirs
-Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations
-Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math
-Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -c -o
libbluetooth_sbc_la-sbc.lo `test -f 'modules/bluetooth/sbc.c' || echo
'./'`modules/bluetooth/sbc.ci

| arm-oe-linux-gnueabi-libtool: compile:  arm-oe-linux-gnueabi-gcc
-march=armv4t -mthumb -mthumb-interwork -mtune=arm920t
--sysroot=/OE/shr-core/tmp/sysroots/om-gta02 -std=gnu99 -DHAVE_CONFIG_H
-I. -I.. -I../src -I../src -I../src/modules -I../src/modules
-I../src/modules/rtp -I../src/modules/rtp -I../src/modules/gconf
-I../src/modules/gconf -I../src/modules/bluetooth
-I../src/modules/bluetooth -I../src/modules/oss -I../src/modules/oss
-I../src/modules/alsa -I../src/modules/alsa -I../src/modules/raop
-I../src/modules/raop -I../src/modules/x11 -I../src/modules/x11
-I../src/modules/jack -I../src/modules/jack -I../src/modules/echo-cancel
-I../src/modules/echo-cancel -pthread -D_POSIX_PTHREAD_SEMANTICS
-DPA_BUILDDIR=\"/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23/src\"
-DPA_DLSEARCHPATH=\"/usr/lib/pulse-0.9.23/modules\"
-DPA_DEFAULT_CONFIG_DIR=\"/etc/pulse\"
-DPA_BINARY=\"/usr/bin/pulseaudio\"
-DPA_SYSTEM_RUNTIME_PATH=\"/var/run/pulse\"
-DPA_SYSTEM_CONFIG_PATH=\"/var/lib/pulse\"
-DPA_SYSTEM_STATE_PATH=\"/var/lib/pulse\" -DAO_REQUIRE_CAS
-DPULSE_LOCALEDIR=\"/usr/share/locale\"
-DPA_MACHINE_ID=\"/var/lib/dbus/machine-id\"
-DPA_ALSA_PATHS_DIR=\"/usr/share/pulseaudio/alsa-mixer/paths\"
-DPA_ALSA_PROFILE_SETS_DIR=\"/usr/share/pulseaudio/alsa-mixer/profile-sets\"
-O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wextra -pipe
-Wno-long-long -Winline -Wvla -Wno-overlength-strings
-Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op
-Wsign-compare -Wformat-security -Wmissing-include-dirs
-Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations
-Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align
-Wstrict-aliasing=2 -Wwrite-strings -Wno-unused-parameter -ffast-math
-Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -c

modules/bluetooth/sbc.c  -fPIC -DPIC -o .libs/libbluetooth_sbc_la-sbc.oi
| modules/bluetooth/sbc.c: In function 'sbc_synthesize_four':
| modules/bluetooth/sbc.c:553:18: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:553:18: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:565:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c: In function 'sbc_synthesize_eight':
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:595:29: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: declaration of 'tmp' shadows a previous local [-Wshadow]
| modules/bluetooth/sbc.c:611:40: warning: shadowed declaration is here [-Wshadow]
| {standard input}: Assembler messages:
| {standard input}:6997: Error: selected processor does not support Thumb mode `mla r3,r0,ip,r3'
| {standard input}:7012: Error: selected processor does not support Thumb mode `mla r3,r1,ip,r3'
| {standard input}:7026: Error: selected processor does not support Thumb mode `mla r3,ip,r0,r3'
| {standard input}:7215: Error: selected processor does not support Thumb mode `mla r3,r7,r0,r3'
| {standard input}:7230: Error: selected processor does not support Thumb mode `mla r3,r7,r0,r3'
| {standard input}:7241: Error: selected processor does not support Thumb mode `mla r3,r0,r7,r3'
| {standard input}:7256: Error: selected processor does not support Thumb mode `mla r3,r0,r7,r3'
| {standard input}:7267: Error: selected processor does not support Thumb mode `mla r3,r7,r0,r3'
| {standard input}:7287: Error: selected processor does not support Thumb mode `mla r3,r7,r6,r3'
| {standard input}:7301: Error: selected processor does not support Thumb mode `mla r3,r6,r5,r3'
| {standard input}:7319: Error: selected processor does not support Thumb mode `mla r3,r0,r5,r3'
| {standard input}:7327: Error: selected processor does not support Thumb mode `mla r3,r1,r0,r3'
| {standard input}:7594: Error: selected processor does not support Thumb mode `mla r3,r5,r6,r3'
| {standard input}:7604: Error: selected processor does not support Thumb mode `mla r3,r5,r6,r3'
| {standard input}:7614: Error: selected processor does not support Thumb mode `mla r3,r5,r6,r3'
| {standard input}:7624: Error: selected processor does not support Thumb mode `mla r3,r5,r6,r3'
| {standard input}:7634: Error: selected processor does not support Thumb mode `mla r3,r5,r6,r3'
| {standard input}:7647: Error: selected processor does not support Thumb mode `mla r3,r2,r5,r3'
| {standard input}:7657: Error: selected processor does not support Thumb mode `mla r3,r2,r5,r3'
| {standard input}:7815: Error: selected processor does not support Thumb mode `mla r3,r9,r7,r3'
| {standard input}:7837: Error: selected processor does not support Thumb mode `mla r3,r9,r0,r3'
| {standard input}:7853: Error: selected processor does not support Thumb mode `mla r3,r9,r0,r3'
| {standard input}:7875: Error: selected processor does not support Thumb mode `mla r3,r9,r7,r3'
| {standard input}:7891: Error: selected processor does not support Thumb mode `mla r3,r9,r7,r3'
| {standard input}:7908: Error: selected processor does not support Thumb mode `mla r3,r0,r6,r3'
| {standard input}:7931: Error: selected processor does not support Thumb mode `mla r3,r6,r5,r3'
| {standard input}:7952: Error: selected processor does not support Thumb mode `mla r3,r0,r5,r3'
| {standard input}:7960: Error: selected processor does not support Thumb mode `mla r3,r2,r0,r3'
| make[4]: *** [libbluetooth_sbc_la-sbc.lo] Error 1
| make[4]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23/src'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23/src'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23/src'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/pulseaudio-0.9.23'
| make: *** [all] Error 2
| + die 'oe_runmake failed'
| + bbfatal 'oe_runmake failed'
| + echo 'ERROR: oe_runmake failed'
| ERROR: oe_runmake failed
| + exit 1
| ERROR: Function 'do_compile' failed (see /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/pulseaudio-0.9.23-r6/temp/log.do_compile.3404 for further information)

(From OE-Core rev: 31a20d50124344dc708ade282677b2c7dda171b0)

(From OE-Core rev: 4eaf22dc67c3de9025bae3f24837f569aba91fff)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:41 +00:00
Khem Raj 8781450256 pulseaudio: inherit perlnative
manpage generatition uses xmltoman utility
which inturn uses xml-parser. So we add
libxml-parser-perl-native to DEPENDS and also
inherit perlnative so it does not use the one
from build host

(From OE-Core rev: 51f6a683ec1d740adf09d808671c7098dc3f83e2)

(From OE-Core rev: 1c5cdc8ee9edeafe86ef0fd955ee067ab67c7aa9)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:41 +00:00
Martin Jansa 9d23f215a0 libatomics-ops: force ARM mode
* otherwise ie spitz (armv5te) build fails with:
| make[3]: Entering directory `/OE/shr-core/tmp/work/armv5te-oe-linux-gnueabi/libatomics-ops-1.2-r5/libatomic_ops-1.2/src'
| arm-oe-linux-gnueabi-gcc  -march=armv5te  -mthumb -mthumb-interwork  -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I.    -fPIC -O
2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops.c
| arm-oe-linux-gnueabi-gcc  -march=armv5te  -mthumb -mthumb-interwork  -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I.    -fPIC -O
2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops_stack.c
| arm-oe-linux-gnueabi-gcc  -march=armv5te  -mthumb -mthumb-interwork  -mtune=xscale --sysroot=/OE/shr-core/tmp/sysroots/spitz -DHAVE_CONFIG_H -I.    -fPIC -O
2 -pipe -g -feliminate-unused-debug-types -DNDEBUG -c atomic_ops_malloc.c
| atomic_ops_malloc.c: In function 'msb':
| atomic_ops_malloc.c:223:2: warning: right shift count >= width of type [enabled by default]
| rm -f libatomic_ops_gpl.a
| ar cru libatomic_ops_gpl.a atomic_ops_stack.o atomic_ops_malloc.o
| arm-oe-linux-gnueabi-ranlib libatomic_ops_gpl.a
| {standard input}: Assembler messages:
| {standard input}:286: Error: selected processor does not support Thumb mode `swp r1,r2,[r3]'
| {standard input}:329: Error: selected processor does not support Thumb mode `swp r0,r1,[r3]'

* this is just work around, proper fix proposed by Henning Heinold
  hm we should think of reworking this recipe now. Because since gcc 4.5
  pulseaudio for arm can use the gcc internal atomicstuff and in oe-core
  and meta-oe we have 4.5 or 4.6 only. The lib is
  only needed for mips and it is still the old release, on cvs
  is a much better version, which supports thumb too, if
  remember correctly.

(From OE-Core rev: 2d34fc0ce21fe06ff97208c8ffb65a718b444de9)

(From OE-Core rev: 6b403ff01863cf3788b696a2b45e56cfaca56512)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:40 +00:00
Richard Purdie 2c1a0b7d32 dpkg/update-alternatives: Fix dpkg version of update-alternatives to be usable
The version of dpkg the updates-alternatives-dpkg recipe pointed
at no longer used a perl script but a compiled binary. This meant
the "all" architecture field was invalid, as as the sed operation
during do_patch. All things considered the separate recipe was
pretty pointless.

This patch moves update-alternatives back to being built as part
of the dpkg recipe. It also moves various functionalty to the .inc
file which it belongs and fixes building and packaging of the dpkg
perl modules.

(From OE-Core rev: fad496c759066d53bebf9b8cebc63e6478c91d19)

(From OE-Core rev: 467af9ae45ce54d6e50041d5134af889ac7cf4d2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:40 +00:00
Richard Purdie 9e52c53a5d base-passwd: Move update-passwd into a separate package
update-passwd is the only user of the passwd/group.master files
and was never used by OE since it wasn't run.

This patch packages this separately and adds an appropriate postinst
to make the package useful so people can include it as they wish.

(From OE-Core rev: 77ab0f09546c5f6217a8e2f1bc30cf3d4306e3fa)

(From OE-Core rev: c26d37b65e0ad69a36e799c56f3c4426ea18f17e)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:40 +00:00
Richard Purdie f812a2c912 base-passwd: Fix the broken preinst/postinstall
The preinst accesses file which may not yet have been unpacked.
The postinst is too late for the creation of these files
for at least the opkg backend.

This patch therefore encodes the file contents into the preinst,
resolving the various issues once and for all.

(From OE-Core rev: fc708d88f97e40a5bf929e4e02ed805fb3684ffe)

(From OE-Core rev: 0f4156c0735e28812c3f8ab27075d3de5360badb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:40 +00:00
Richard Purdie d3c848094f opkg: Ensure we use the uname/gname fields when extracting tarballs
When extracting packages onto the target system in particular, we
really want to ensure the name fields in the tarball are used over
and above the numerical uid/gid values. This patch adds this
functionality to opkg and ensures package upgrades work correctly
permission wise.

(From OE-Core rev: f2316ff39670ed99382411e15ac035550360fbdd)

(From OE-Core rev: 56800b9906cf228331083256664407947f831185)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:39 +00:00
Richard Purdie 37d694ae80 rootfs_ipk.bbclass: Ensure bad recommendations persist in the status file
Currently bad recommendations are added to the status file with status
"ok". After a single opkg command, whilst it will ignore the recommendation,
the status changes to "installed" even if the recommended package was not
installed. Whilst this is likely a glitch in opkg's logic, the correct
way to persist the information in the status file is to set the status
to "hold" as deinstall packages with that status remain. With this change
the bad recommendations persist accross multiple opkg runs and the system
behaves as expected.

[YOCTO #1758]

(From OE-Core rev: 215ff6b2e9676c8c7dd8acfd696151bcd0f1490f)

(From OE-Core rev: 525743f5513feff67fb8fd2e4c7a1a05ae22ddc9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:39 +00:00
Otavio Salvador e391e1a200 xinit: rdepends on util-linux-mcookie to avoid brining whole util-linux
(From OE-Core rev: a8ed4fcd79f6283c1d45f347dce894d784183900)

(From OE-Core rev: 7fc9855421222eb671e414ef7bc190f53521e914)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:39 +00:00
Otavio Salvador 199f985754 util-linux: split mcookie into a package
(From OE-Core rev: 3e5b9ddaf3f9492e34967146c42369bcd76ddf03)

(From OE-Core rev: 66ac20ea171a5f823b4810975570885c8138d930)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:39 +00:00
Paul Eggleton 395ffa8930 util-linux: split out mkfs into its own package
For those external tools such as Webmin that call mkfs to do formatting
operations, it is useful to have it in its own package to avoid dragging
in the rest of util-linux.

(From OE-Core rev: cceee30de96b2389209fc2c9c474ebbd863ff64a)

(From OE-Core rev: d5841bc9559d9de4ca1a063ecf40571688d0d147)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

[Merged with head]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:38 +00:00
Matthew McClintock 90920546e4 Add new util-linux-chkdupexe package to avoid making perl a dependecy for all of util-linux
(From OE-Core rev: 57def2a05f4cff77f014c6dfb93c2dcc1b9db61b)

(From OE-Core rev: 115f49b2b4b13884be7a4fffc4261cbcb884d428)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:38 +00:00
Koen Kooi 1d9ec42166 util-linux 2.19.1: split blkid out into its own subpackage
Recent udev versions require blkid from u-l, not from e2fsprogs. In general all the non fsck related binaries from e2fsprogs are deprecated.

(From OE-Core rev: eb048308ae80d779e904951b032dba5b780898e5)

(From OE-Core rev: d9afc91bd5bce889dfbcba13b6b59ea07f288cc7)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:38 +00:00
Koen Kooi 57481984c9 util-linux: split fsck* into its own subpackage
This will allow systemd to run /sbin/fsck without dragging in all of util-linux

(From OE-Core rev: 4c95779fe1297b06adc705de30dca4e3570084ae)

(From OE-Core rev: 8b3beaddb5d44efcaa88ea173081c6e0558908ad)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:38 +00:00
Mark Hatle 05051d864d sudo: Avoid post install scripts
The post install script was removed, and the install_append updated
to ensure the permissions are set correctly.

(From OE-Core rev: 463e44ae159da2e03369f9ac14843b479de2e43d)

(From OE-Core rev: 52dac3a309f3f1d6a4ee7269b16ca381fd0cdd38)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:38 +00:00
Mark Hatle 48ee7e9b3a shadow: Generate the shadow files at rootfs construction
With the recent changes to the shadow-native package support "--root",
we can now convert the passwd/group files to their shadow forms while
doing the rootfs install, instead of waiting to run on the target.

(From OE-Core rev: 662431ace246e9bb35ad8d0ddd0510193f93517d)

(From OE-Core rev: 03c366bb36145f7bc1679307e578bb2cf44e3737)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:37 +00:00
Mark Hatle 1278cee687 wpa-supplicant: Avoid blocking the post install script at cross rootfs time.
We only want to reload dbus, if we're install on the target -- not on the host.

(From OE-Core rev: 1ce23fe7d7c33c196af3ba25b4e97496718328d1)

(From OE-Core rev: e9dc54d5c31ef50fa2f929d552e2f61533426dcc)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:37 +00:00
Mark Hatle b5195d2739 rootfs_rpm.bbclass: Turn off script debugging
Disable script debugging, as the log files become huge and take a
long time to process during the log check step.  This results in a
performance improvement.

(From OE-Core rev: a7e70227bac72c4f7d3419f94f6915da4c7e3f43)

(From OE-Core rev: 9b6ecd1fd2f6870ace033362e3bb86fd98935bc9)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:37 +00:00
Mark Hatle 7561770d43 rootfs_rpm.bbclass: Enable pre and post install scripts
[YOCTO #1755]

We change the want the RPM rootfs install works to install pre and post install
scripts.  The new method uses a script helper that is invoked by RPM outside
of the normal chroot.

The wrapper is dynamically generated prior to the install starting.  It will
check the return code of the script.  If the script fails, it will store a copy
to be executed on the first system boot.  This is similar to the previous
mechanism.

In addition, a line of debug was added to the scripts as written by package_rpm
to list which package and which script for later debugging, if necessary.

(From OE-Core rev: 3e7120d6a9fd5e46214673d0a6e1085a7314ff42)

(From OE-Core rev: 5d74a2bbe036cf586b76aef0d9907ecb3d4a5f1d)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:43:01 +00:00
Paul Menzel 03fbfe7cf1 xinit: Fix `startx` looking for `mcookie` in sysroot
`startx` run on a system based on the demo systemd image [1] and `opkg`-installed packages fails with the following error.

	/usr/bin/startx: line 139: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x68_64-linux/usr/bin/mcookie: No such file or directory

Applying commit 443bcc07 [1] from OE-classic

        Author: Tom Rini <tom_rini@mentor.com>
        Date:   Thu Apr 7 10:36:43 2011 -0700

            xinit: Fix mcookie / util-linux-ng dependency

            xinit just needs to know the runtime path of mcookie so we need to
            RDEPEND on util-linux-ng and pass the runtime path in via EXTRA_OECONF

            (From OE-Core rev: 1053a6a8e15851ef139d8aa4683849fc2fc277e1)

(From OE-Core rev: a32d9dbc25fce5e8566681f0c7f606eedaaf3933)

Signed-off-by: Tom Rini <tom_rini@mentor.com>

fixes this issue. Commit 7f6cec6f [2]

        Author: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
        Date:   Sun Feb 21 18:11:30 2010 +0100

            xinit: add dependency on util-linux-ng

        […]

tried to address the same problem but apparently did not help, because Tom still had problems.

[1] http://www.angstrom-distribution.org/demo/beagleboard/Angstrom-systemd-image-eglibc-ipk-v2011.11-core-beagleboard.rootfs.tar.bz2
[2] http://git.openembedded.org/openembedded/commit/443bcc0785bc004e471b3750a34d12d2fd2e5dad
[3] http://git.openembedded.org/openembedded/commit/7f6cec6f0adb6203a6dbaf8a43c67c2c4f8bf84e

Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:16 +00:00
Darren Hart 9faa58ecdc ncurses: refactor configure to avoid configuring widec when disabled
The ENABLE_WIDEC variable can be used to disable ncurses wide character support
when your C library doesn't support it. Currently, the do_configure step
configures for both narrow and wide characters regardless and only checks
ENABLE_WIDEC during compilation. This leads to QA failures with host
contamination during configure if the C library doesn't support wide characters.

Refactor do_configure with a new ncurses_configure helper function and only
configure for wide character support if ENABLE_WIDEC is true.

Ensure that configure errors are propogated back through to do_configure.

Tested with ENABLE_WIDEC as true and false via an ncurses bbappend on i586,
including basic error injection.

V2: INC_PR bump

(From OE-Core rev: 8b995deb046469c1c713fa053510d2fe94454133)

(From OE-Core rev: 802cd855f1860ef0fbbbbf87b0af7c5dcdc35975)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:16 +00:00
Saul Wold cc19812fb4 udev-extraconf: blacklist /dev/md
Do not mount /dev/md by default via udev, this resolved a problem
with the sanity test failing due to seeing the error while attempting
to mount /dev/md0

(From OE-Core rev: 07a2825c6f4ad3e5e3970cd1a89233bd795c68cf)

(From OE-Core rev: 8ea8e41ad7863f57a851f00154e133cd0e550ef8)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:16 +00:00
Richard Purdie 110d499544 useradd: Add missing DEPEND on shadow
Without this rootfs generation fails as an RDEPENDS is added
but the package might not have bneen built.

(From OE-Core rev: bfe70c6446e6686f826f01040ba74c7d7d28bf42)

(From OE-Core rev: 30a1f1d3ec763b4929b052ab3388499dfb40b1fa)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:16 +00:00
Scott Garman 7fe64f43f4 avahi: remove USERADDPN
USERADDPN is no longer used; remove it.

(From OE-Core rev: ed7e7a8e4d00cd45c74dc233c8b574d3978755d8)

(From OE-Core rev: 2a52444dd464f5dff43424ab18feae43435061ae)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:16 +00:00
Scott Garman 47007075d4 useradd-example.bb: update example documentation comments
Clarify that only packages listed in USERADD_PACKAGES will
include the user/group creation code.

(From OE-Core rev: 70aaac37968bf2b35d6a536c3f3f69fe3620255c)

(From OE-Core rev: 3d0649253cc99b658a2f6576b1d38661d65f3977)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:15 +00:00
Scott Garman 9dc2193d31 useradd.bbclass: do not modify -nativesdk packages
Exclude the addition of user/group code and RDEPENDS changes for
-nativesdk packages.

(From OE-Core rev: 2f057dd905ccb497890ce73ac4e4c256edcf0351)

(From OE-Core rev: 9acbe80fea3dbd5405030c95d8b6d411689c4911)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:15 +00:00
Scott Garman 403d5e0b7d useradd.bbclass: only modify packages in USERADD_PACKAGES
Previously we injected the user/group preinstall script into all
output packages. This fixes that so that only packages listed in
USERADD_PACKAGES get modified.

It also removes the USERADDPN variable, which is no longer needed.

(From OE-Core rev: 2f73466eb5018040a123ccb0e2af8c519525f958)

(From OE-Core rev: 424b6447ebce761c9027ffdaf68ecbcd6f28e4ec)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:15 +00:00
Paul Eggleton 5d9dfed5c4 busybox: add grep to temporary links during uninstall
In the busybox package prerm we set up some temporary links and modify
PATH so that certain utilities are provided for the purpose of running
update-alternatives; if grep is not among these then you get errors when
removing busybox, so add a temporary link for grep as well.

(From OE-Core rev: 013eca09c863862cc6b7ee3bc22923bf8fb42956)

(From OE-Core rev: a425305249cdd89ab481310b31ae04970c6ae3be)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:15 +00:00
Paul Eggleton 9924a6c72d classes/package_rpm: disable uninstall scripts for upgrades
Our current assumption (based on the behaviour of opkg) when writing
recipes is that prerm and postrm do not get called during an upgrade.
When using rpm however, these are mapped to the rpm "preun" and "postun"
events which occur after postinst for upgrades, and when these contain
removal type operations (such as update-alternatives --remove) this
causes problems.

This patch wraps each preun and postun script for rpm in a check that
determines whether or not the script is being called during an upgrade,
and skips the entire script if it is, which mimics the behaviour of opkg
under the same conditions.

Fixes [YOCTO #1760]

(From OE-Core rev: 1d3f37dc9a43ba6d6beb7b4530c077f239032b99)

(From OE-Core rev: 6e66ecd201760fe418a9884e3605b88a68208776)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:14 +00:00
Tom Zanussi ccf6077d4e python: skip setup.py 'import check' when cross-compiling
build_extension() in setup.py, as part of the build process, does an
'import check' on the built extension.  The import check in turn
dlopen()'s the shared library associated with the extension, which
isn't something that makes sense if that library was cross-compiled
for a different architecture.

This was noticed with an x86_64 target that was compiled with avx
support, because it caused 'illegal instruction' exceptions:

| /bin/sh: line 1: 14575 Illegal instruction ... -E ./setup.py -q build

For other target architectures, it doesn't necessarily cause illegal
instruction exceptions, but still fails.  For example, on arm, the
failure pathway causes this warning:

*** WARNING: renaming "cmath" since importing it failed: .../cmath.so:
    wrong ELF class: ELFCLASS32

This patch to setup.py and the associated recipe changes allow the
whole 'import check' logic to be skipped when cross-compiling.

(From OE-Core rev: 25fae81538a92e15eab3fc169ebce44505f67839)

(From OE-Core rev: d83e4ac25cca788d2b102c2072ccb367c0cab284)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:14 +00:00
Tom Zanussi 38978dc0b8 libzypp: fix mishandling of hyphenated arches
Several hyphen-to-underscore translations were missing, causing
compiler errors trying to build arches with hyphens in their names.
This adds the missing translations.

(From OE-Core rev: 5be9785f344ec4d7580f7ec68e29dba9fceb0a0a)

(From OE-Core rev: 69f45c6e9f28aae2ba84aea87a6ed096800ed685)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:14 +00:00
Tom Zanussi 9152ef8b1d gmp_5.0.2: Set CC_FOR_BUILD to BUILD_CC
CC_FOR_BUILD was compiling the test programs using the target's
compile options and executing those on the host, causing errors such
as:

/bin/sh: line 1: 15032 Illegal instruction     ./gen-bases table 64 0 > mpn/mp_bases.c
/bin/sh: line 1: 15033 Illegal instruction     ./gen-bases header 64 0 > mp_bases.h

Export CC_FOR_BUILD using BUILD_CC to fix the problem.

(From OE-Core rev: 68cca5ca15cbdd53748ec130fb6f20cbb3fb5072)

(From OE-Core rev: 6ce3482c0f50b95d1d60d3c9250a9ab38fca76fe)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:14 +00:00
Otavio Salvador 4e4521b5bf files/device_table-minimal.txt: add /dev/kmsg
(From OE-Core rev: 1a340471694204937981513dee4cc24bc2dc6f7e)

(From OE-Core rev: 535f7e52b02b6434fca5265eba8d366f483ce33c)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:13 +00:00
Otavio Salvador 501211d4d5 libcap: fix sstate for native package
The 'lib' option needs to be given on target and native builds
otherwise it installs the binaries at ${libdir}64 when host is 64bit.

(From OE-Core rev: f768ef66c107410d4e81a69543d41910bbc6a26e)

(From OE-Core rev: 76be81b5b0f56536dd36e800bc3f597aeea6d8ef)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:13 +00:00
Eric Bénard 155aad308c useradd.bbclass: handle nativesdk case
* without this patch, building dbus-nativesdk leads to a missing
dependency on 'base-passwd-nativesdk'
This was added by commit 46e6c3fa8034b12d178d605f3f5d7efe69671a13
* this patch handle the nativesdk case in the class useradd
* close bug 1702 http://bugzilla.pokylinux.org/show_bug.cgi?id=1702
* v2 from Scott Garman with Richard Purdie's tricks

(From OE-Core rev: 140a3507fb5c14cd9bcebe4304f491aa1c5c47a2)

(From OE-Core rev: 79d5ce46b4d73e5ed39c509ce872e99e6bcb94ee)

Signed-off-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:13 +00:00
Dongxiao Xu 11e383d24c multilib: Drop MULTILIB_IMAGE_INSTALL
There should just be a single IMAGE_INSTALL variable. If the package
backends need this split into different multilib components they should
be responsible for doing this, not the user.

This commit removes the MULTILIB_IMAGE_INSTALL variable.

[YOCTO #1564]

(From OE-Core rev: 7736862a74c92fe1afe42e170822be13117575c2)

(From OE-Core rev: 4889865934d590bf18d9f8f8ec3b63ce992cd4c5)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:13 +00:00
Joshua Lock aff0c68b0f contacts: fix packaging of icons
(From OE-Core rev: 1f4028337d5e288e239f44ef34e1d707b785273e)

(From OE-Core rev: 8bc45d72d3211df9ca846c775524176308027aea)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:12 +00:00
Joshua Lock 3b75e27536 gypsy: fix packaging
(From OE-Core rev: 3c272ce9df811281029d028e96ab6bc644645592)

(From OE-Core rev: 28c22b7d7cdbea39fca5867f14c22f75f7749183)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:12 +00:00
Joshua Lock 5f3b7a7616 libcanberra: add libvorbis to DEPENDS
(From OE-Core rev: 531151fdeba3779ba6f0976fc08aa8da483600f7)

(From OE-Core rev: 05f10a527099d22eb87614013e01c420bdafaf16)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:12 +00:00
Eric Bénard fb8d219960 dbus: fix install for virtclass-nativesdk
* 46e6c3fa8034b12d178d605f3f5d7efe69671a13 changed do_install
which now fails for nativesdk (chown messagebus leads to no
such user)
* tested by building meta-toolchain-qte and running the generated
sdk

(From OE-Core rev: 5818a885df489f4bc9579d17c6b0efa7777f5ccc)

(From OE-Core rev: 7984cc2fec3179da2e1f8f3bbffca9e7e21a3788)

Signed-off-by: Eric Bénard <eric@eukrea.com>
Acked-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:12 +00:00
Scott Garman ae88920dec useradd.bbclass: fix how RDEPENDS is setup
Fix bug where only packages named PN included base-passwd in
RDEPENDS.

This fixes [YOCTO #1727]

(From OE-Core rev: 2c55d51afd71d708a54afc8377e10c4f80f810e3)

(From OE-Core rev: 213d31f24d911a10132ddcd75f50363a80c4dc2e)

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:11 +00:00
Martin Jansa 57c6f14828 libnl-2.0: add PE/PR bump for upgradable patch for meta-openembedded users
(From OE-Core rev: 2260b18590416940eec26aaf3d68e510ceff8d31)

(From OE-Core rev: 3aa933cf91cf788246f13966471a9be6e0bc1931)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:11 +00:00
Martin Jansa bd9a5e1b88 libnl-2.0: split to more packages, as meta-openembedded does
(From OE-Core rev: 8720e063c7b43c278b3bb406b45390ed03f8ac96)

(From OE-Core rev: 0f495eca8737a71ade6e1b5ca0fcbddf3b22181a)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:11 +00:00
Martin Jansa 8614fcf709 libnl-2.0: add patch from meta-openembedded to fix pkg-config file
(From OE-Core rev: 72227178bc74d6e2e24f8df6176c3d45b640e860)

(From OE-Core rev: 64aab9609e23cdaa662cf544a31de5e879958e31)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:11 +00:00
Martin Jansa 2202d845ab libnl-2.0: move fix-pktloc_syntax_h-race.patch to libnl-2.0 subdirectory and merge with fix-makefile.patch
(From OE-Core rev: a4882cd6f98c5b3df80ba96536d94d9f556f77a2)

(From OE-Core rev: 69701f7eaec6405fe2208d2412aebaf2db5ce606)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:11 +00:00
Koen Kooi a55d8c6aa4 image_types bbclass: use 4k bytes per inode so we don't run out of space immediately
genext2fs only creates the minimum number of inodes, after this patch it will scale with the rootfs size

(From OE-Core rev: c31cb0bdc5a61d2d9f21a2cea34c3d8ac3b47cb9)

(From OE-Core rev: 41d1091e6b821404eeb73a7c363537c2835558d3)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Martin Jansa b6312e2d51 libcense.bbclass: fix OpenSSL mapping
[YOCTO #1712]

(From OE-Core rev: 56799ebcb5c55a7fc75458fc2be2e69a67e8fd21)

(From OE-Core rev: efb4527ff527d3e465df2a21fdfda110542b70b5)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

Fixed YOCTO bug format and location

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Dmitry Cherukhin 5a41a612c9 tslib: fix the bug with loading libts-1.0.so
Touchpad did not work in the qtdemoE if the library libts-1.0.so was not loaded
manually using the LD_PRELOAD variable. This problem was fixed in the tslib mainline
https://github.com/kergoth/tslib after the 1.0 release. We just import the patch.

(From OE-Core rev: 0ba6d91dc527908740890c896b834e7216b0d2fb)

(From OE-Core rev: cf9fbfcb65c09d70613eb6ab87e0b9121cfcc34c)

Signed-off-by: Dmitry Cherukhin <dima_ch@emcraft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Kumar Gala aaea770f1f udev-164: Update init script to do an explicit add action
With udev 152 or greater the default action for 'udevadm trigger' was
modified to be 'change' instead of 'add.

To ensure initial coldplug events at boot are seen be scripts the are
expecting them as 'add' events we invoke udevadm with an explicit
'--action=add'.

(From OE-Core rev: eacafd21999ab37b60af29dc3e626c441716ef66)

(From OE-Core rev: c90e1c91efc721eb6910cd3244b7671b63a341b6)

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Elizabeth Flanagan 6e4607f23a buildstats: Fix for buildstats on tmpfs
tmpfs/encryptfs/(and most likely, but not confirmed)ramfs TMPDIRs
cause diskstats to choke. No device entry ends up in /proc/diskstats
for these fs types, which ends up causing the failure.

The short term solution is to exclude these fs types from diskstat
collection. Longer term we will want to see if we can collect
meaningful diskio for each of these, and other, use cases, but for
this cleans up Bug 1700.

[YOCTO #1700]

(From OE-Core rev: 2b14046c12855b6f484ba5bd6bc0a8022de6873e)

(From OE-Core rev: e0d26e0e1dfb9d35d71f20488c16f3cea3da862e)

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>

Corrected YOCTO bug location and format

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Richard Purdie 5a192f85d9 bash: Ensure we fully reautoconf the recipes so site data is used
This ensures bug 487 (missing job control functionality) really gets fixed.

[YOCTO #487]

(From OE-Core rev: 08b78066bd5a9ff2819a42eb4263ee0a78cddb97)

(From OE-Core rev: cf9d3140a9dae5bdc6145ae04a729f4775ae66a2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:10 +00:00
Koen Kooi 9ce56ec4ca rootfs_ipk bbclass: special-case base-passwd preinst to run first
Preinst are run alphabetically which breaks when e.g. avahi-daemon needs /etc/passwd present.

(From OE-Core rev: d6793165feb26c51b5f19ad1e6d1a4099878e879)

(From OE-Core rev: 0485c362ac6ee0a3e310de078d7a202b961fed11)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:09 +00:00
Koen Kooi e47cfd447c avahi: fix useradd race condition
Avahi doesn't work at boot because of:

+ sh /OE/../rootfs/var/lib/opkg/info/avahi-daemon.preinst
Running useradd commands...
grep: /OE/../rootfs/etc/passwd: No such file or directory

That is due to:

Package: avahi-daemon
Version: 0.6.30-r9.0
 [..]
Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), libexpat1 (>= 2.0.1)

After this patch:

 Package: avahi-daemon
 Version: 0.6.30-r10.0
 [..]
 Depends: libavahi-core7 (>= 0.6.30), libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-common3 (>= 0.6.30), libdbus-1-3 (>= 1.4.12), sysvinit-pidof, libc6 (>= 2.12), shadow, libexpat1 (>= 2.0.1), base-passwd

This also changes ${PN}-daemon to avahi-daemon to be consistent with the PACKAGES/FILES lines below

(From OE-Core rev: f01fbc17b5d9bf9a227d64fe858014376cd19432)

(From OE-Core rev: 9d0b21f0723fda0e0d287788eb79d3a70b12f949)

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:09 +00:00
Saul Wold fc2433de1d dbus: ensure that the useradd shell is set to /bin/false
(From OE-Core rev: 899efe6bf17a31d842ff2f65704d4858892496d4)

(From OE-Core rev: 7d6ba259603ebcb1c08c1ac7b77f8b482e77b6d5)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:09 +00:00
Saul Wold 8cf7c76ce1 connman: Use useradd to add the xuser for DBus
Connmand needs to start as the xuser as defined in the dbus
configuration and needs to share this with rootless X. Since
it's possible for connmand to run on a sytem without rootless
X we still need to create the user here.

Useradd will fail gracefully if the user already exists.

Fixes: [YOCTO #1699]

(From OE-Core rev: 8139ac9284031e00d6b268210b04b57670d9268a)

(From OE-Core rev: 835ab34adb6acf562e37db99a1dd24f7b8bd95ec)

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

Conflicts:

	meta/recipes-connectivity/connman/connman_0.75.bb
2012-01-30 16:38:09 +00:00
Saul Wold 5d8269d28a xserver-nodm-init: Use useradd to add the xuser for rootless X
This also address an issue with dbus and connman, since connmand
needs to start as the xuser in the rootless X situation.

Fixes: [YOCTO #1699]

(From OE-Core rev: 6823a32035de5d0bcd82a3b41a6ad536aaddbc58)

(From OE-Core rev: 26573a84583793f64979100c2b89a95146d38dd1)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:08 +00:00
Saul Wold 9f542cf856 avahi: use useradd to create avahi user for avahi-daemon
DBus was failing to start correct since the avahi user was
not setup.

Keep the dbus reload since this could still be installed
as a package an would require a dbus restart.

Fixes: [YOCTO #1699]

(From OE-Core rev: f0bfecc8a0af1c4c76a37a9c88f334ab6ae7e7ef)

(From OE-Core rev: 925c7cd5c3ff44a4d0f2c71d0029998bfd00db48)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:08 +00:00
Holger Hans Peter Freyther 398a0159a6 udev: Fix the packaging of libgudev
Make the libgudev so go to the libgudev package, this is already
fixed in meta-oe.

(From OE-Core rev: 43ac43d7c7245e9aa2bfc8572c2620074d1e2a25)

(From OE-Core rev: 3890186dda8db3978f18c05099a6f327c122cc1d)

Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:08 +00:00
Richard Purdie 8ce627f9b1 dbus: Ensure localstatedir is added to the package
(From OE-Core rev: dc0d004fd23f686591281eb1d700327ea15d1c54)

(From OE-Core rev: 3de19d01402aa7fdee28df2e1066987c14c17a78)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:08 +00:00
Richard Purdie a7e5ad1268 package.bbclass: Fix various problems
Before this change:

a) Ownership and permissions of files copied from packages to
   package-split could get lost during the copy process. This change
   ensures they are preserved.
b) Ownership and permissions of directories could also get lost.
   Most of the complexity in this patch is addressing this problem
   ensuring newly created directories match the source ones being
   copied.
c) There was no warning about directories being created but not
   shipped by any package.

This patch fixes all of the above issues.

(From OE-Core rev: 6021e309e69d823e1467648aee12a32182945569)

(From OE-Core rev: 5f9228b32c243ae499398763ce7c90b776dc9d24)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:08 +00:00
Richard Purdie 8223a46ca0 dbus: Use $D not ${D} in the postinstall
We need to do this as we don't want bitbake to expand the variable
but use the shell variable instead.

(From OE-Core rev: 509a8a9ea428debf3ff2115fcff0aa89d0239ced)

(From OE-Core rev: dcf118e9dfd15f7cf535c9918a6fcad9f9121ff4)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:07 +00:00
Richard Purdie 1890a0f3b2 gnome-doc-utils: Add missing glib-2.0 dependency
(From OE-Core rev: c367a2d2f4b817211b6bd200e49b49355cd67fe2)

(From OE-Core rev: f4555a27bcc2174d30c1ea4ab7785325766b7c4e)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:07 +00:00
Joshua Lock 2dbcd4154c lib/oe/terminal: add support for XFCE's terminal emulator
That's Terminal on Fedora and xfce4-terminal on Ubuntu/Debian... This
could get interesting!

(From OE-Core rev: 162b70a36388ac44fc1b39e172cd53579707bff3)

(From OE-Core rev: 149cc418dbcbe014225c86d16b5ef696496e3a39)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:07 +00:00
Saul Wold 0524f419cf libproxy: fix QA Packaging issues
(From OE-Core rev: d756b85565820f0caef17af4c4aee2bf29ea6794)

(From OE-Core rev: 58231521f9f20fb5606efc84f779612834225b7d)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:07 +00:00
Saul Wold a90c197e94 libatomics-ops: fix QA Packaging issues
(From OE-Core rev: dfddbffc48e86cb0a6d07da6727782e3b17535e1)

(From OE-Core rev: 33fe21a3d446f562fde9730e3755ae99fd50e1ae)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:06 +00:00
Saul Wold 21458bd419 mdadm: fix QA Packaging issues
(From OE-Core rev: b3840f88f004c9ef371a075f1800052c66c91759)

(From OE-Core rev: 5da0710659d671e7e9494feb546fbad950b0c644)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:06 +00:00
Saul Wold 7e96247751 man: fix QA Packaging issues
(From OE-Core rev: 2f597288c141c910b945e63e8b31436984ad536b)

(From OE-Core rev: cb3cdb9da4866539ac84df811076c4ddad89e47a)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:06 +00:00
Saul Wold 07e2aa9b80 at: fix QA Packaging issues
(From OE-Core rev: f3487717ae3b7f9256a3e3cc78be331e424ec457)

(From OE-Core rev: e9b469fb19c69dffc0aedf777dc58d41f6e1815e)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:06 +00:00
Saul Wold 5c37b7ea47 dbus-glib: fix QA Packaging issues
(From OE-Core rev: 1f55db4936b43e2fd3e50f99815b547e3c5e8010)

(From OE-Core rev: b84c1d5854052af3351f853f42c6a0e4b9918dd8)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:05 +00:00
Joshua Lock 79081f46ec libxslt: Fix packaging of xsltConf.sh
xsltConf.sh is installed to libdir not bindir, fix pacakging.

(From OE-Core rev: 27b438df0b937180263346cbf68f1641abcdb068)

(From OE-Core rev: 82ff9739d7b95775636d1b9ac7aa4fb5576eccd9)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:05 +00:00
Matthew McClintock 4f9e333b05 Add readline as dependecy for gdb-cross-canadian
Got errors that we were unable to find -lreadline, this fixed the
issue

(From OE-Core rev: ddc9a58b8553599d2328ac1c4449b41681ae45d1)

(From OE-Core rev: c50f8d83749d755e58fcd159b8e4dab33fbd9036)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:05 +00:00
Julian Pidancet dc09c258f0 Give coreutils a chance to build the df utility
The coreutils configure script is unable determine how to get free
space from the Operating System when cross-compiling.
This changes caches the result of the "statfs2_bsize" test for the
coreutils configure script.
Both glibc and uclibc defines statfs as a two-argument function
and uses a struct statfs containing a f_bsize field. That's why
the fu_cv_sys_stat_statfs2_bsize variable has to be defined for
both libcs.

(From OE-Core rev: fa1eb21933a880aa20e4ca87574753b1ec272c3b)

(From OE-Core rev: 5be987aeb5e34bb1277f86a7f294607a6d935a19)

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:05 +00:00
Khem Raj 5de0f305f9 pulseaudio: inherit perlnative
manpage generatition uses xmltoman utility
which inturn uses xml-parser. So we add
libxml-parser-perl-native to DEPENDS and also
inherit perlnative so it does not use the one
from build host

(From OE-Core rev: 51f6a683ec1d740adf09d808671c7098dc3f83e2)

(From OE-Core rev: c2ccc9a294cab3f41cab35eee64f8a464ac8ad9f)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:05 +00:00
Khem Raj 52dc5edde3 gcc-4.6: Backport fix for PR32219
This fix is needed for gold to work. Otherwise
connman fails to build since it used hidden weak
symbols.

See

http://gcc.gnu.org/bugzilla/PR32219
http://www.cygwin.com/ml/binutils/2008-02/msg00239.html

The fix proposed to gcc had reviews which were not addressed hence the
patch is not yet
applied to gcc upstream.

connman can also have workaround by changing the visibility of these
symbols to be default
 __attribute__ ((weak, visibility("hidden")))

to

 __attribute__ ((weak, visibility("default")))

in include/plugin.h

(From OE-Core rev: 3cb2b003db7371b3a47d02c08352a262e1e419b4)

(From OE-Core rev: 9a160921a16c9c37e07e4b5cb30e37348ecd205b)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:04 +00:00
Otavio Salvador 9d086cd151 dbus: use useradd class to allow use in read-only filesystems
Move creation of required user/groups to useradd class thus allowing
use with read-only filesystems and booting the initial boot.

(From OE-Core rev: 46e6c3fa8034b12d178d605f3f5d7efe69671a13)

(From OE-Core rev: a115b657ed3df1c9b26b016151881a6c9c26ac2b)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:04 +00:00
Otavio Salvador 2edde1021f base-passwd: move initial criation of group and passwd to preinst
To allow use and manipulation of users and groups at rootfs building
time, the '/etc/passwd' and '/etc/group' needs to be available as soon
as possible.

(From OE-Core rev: 0395eba96d6f37f323f5b76564809a44d7ceb103)

(From OE-Core rev: 73452afe344b66c6dd8e4e120e61ac9fce8652e3)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:04 +00:00
Otavio Salvador afc60481c7 useradd.bbclass: check if a group already exists manually
The use of groupadd -f makes much more difficult to figure when a
group is not add. This was the case of the class not working for our
usage and this being caused by the lack of '/etc/group' file but
unnoticed as groupadd wasn't failing according.

(From OE-Core rev: 82933a1ff921fd0836f03e6f379fd8536cdc0a30)

(From OE-Core rev: e3e8f15176107fa26248e878af548835692d3068)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:04 +00:00
Khem Raj eb94ba9052 gcc-configure-sdk: Point sysroot to correct location
(From OE-Core rev: c9883733fed9267b1a936c08500a4caf8dc52d3d)

(From OE-Core rev: 1cffc4c39f897ae1db30825364ff809ce40f512b)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:03 +00:00
Khem Raj 6fa445d50e binutils-cross-canadian: Point sysroot to correct location
(From OE-Core rev: b8dad4ab77f5516bc6929e2ed094fdc62a5a52db)

(From OE-Core rev: 065b65f8835304a0ba7fe751a132b684a41b08ae)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:03 +00:00
Anders Darander 795843df09 module.bbclass: add lock to prevent error bulding ext modules
When external modules are built, files in $STAGING_KERNEL_DIR/scripts/basic will/can get
rebuilt.
This raises a potential race condition. Prevent this by adding a lock around the
do_make_scripts() function. Further, make sure that the kernel has been installed
to the sysroot, prior to executing this new task.

(From OE-Core rev: 8681b82e8b466929205edde7ba479f3ac1a6143e)

(From OE-Core rev: 694e3016e25dff3f573291830d79982c8b8793a2)

Signed-off-by: Anders Darander <anders@chargestorm.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:03 +00:00
Khem Raj 8a20492e8a gcc-4.6: Backport PR46934 fix
We have been hitting this issue on ARM/thumb and
have a workaround in place to compile samba
http://git.openembedded.org/openembedded/commit/recipes/samba/samba_3.2.15.bb?id=4ba7aa07c0dcd28f94515ff9927e2a04403fcf15
This backport should fix the gcc bug

(From OE-Core rev: 75f7269a7a1da2494768d4be63c44b12c5cfeeeb)

(From OE-Core rev: 446767c4c471b8ec932698a23af5a815d326a0be)

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

Conflicts:

	meta/recipes-devtools/gcc/gcc-4.6.inc
2012-01-30 16:38:03 +00:00
Khem Raj 70ff3b6d98 gcc-4.6: Upgrade SRCREV to latest FSF 4.6 branch
(From OE-Core rev: b1af6951e14d645fe861f289011c91ab6f1b6865)

(From OE-Core rev: f6ba855e3d8b33591c14048cac68264e93a821e8)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Lauri Hintsala ba79e6f631 poky: fix broken ubifs link in deploy folder
Fix broken rootfs image link when ubifs is used.

Function runimagecmd is using image name "${IMAGE_NAME}.rootfs.${type}".
Let's use the same name in IMAGE_CMD_ubifs.

(From OE-Core rev: 766f6165471691f651584ebda004e1abb4ea9eb6)

(From OE-Core rev: 6c4276ee968bed7a5b3e74637183414a428facb8)

Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Martin Jansa 071d5de3f3 fontconfig: fix fix-pkgconfig.patch
* missing $ is causing problems ie when building webkit-efl
* see http://lists.linuxtogo.org/pipermail/openembedded-core/2011-June/003798.html
  for details

(From OE-Core rev: e31dd9b65f3b03f79cabab25eca157532de3bd9c)

(From OE-Core rev: 5deaf85c0c07105173e6791a7aafd03aa5b2e204)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Xiaofeng Yan 1fa324c533 lsb: Change link of ${baselib} to lib64 for 64bits system
Correct two faults:

1 Binaries of lsb test suite need ld-linux.so* in /lib64.
for example:
Target$ ./lsbcmdchk
-sh: ./lsbcmdchk: No such file or directory
Target$ strings lsbcmdchk | grep "ld-"
/lib64/ld-lsb-x86-64.so.3

"lsbcmdchk" from lsb test suite is a binary program.
A new modification to lsb_1.4.bb caused that binaries from lsb test suite can't run
because binaries of lsb test suite need ld-linux.so* in /lib64.
But the link is changed due to adding multilib. I changed this link again.

2 correct mandir
Waring will appear when running task task do_populate_sysroot

NOTE: package lsb-1.4-r2: task do_populate_sysroot: Succeeded
WARNING: For recipe lsb, the following files were installed but not shipped in any package:
WARNING:   /{datadir}/man/man1/lsb_release.1.gz

I changed mandir=${D}/man to mandir=${D}/${datadir}/man

(From OE-Core rev: f2dada2079b5f98e13d4888609368ba111967a60)

(From OE-Core rev: 9961c1e73e8f8ae426d7ac8c9ba35b05669cbffe)

Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Saul Wold 958c7f773f sysprof: remove duplicated patch
Apparently this pactch was duplicated by backported
patch, and needed to be applied more broaded than to
just ppc.

(From OE-Core rev: 182e4768b651e58de5b42f9fb55ae9816b57233b)

(From OE-Core rev: 62700be77386ba3388dc65b599cce9dfe5b802f6)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Saul Wold 141240c409 libomxil: Fix QA Package Errors
(From OE-Core rev: ef786ef9abcd919c651c14004a1cb0a0dcad1bff)

(From OE-Core rev: 83cad4ce6b1e942c3c45d316cbec95db4e04bebf)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:02 +00:00
Samuel Stirtzel 89e945be6a data.py: fixed message domain errors
The dynamic message domain was introduced by Richard Purdie with the following patch:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6c48298b17e6a5844b3638b422fe226e3b67b89

(From OE-Core rev: 55a8382e460430dc5ff10755d235d637531d2ae7)

(From OE-Core rev: d08db11fcae91deca10d250430a6f77de47f9080)

Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:01 +00:00
Samuel Stirtzel 7d30c2df87 patch.py: fixed message domain errors
The dynamic message domain was introduced by Richard Purdie with the following patch:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a6c48298b17e6a5844b3638b422fe226e3b67b89

(From OE-Core rev: 2383e06c8ed7c15aa148b9dbe40445e7095b6f57)

(From OE-Core rev: d104367903478613123c64df8d2a5188775d1f9d)

Signed-off-by: Samuel Stirtzel <s.stirtzel@googlemail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:01 +00:00
Wenzong Fan 90a4f95d3d qt4-x11-free: Fix broken regexes in qt4-x11-free's recipe.
[YOCTO #1671]

qt4-x11-free's recipe includes a sed script to sanitize it's .prl files,
which are used by qmake to generate a list of libs and includes in the
Makefiles it generates. It however, fails to take into account the possibility
of trailing slashes, and thus leaves them in, and breaks gcc's syntax.
Update these regexes to account for them.

(From OE-Core rev: 8d580ed449c09a64483519d66e14a2e3b071806a)

(From OE-Core rev: 9f655fbf0f818e25fdbf247334881da07a29e815)

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:01 +00:00
Tom Rini 53db004d24 libnl2: Fix a race on route/pktloc_syntax.h
At issue is that route/pktloc.c (not generated) depends on
route/pktloc_syntax.h (generated).

(From OE-Core rev: 7bec22c70598a5180f754bbbe2dfdd3db2843a64)

(From OE-Core rev: b992c9e631bfb4888a20a13b7ebf3b5acf59edb5)

Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:01 +00:00
Christopher Larson f7d5b31d6c autotools: fix multi-word arguments for EXTRA_OECONF
This is needed to better support things like the following (with a
multi-word BUILD_CC):

    EXTRA_OECONF += '"ac_cv_prog_CC_FOR_BUILD=${BUILD_CC}"'

(From OE-Core rev: 38a394e7ffedccfabda085c97add8944718943c2)

(From OE-Core rev: 5c26de72b97a670a263428ef3a1846385683feeb)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:00 +00:00
Richard Purdie 35d3782099 flac: Add missing gettext dependency (requires iconv)
(From OE-Core rev: fd310c2d64dd2df62bf3a10e5dbad25492013ae2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:00 +00:00
Matthew McClintock 1080ef1105 Fix sysprof for powerpc64
__ppc64__ is not defined on powerpc64, rather __powerpc64__ is, this
uses a patch that is already upstream to fix builds for powerpc64

(From OE-Core rev: 4732222c46652951e66aae377631f4a361179d8f)

(From OE-Core rev: d4cc180e60da43f66618d130009ac5d4930b9228)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:00 +00:00
Matthew McClintock 7bd151a4f3 Fix mdadm for powerpc64
This takes an upstream fix for compiling on powerpc64

(From OE-Core rev: 1325f506972555d4c218c15090bfa3f63fb13473)

(From OE-Core rev: c6da1a4eb9ba6885b49b0240030dff9b234ab1ca)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:38:00 +00:00
Martin Jansa e1f53370ed zlib: fix inverted LFS logic
(From OE-Core rev: 6dd3f5c2f300c9cb5b6dbe2afe67323fc6f44c3e)

(From OE-Core rev: bf7b5c6f6b8d27e64fcb169ec9a4c4ecf2047e58)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:59 +00:00
Martin Jansa e708d0ab68 libglade: add gdk-pixbuf dependency
(From OE-Core rev: eb709fceacab3ec33f38694d6238b96cb0474848)

(From OE-Core rev: c0382636ee2cfc0ea74464904d94eb1178512700)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:59 +00:00
Julian Pidancet e6e867558b Use useradd and update-rc.d classes in the OpenSSH recipe
The current sshd postinst and postrm scripts in the OpenSSH make the
package dependant of the adduser/addgroup scripts which may not be
available on all systems.

This patch replaces the sshd postinst and postrm scripts with proper
usage of the useradd and update-rc.d classes.

This patch had been modified from the previous proposed version to
use useradd long options for more clarity.

(From OE-Core rev: 6b7f399d595ef58e759dab211f4ece155119a680)

(From OE-Core rev: 058116f528bff27ca5a0e56bbf8070e94f934f32)

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:59 +00:00
Julian Pidancet ab81049f37 Fix the --root option in shadow-native programs
The add_root_cmd_options.patch that we apply to shadow-native allow the
various programs from the shadow utility package to chroot() so they can
be used to modify etc/passwd and etc/group if they are located in a
sysroot.

Some of the shadow programs (gpasswd, useradd and usermod) need to parse
the command line in two passes. But we can't use getopt_long() twice
because getopt_long() reorders the command line arguments, and
consequently corrupts the option parsing during the second pass.

This patch fixes this issue by replacing the first pass by a very simple
manual walk of the command line to handle the --root argument.

This change is a patch of another patch, I apologize if it is
difficult to read. But IMHO it wouldn't make sense to put the patch for
this issue in another separated file.

The --root options in groupadd and useradd are needed to make the
useradd class work, and this issue was preventing to use useradd and
groupadd long options while using the class.

(From OE-Core rev: 6e9e19b18597103d8fe09f258cfd9904bb5f1c27)

(From OE-Core rev: 533d99f28fab73503ed3ebaee63aaaeb23ad2a1c)

Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:59 +00:00
Jason Wessel 0b2f036a81 Allow user mode NFS server to run without rpcbind / portmap
and nfsroot mount without the need to talk to an RPC info
server as long as the port numbers for mountd and nfsd
are known in advance.

This patch updates the qemu startup scripts and the
user mode NFS server to have the ability to start
without the need to use rpcbind or portmap services.

(From OE-Core rev: 3b1346c607c41a2d592c48594457c32153cb2314)

(From OE-Core rev: 13899c6cd44a618276e1b8d236187eddcb98bc2c)

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:58 +00:00
Richard Purdie 6ed9f0763b pkgconfig: Fix logic that was accidently leaving legacy pkg-config functionality enabled
(From OE-Core rev: aa816b0aaf39dc6f822114df0bd6d4dd62fce0b8)

(From OE-Core rev: d46496b814b9a75523b337202d53c2c6c198566b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:58 +00:00
Saul Wold 1e225af16e acl/attr: don't make symlink if base_libdir = libdir
(From OE-Core rev: 46cd3527217821a7e9a8223dc45a43294b6c5e8d)

(From OE-Core rev: c2d14090d6400f4d8cb140947ccb9b68f2086835)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:58 +00:00
Richard Purdie 385365f689 native.bbclass: Ensure native recipes have a deterministic baselib value
Changes to baselib by specific machine configuration were resulting
in sstate cache invalidation, particularly in multilib configurations.

This patch ensures this doesn't happen and native sstate cache files
are reusable.

(From OE-Core rev: d0915fb0a2cc80ad45b3fd526d3b29a91d99572c)

(From OE-Core rev: 4fe88a2a3c7cec3ad9ea13d39d71d317405c910a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:58 +00:00
Richard Purdie dec4fb1bee sstate.bbclass: Ensure machine specific stamps are only wiped for the current task
sstate was being a little too ethusiastic about removing stamp files and
was removing stamp files for other machines when it shouldn't have been.

This patch teaches sstate about machine specific stamp extensions and
allows it to only remove the current task's stampfiles.

Based on a patch from Phil Blundell <philb@gnu.org> with some tweaks
from me.

(From OE-Core rev: 5e9488495401399d39fcb5012b86c313b6caca73)

(From OE-Core rev: e8efeedbc2ec1587b1c4d938c25cacd4e8611053)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:58 +00:00
Kumar Gala ef1a8f21e0 scripts/oe-buildenv-internal: Add SOCKS5_{USER, PASSWD} to BB_ENV_EXTRAWHITE
If a SOCKS5 gateway is needed for a proxy access like git it might also
require authentication to the proxy via a password and username.  Adding
SOCKS5_USER & SOCKS5_PASSWD to BB_ENV_EXTRAWHITE allow for automation
of the authentication request to occur when something like a git fetch
is going through the proxy.

This patch requires the bitbake patch to add extra exportvars so
these variables get passed from Env -> bitbake -> fetcher

(From OE-Core rev: 9206ea0f7cd39d2ba6ff4b41cbeb17409d3ae5f1)

(From OE-Core rev: e0438a7ce3523c25d36d564ca85753f0931544e6)

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:57 +00:00
Richard Purdie 0c1b16db4c mtools: Disable parallel make install, its broken
(From OE-Core rev: 6f64114f5825bf6f6ab8eaaf4bed24586e05ee57)

(From OE-Core rev: b7d7af9d54fee435df88ad5d81eb32ed27cf59c7)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:57 +00:00
Tom Zanussi 02c530f442 kexec-tools: fix architecture mismatch QA error
Building sato-sdk for an x86_64 target throws this QA error:

| ERROR: QA Issue: Architecture did not match (62 to 3) on /work/x86_64-poky-li\
nux/kexec-tools-2.0.2-r1/packages-split/kexec-tools/usr/lib/kexec-tools/kexec_t\
est

kexec_test uses 32-bit code for testing - add an INSANE_SKIP exception for it.

(From OE-Core rev: 0dbf91969bb16f4761f58426ff5b458139c4e235)

(From OE-Core rev: 4f4088ee53950f934b736488dbd265e27df9b033)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:57 +00:00
Dmitry Eremin-Solenikov df2fddf9cb qt4: packaging fixup
Improve packaging:
* Add phrasebook packages to DYNAMIC_PACKAGES
* Correct phrasebook packages generation
* Include more files into -dbg packages
* Package fontdir and fonts README.

(From OE-Core rev: 4e3c29dd90f583cafe7a7fc863efb3720096d67b)

(From OE-Core rev: 8fbad61dc62bdd439a55bcca09601bed28fcd3af)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:57 +00:00
Martin Jansa 6f0c0167c6 hal-info: drop PACKAGE_ARCH all
RP: It would be better if we could find a way to patch out the compiler
checks in this package...
JaMa: drop PACKAGE_ARCH for now (nobody likes hal nowadays)

(From OE-Core rev: 870191c1c46e36f92c5d90a3eb049154b0597133)

(From OE-Core rev: 1f66c882937d11762916023f4233b63cc6645edc)

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:56 +00:00
Richard Purdie 47c5f1c3bc Improve handling of 'all' architecture recipes and their interaction with sstate
* Jansa: rebased on current master, added nocompiler patch also to
  font-alias, dropped allarch from linux-firmware, gnome-icon-theme, hal-info as
  those are checking compiler (ie in intltool check) and better to build
  them as default arch instead of rebuilding after every machine
  change.
* this is also part of [BUGID# 1075]

(From OE-Core rev: 85d8362e0c443f11fe8d3fd0fba55d1bd4983613)

(From OE-Core rev: bfb58bf95f1796deebc9759da6d22949d62e7070)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:56 +00:00
Otavio Salvador 29a5cc693c qt4: Fix translation support
The translation support was disable in build. The
fix-translation.patch was imported from OpenEmbedded to fix a linking
issue in phonon translation support.

(From OE-Core rev: 8d5a5d78f9e83c64ebddcecd7c4fd89cc1264163)

(From OE-Core rev: 23d72a8066233c592503fda4460c309adc27706a)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:56 +00:00
Denis Carikli c3a1b97511 qt4(embedded and x11): Disable neon for armv6-vfp
Without the -no-neon flag, neon is "autodetected"
by looking if the compiler is capable of compiling
a neon test, and succeed, and neon is then enabled
during the compilation.

(From OE-Core rev: 026b59180fe3fbeb43cfd143f053ef33f482ef0c)

(From OE-Core rev: e53987e52a362e9a66c0007bfe1ff17a1d5ba2da)

Signed-off-by: Denis Carikli <denis@eukrea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:56 +00:00
Eric Bénard f1369ae9fe qt4: fix generated sdk
- qt4-tools-nativesdk : actually the qmake binary which gets installed
comes from the native recipe. This patch fix this problem by launching
configure twice : once to compile qmake using the right toolchain for
nativesdk, and a second time using the native qmake to compile all the
other tools for the nativesdk. Then we install the right qmake.

- mkspec : the link actually created in qt4-tools-nativesdk's
do_install point to nowhere so remove it and generate the link in
meta-toolchain-qte as it's the only place where we have all the variable
to create it.

- toolchain_create_sdk_env_script_append : we need to add OE_QMAKE_CFLAGS,
OE_QMAKE_CXXFLAGS and OE_QMAKE_LDFLAGS else the sdk won't find these
variables that are inserted by qmake in the Makefiles.

- with this patch, oe-core generates a working meta-toolchain-qte which
can compile a small example and is properly recognized by qtcreator (this
brings oe-core's meta-toolchain-qte to oe-dev's functional state).

(From OE-Core rev: 5f6fb92b939147d2d6aa7790a378d4b7cce3ada5)

(From OE-Core rev: d86d55aea57966e1aaffe913c745a648c21f6c24)

Signed-off-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:55 +00:00
Matthew McClintock 8620d997d4 Fix lttng-ust for powerpc64
(From OE-Core rev: a75683a815343a481b3612c35e1ab79071343187)

(From OE-Core rev: 6af6e862a3f000ada27c8d7f3440821187494421)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:55 +00:00
Matthew McClintock 7d06a71c02 Update gitignore to ignore all meta-* directories
meta-XYZ directories have been manually added in the past, instead
always ignore them unless they are explicitly added

(From OE-Core rev: 3c6e85c653ce176fd2cb5a570e63c8e5da5a4e48)

(From OE-Core rev: ad5f076bee5f43c035499aa0b873ccf683e4e79e)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:55 +00:00
Richard Purdie 7c5028614b base.bbclass: Drop unneeded dependency
patch depends on unpack
configure depends on patch

We simply don't need a configure dependency on unpack. This simplifies
the dependencies of every recipe slightly and should make bitbake
slightly faster at resovling dependency graphs.

It also makes the .dot dependency graphs slightly more readable by
removing noise.

(From OE-Core rev: c54c1280fc0d06a53e23339c3913ec88eead13d9)

(From OE-Core rev: a5b205090d3244cd578d611fd45f2e2f4818b284)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:55 +00:00
Matthew McClintock 6844fac9d5 Fix flac build on e500mc cores
This core does not have altivec, so we disable it in the build,
also reestablish the config option to enable/disable building
with altivec

If SPE is not detected we always build with altivec which is wrong. This
will check to make sure altivec is enabled and pass build options
through accordingly

(From OE-Core rev: 96241de59fdf548ae0f80cc9e4668f9ba11924ef)

(From OE-Core rev: a7237f2be949aef19eedad5a4f34b91641f1660f)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:54 +00:00
Saul Wold 41b5ca8582 python: fix sqlite RPATH issue
(From OE-Core rev: 9f9612d15acc6ee3b71f52bdb3f1ec4cb56b1a17)

(From OE-Core rev: 98acff46d777a5a0931a80a33e9c9d148a0f69a6)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:54 +00:00
Matthew McClintock 7a1504dfe8 Add proper deps for nfs-utils, util-linux, and strace
These packages need these deps for the RPM generation stage:

 error: Failed dependencies:
| 	/usr/bin/python is needed by nfs-utils-1.2.3-r2.ppce5500
| 	/usr/bin/perl is needed by util-linux-2.19.1-r4.ppce5500
| 	/usr/bin/perl is needed by strace-4.5.20-r2.ppce5500

(From OE-Core rev: 9c9ea24b115a9bb87df1323b5f185ce426262aec)

(From OE-Core rev: 42acc3337ef40b3ef693000c27e6efdb79e39351)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:54 +00:00
Matthew McClintock 062623f6ef Fix sysklogd build on e500v2 cores
(From OE-Core rev: 5035097bb369dc1740b817734b92bcfa40d95d22)

(From OE-Core rev: 235ec938cdb01918df659a52711da63d3ff7441f)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:54 +00:00
Matthew McClintock 62ad5b81cb Add udev patch to compile against newer kernels
This patch is needed to compile against newer kernels which have
changed their API

(From OE-Core rev: 60b04097c7aeca2c4d529b2f23343a507fa68ea6)

(From OE-Core rev: 64ab24d5338120e7d1a1feba966269a885306a63)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:54 +00:00
Matthew McClintock ada8ebb116 Fix HAL on newer kernels without header file
(From OE-Core rev: 3d421ecaef966b47bec49aa2feb3ccc9833d041f)

(From OE-Core rev: 4a6599a01a6dd2b856656d93e82f1411b7d352ed)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:53 +00:00
Matthew McClintock f1f2cbbc0d Fix ghostscript on powerpc64
This adds pregenerated files for powerpc64

(From OE-Core rev: 30b91a530e7dbabc4cef24525691aa2c34ecf47b)

(From OE-Core rev: 4bef884ae1fe52916849045e4e3dca6396ee7fb3)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:53 +00:00
Matthew McClintock c434795edf Add autoconf cache for screen on powerpc64
Screen can not run tests for the target and depends on the aotuconf
cache for information about the target system

(From OE-Core rev: 946cd8df49a8873ff93ef5ec1e3cc745a21e2a8f)

(From OE-Core rev: 3c004856e460656e16739d6b68f5189ecf0746a7)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:53 +00:00
Matthew McClintock 25330d9f38 Fixup kexec-tools compatible host for powerpc
kexec does infact work and build on powerpc, enable the compatible
host for these machines

(From OE-Core rev: 1ccc1ec56bc50cee121c03ae8bb8ccacd32b8560)

(From OE-Core rev: c7afacf05deb8ca77818aa33ee13ec3a8c5d983f)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:53 +00:00
Richard Purdie c1c5eb6866 util-linux: Ensure perl scripts reference the correct perl
Without this change the perl path from the build system is used.

(From OE-Core rev: 18ad3a84dacc0d6c107b56874bb23d2a3c0a429f)

(From OE-Core rev: a20e75a83cd5998d7ed6ea7c0c4ea7039c22160a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:52 +00:00
Richard Purdie 51e089403a mc: Ensure perl scripts reference the correct perl
Without this change the perl path from the build system is used.

(From OE-Core rev: feff6030091d519a0738e2a5db47654dcd13ef13)

(From OE-Core rev: 077a85c4fa376b5e7ee826589bbd4fe6776a326f)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:52 +00:00
Richard Purdie 058ef489a0 openssl: Ensure perl scripts reference the correct perl
Without this change the perl path from the build system is used.

(From OE-Core rev: 1ed8fb66c51ce584c13e592176a69a61bae01f2e)

(From OE-Core rev: bc7da81942aa5676010d513407a2731bd385a165)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:52 +00:00
Khem Raj 3eb7e626d0 gcc-4.6: Update to tip of FSF gcc-4_6-branch
(From OE-Core rev: ed7deecb9503420fbf8071445e077c32beda8dc4)

(From OE-Core rev: 90e3aee700b8fff6d94f84850dfc00091b3777c9)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:52 +00:00
Andrew Gabbasov 386e75b7f0 apmd: use ${HOST_SYS}-libtool
libtool-cross uses ${HOST_SYS}- prefix while building and installing.
In some cases that may be different from ${TARGET_PREFIX}, that is currently
used in apmd recipe. It's better to have them consistent.

(From OE-Core rev: 5f1fac618fa099f6fc78cbc98f18d1c0ab792abf)

(From OE-Core rev: eda6005d2dfcf163f12e3c5cc447ea3ad495a0bb)

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:51 +00:00
Andrew Gabbasov f72a801d51 apr: use ${HOST_SYS}-libtool
libtool-cross uses ${HOST_SYS}- prefix while building and installing.
In some cases that may be different from ${TARGET_PREFIX}, that is currently
used in apr recipe. It's better to have them consistent.

(From OE-Core rev: 61cedb87446a27ddaaa880a5f3296399def441df)

(From OE-Core rev: 170d1fe5158eeb316009b2920b009da2c2dedae2)

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:51 +00:00
Andrew Gabbasov 4ffc32566a libpam: add flex-native to DEPENDS
flex-native is required for building libpam. Although this dependency
is now fulfilled indirectly through bison recipe, having an explicit one
would be preferable.

(From OE-Core rev: 14018608277fe62e2a662711ff6177c93e9bc153)

(From OE-Core rev: 3a8ca44cbd31411934b6c873f75f1fb49167f93c)

Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:51 +00:00
Paul Eggleton 3f692305dc scripts/oe-setup-rpmrepo: use setup_tmpdir from runqemu
Update the internal copy of setup_tmpdir in the oe-setup-rpmrepo script
to be the same as the one in the runqemu script.

(From OE-Core rev: 4a23c4dd5ab31d9642e5e49569d5c7ab77e97adf)

(From OE-Core rev: 2174746ca6f480eb6387d91f9b3faf2581e816d3)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:51 +00:00
Paul Eggleton 4ff17dc89d scripts: use OE_TMPDIR instead of TMPDIR external variable
On OpenSUSE within an X session, TMPDIR is set to the system temporary
directory (/tmp) which is incorrect for these scripts. Thus, change
runqemu and oe-setup-rpmrepo to use OE_TMPDIR from the external
environment rather than TMPDIR.

Fixes [YOCTO #1530]

(From OE-Core rev: 4e24c10952c7a52af7f2447595fd484692d35534)

(From OE-Core rev: 354497bf3e3bf68374875caa97d9b4fdcad74789)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Saul Wold 1a506c5dfd rpm: fix QA Warning on installed but not shipped staticdev filesw
(From OE-Core rev: 62ce8f96626e061e03ca49896716bbb133721ee0)

(From OE-Core rev: 59f80f70c5ff6c62143b7bad5a67d5508b388d29)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Simon Busch 84865e45ea meta: qt4: fix postprocessing of pkg-config files
When building qt4-embedded the generated and cleaned pkg-config files for qt are wrong.
The Cflags variable contains something like ${includedir}/qtopia/QtCore where
${includedir} is already /usr/include/qtopia/QtCore.

This patch reverts the fix up of the Cflags variable implemented in do_install.

(From OE-Core rev: b40b9c024be5e1ec81a31961158b3e6b529acfe0)

(From OE-Core rev: 960318ebd271ad5330a0863047927ab827b5e107)

Signed-off-by: Simon Busch <morphis@gravedo.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Richard Purdie ae97dbe1db pseudo: Fix QA warnings
This fixes two QA warnings:

a) Debug files being contained in the main package (by adding
   an appropriate FILES expression)
b) Stop hardcoding the RPATH in the nativesdk case since our
   path is on the loaders default search path

(From OE-Core rev: 1577975202437f8f89ef24a5e4d3f6c6c8a88c5c)

(From OE-Core rev: 0c345e7aa83196e55cd554a958690e4cc261ef16)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Richard Purdie edb2641243 sqlite3: Fix nativesdk packaging/QA warnings
When building sqlite3-nativesdk, there was a warning about debug files in the
main package. This was due to the order of items in PACKAGES with -dbg after
the main package which breaks an assumption native.bbclass makes. Changing
the order fixes the packaging problem with no change to the normal target
packaging.

(From OE-Core rev: 4f5fdc4dc14d287d301069024ddec9cb65d68f7f)

(From OE-Core rev: 8f2ff09f0da21e83ddfb8049bf7ddece94eb6893)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Richard Purdie c8635bab0b grub: Fix insane/QA architecture warning
There is QA warning about this package for an architecture mismatch but
this is inappropriate in this case since the bootloader needs 32 and 64
bit code. We therefore flag the QA check to be skipped.

(From OE-Core rev: 43723e19eb5a6119c7546dc812428e792999a928)

(From OE-Core rev: f31c0b804b04cd1ae9ea7251164fd1345697c72b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:50 +00:00
Richard Purdie cd50451812 gcc: Fix two QA issues
a) There is a QA warning from a .so being present in a main package.
   In the case of the plugin library for gcc, this is allowed.
b) Remove the unwanted libiberty.a file with the strange path. We
   don't need/want this and this removes an unpackaged file warning.

(From OE-Core rev: ca36a3edf9cede9fa0d73ba1a9538ab467cb5e3c)

(From OE-Core rev: 974677d32e0af74fab58d1b12b8d786b67323c5a)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Dmitry Eremin-Solenikov 877979c8b5 libffi: really populate -dev package
As per gcc PR 11147, libffi installs headers into a target dependent
place (/usr/lib/....). Include a rule to include those files into
libffi-dev package.

Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11147

(From OE-Core rev: 684a4b517d13884c315688967fadd5e6a4845b71)

(From OE-Core rev: 5cb756227b12e0d537430a527c51033572fb627e)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Dmitry Eremin-Solenikov f69eca96d1 gconf-dbus: packaging fixup
Behave more like plain gconf: include a dtd and .la files into -dev
package.

(From OE-Core rev: 9e962c1b4c8e5a3352f5e2b7dc162aeac1335b3a)

(From OE-Core rev: 53951cffc4253850b9b0d6e24f932a9106dfafef)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
lumag c0a8c9b985 gcc: include libgcov.a into libgcc-dev package
First, this lib is usefull for coverage analysis-enabled building.
Second, this fixes the warning about unpackaged files in libgcc recipe.

(From OE-Core rev: 2a807a98d8be3f486e703321773db32657c71d9e)

(From OE-Core rev: 651e6ee7d1ba729ed0bb5e9ede5975582d9941bf)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Dmitry Eremin-Solenikov 09ab224a2f gcc: fix possible problems with nscd compilation during eglibc-nativesdk build
Long time ago a066e7ca90a28d5681c5fa895a29e999ed7c88b was committed to
address possible problems with compilation of nscd during
eglibc-nativesdk build. Problems were related to the way gcc searches
for headers to check if it should enable it's own stack smash protection
bits or it can relay on eglibc for it.

However after 934d38530c9a67562e53d4034aee5531f0f26750 things got
broken, as for gcc-crosssdk-intermediate packages:
1) EXTRA_OECONF is ignored
2) headers are installed in a different location than expected by that
patch.

This results in eglibc-nativesdk build broken on some systems (e.g. mine
Debian x86_64 squeeze). Fix that by providing with-headers options to
crosssdk-intermediate gcc configuration.

(From OE-Core rev: 63494d638b7a9b88a5b7d7a02d2afcb3aa0fa064)

(From OE-Core rev: b4a686061f27f663321674fb42aa93dbd20c5b3a)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Dmitry Eremin-Solenikov 0e9001afd5 icecc-create-env-native: provide the script right in the tree
There is no point in downloading a tarball with no clear upstream (other than
icecc itself) and then patching it. Rather put new script in the source tree.

(From OE-Core rev: 409fa8ca4d37ad407faaa2a8935e9d2bb89776c9)

(From OE-Core rev: e68d1d5117be9631db644b70308e7360a9d76a3a)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Dmitry Eremin-Solenikov d63678cdfa bitbake.conf: change ccache path to use MULTIMACH_HOST_SYS
Currently if I build packages for several targets (e.g. for armv5te tosa
and for armv7a beagleboard) oe will use single ccache dir for both of
those targets: build/ccache/arm-oe-linux-gnueabi. However those targets
use different opcodes, different features and binaries created for one
of those targets wont't run on the lower one. So use MULTIMACH_HOST_SYS
for ccache dir, so that it uses something like
build/ccache/armv5te-oe-linux-gnueabi dir.

(From OE-Core rev: 982373006a98cf2303514badd1cfb692108408c0)

(From OE-Core rev: 9d460e31b6b45b30b39587503d655aa2a418cbc3)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Khem Raj 1af2581f0b gnome-doc-utils: Prepend PKG_CONFIG_SYSROOT_DIR to the path returned from PKG_CONFIG
If we build say gnome based image on a build system which does not have
gnome e.g. kubuntu then packages like gedit do not build since it uses
gnome files from host system which are non existent on kubuntu

(From OE-Core rev: 7b18b3c96634e40abf690a7ec72562389b0e6c23)

(From OE-Core rev: a413f3adcfb8245550067c1c2a3197817e631ffe)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Richard Purdie 9dcb176dc8 autotools.bbclass: Set the dynamic linker search path for libtool correctly
libtool obtains the search path from /etc/ld.so.conf and hardcodes /usr/lib
and /lib. This results in host contamination and variable sets of RPATH
values ending up in binaries.

By exporting the correct values for all autotools recipes we avoid this.

(From OE-Core rev: 93e595d5c89ebacdb8d1e6fcfe6f58fe2d30de28)

(From OE-Core rev: 5e41e0973a9be890ac310e1bbf465fcd08b0add5)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Zhai Edwin 64ba74deff matchbox: Upgrade SRCREV to reflect recent accpeted patches by upstream
(From OE-Core rev: 33a1a05ef988c69f8ff8e38c6723922082e5d1aa)

(From OE-Core rev: 1194935707f4acd9029b36769bc0320ba0a90163)

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Mark Hatle ff047d3a77 cups: Fix recipe to use the correct cups directories
${libdir} is not used, instead they use a common ${exec_prefix}/lib
directory structure for helpers, filters, renderers, etc.

(From OE-Core rev: 24ae432b1a3906956381d83c1984687e45c5a1d1)

(From OE-Core rev: 72da8109de9c2b1e237655706cdf4de447d38393)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:49 +00:00
Khem Raj b137421cfc eglibc-2.12: Fix build on powerpc/603e
We pass --with-cpu to eglibc now. Which breaks
the configure for cpus that it does not support
We add support for ppc603e which gets 2.12
building for qemuppc.

(From OE-Core rev: 465a988e2370ec377875b599045f2a7bad913ac6)

(From OE-Core rev: f6dbd42382d980d90f3e64a94178a0050af537cf)

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.12.bb
2012-01-30 16:37:48 +00:00
Dmitry Eremin-Solenikov 3a8590f105 gcc: include plugin-related headers into packaged SDK
Include headers necessary to compile gcc plugins into cross-canadian gcc
packages.

(From OE-Core rev: d12aa92b3dac1109d510e7b6f74055d1ab927817)

(From OE-Core rev: 51c96c98fca5a4a51cb38a6442ab9b4a03938721)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:48 +00:00
Dmitry Eremin-Solenikov 3571525ab8 e2fsprogs: include devtools scripts
Some scripts are necessary to develop programs with libcom_err and
libss. Include those into e2fsprogs-dev package.

(From OE-Core rev: 46332c2313abb273f6fc889fac4daa91cf43faa3)

(From OE-Core rev: f1f22acd15591e5394254441c4364899875a0fbc)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:48 +00:00
Dmitry Eremin-Solenikov 204762c531 glib-2.0: include glib-gettextize stuff
glib-utils already includes glib-gettextize program. Include some files
necessary for glib-gettextize to work.

(From OE-Core rev: c98356e9c46cd28b7ca8e84fe0ea56dc6d812a8d)

(From OE-Core rev: 0f0d5c7d980400bb45e78b7f178844c5a6dbf630)

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:48 +00:00
Daniel Lazzari 394d340ab1 alsa-lib: Don't use versioned symbols on uclibc builds as it causes strange hangs
alsa-lib: Don't use versioned symbols on uclibc builds as it causes strange hangs. Taken from oe-classic.

(From OE-Core rev: b354eb957ce08ac7814ce46c13ca3a8449b4063a)

(From OE-Core rev: 16852546234a252103337414fe536a3b97443539)

Signed-off-by: Daniel Lazzari Jr <dlazzari@leapfrog.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:48 +00:00
Bruce Ashfield 4bf5435d95 linux-yocto: v3.0.10 + rt27
Updating the BSP base to the kernel.org v3.0.10 baseline and importing
the latest stable rt27 release.

(From OE-Core rev: e8aa8fe6e299104d4eb6da16134272a1dc7e929b)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:47 +00:00
Bruce Ashfield 05dba88379 linux-yocto: change SRC_URI to 3.0 maintenance kernel
The 3.0 yocto kernel is updated for both new feature development
and for maintenance purposes. The maintenance kernel repository
takes updates once they have been applied to the development
repository and have been deemed safe/suitable for point releases.

(From OE-Core rev: 0b6eedfe26fca031e84543cab92b20e121364fb7)

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:37:47 +00:00
Paul Eggleton 1ab5a6851d README.hardware: declare support for BeagleBoard xM rev B
The BeagleBoard xM revision B has been tested (by me, if nobody else.)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2012-01-30 16:30:14 +00:00
Paul Eggleton 781866f64e README.hardware: update atom-pc instructions
The -live and -directdisk images have been superseded in the Yocto
Project 1.1 release, so update the instructions for atom-pc relating to
this change. Also fix a couple of other minor atom-pc related
capitalisation.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2012-01-30 16:29:43 +00:00
Joshua Lock 702c428804 poky: set linux-yocto-rt preferred version for qemu machines
Signed-off-by: Joshua Lock <josh@linux.intel.com>
2012-01-30 16:19:24 +00:00
Xiaofeng Yan 5882121a94 local.conf.sample.extended: Fix bug 1674
[YOCTO #1674]
local.conf.sample.extended: An image based on gtk+-directfb don't need x11 for DEFAULT_FEATURES

Remove "x11" from DEFAULT_FEATURES and add "directfb" to it because someone could don't need x11 in their project, perhaps
gtk over directfb will meet his reqirement.

(From OE-Core rev: 5def790bdecd2726692b40a57bc12c8bdfea9179)

Signed-off-by: Xiaofeng Yan <xiaofeng.yan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:19:15 +00:00
Joshua Lock 6c2f754a0a machine/atom-pc: enable sound
Add alsa to the MACHINE_FEATURES - looks like this was an oversight.

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:19:06 +00:00
Joshua Lock acd0bedbce ui/crumbs/hobprefs: trigger a reparse after changing IMAGE_FSTYPES
As reported on the mailing list[1] when changing IMAGE_FSTYPES through the
hob preferences a reparse is required before the changes will be picked up
by the system. This patch sets the reload_required property of the class to
true when the image types have been modified to ensure the reparse is
triggered.

1. https://lists.yoctoproject.org/pipermail/yocto/2011-December/006002.html

(Bitbake rev: 6c0babf08909307ab69a66ed06e77e8818b2a8c5)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Joshua Lock 90f8d53800 ui/crumbs/runningbuild: handle InvalidTask events
The knotty UI just ignores these and so should RunningBuild, if these events
aren't handled the UI appears to hang.

Fixes [YOCTO #1665]

(Bitbake rev: 540ba78075bd525776aa23bf38bee66350c66534)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Matthew McClintock 23c6b49566 siggen.py: If both sigs have a variable in it's whitelist then don't say it's changed
Some BB_HASHBASE_WHITELIST variables are in the lists of variable
dependencies for signatures. Ignore those differences in lists
since this difference does not matter

(Bitbake rev: 71b53a3f0766ca464560a1f6a449f9424fbdf7ae)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Robert Yang f204d16012 bitbake: Update and fix bitbake-runtask
Since bitbake switched back to the fork instead of the exec model,
it no longer used bitbake-runtask and the code has suffered some bitrot.
bitbake-runtask is a useful tool for excuting the task without
the scheduler of bitbake, so that the external tool can invoke it
easily. It also provides a useful example of how to invoke exec_task()
with low overhead without a lot of the bitbake threading/UI overhead.

Significant changes:

* This patch changes the argument order so that the commonly used
  and mandatory arguments come first.

* The taskhash file and dryrun options are now optional

* It now uses the bitbake logging mechanisms to provide processed
  logging output to the console.

* The process handling to do with stdout/stderr redirection
  are removed since they're no longer required.

[YOCTO #1229]

RP: Logging updates to the patch based on Roberts original patch
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Richard Purdie 3796541746 bitbake/siggen.py: Don't backtrace if the taskhash data isn't present
This allows the code to safely fall back to dumping the basehash data
if the taskhash data isn't present for some reason. We could effecitvely
obsolete the runtime option and use this approach instead exclusively.

(Bitbake rev: 5ace320ccc01f4e326f90b7ba060dcbff3380dca)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Richard Purdie 0e676f74c5 build.py: Be determistic about a function's cwd
There is a subtle but nasty problem that a function's cwd can vary
depending on whether ${B} (often ${S}) exists before the funciton is
called or not. Most functions in the system can cope with this but
its bad practise and I've just witnessed build failures resulting
from this during image generation from bootimg.bbclass. I also
suspect this could explain some odd fetcher behaviour witnessed in
the past.

This change ensures we always call funcitons with a specific build
directory making things deterministic.

(Bitbake rev: ef0888f83fa4408eb768257d7e03700202faad18)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Richard Purdie 26666187e3 cooker.py: Allow the -e option to work with virtual classes and -b
Using bitbake -e -b virtual:xxxx:/path/to/the.bb would result in
zero matches since the virtual:xxxx piece wasn't being processed.

This adds in the necessary functionality to handle it correctly.

[YOCTO #1793]

(Bitbake rev: bd5a727c8447bcb747c1d2463b7de2ab6d21a7de)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Matthew McClintock c270f92b08 Nothing uses USERNAME, remove it - can cause sstate-cache conflicts
USER is the correct variable to use, also this can affect sstate
cache as well.

(Bitbake rev: d7f9edda65dae2e046871afa275c5a51dff48fc4)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Christopher Larson 1670051a79 codeparser: silence non-literal warnings for vardeps
If the vardeps flag is not None, we now silence the warnings about
non-literal usage for that variable.

(Bitbake rev: e724b9f417d1baf898f5afc6376c73c1a2ad8db9)

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Christopher Larson c61f04c34e codeparser: drop expand tracking
There are two usual cases involving bb.data.expand:

- Calling it with a string literal -- "bb.data.expand('${FOO}/${BAZ}/bleh', d)".
- Calling it on getVar results (legacy) -- "bb.data.expand(bb.data.getVar('FOO', d), d)"

Nothing in any of the usual layers uses it in any other way, and I'm
having trouble coming up with any real use cases beyond this. The first
of the above cases is already tracked, via the expandWithRefs called
on the python code string. The second didn't emit a warning anyway,
since the getVar was already handled.

Given this, I see no reason for us to maintain explicit expansion
tracking. Further, we weren't using its results anyway (the var_expands
member).

(Bitbake rev: 405dfe69e6a608826e599ebf2f83ef8cf5083b96)

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:13 +00:00
Christopher Larson 2b26745c70 codeparser: accept a name for better messages
- If a name is passed to the parser, prepend the messages with "while
  parsing <name>:". This gives a bit more context.
- Tweak the warning messages slightly (they had to be altered anyway to
  inject the variable being parsed).

Before:
  DEBUG: Warning: in call to 'bb.data.getVar': argument ''%s' % var' is \
         not a literal

After:
  DEBUG: while parsing emit_pkgdata, in call of bb.data.getVar, argument \
         ''%s' % var' is not a string literal

(Bitbake rev: 1060193ae4d54e667735dbff5d1d2be49a3f95c9)

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Christopher Larson 28ca6cc34b codeparser: simplify how we compare the called node names
With the previous method, using the compare_name methods, we split the
requested match name by '.', reversed it, then compared them piecemeal
during the node traversal. The new method walks the nodes and hands back
the name of what's being called, and then we check that. This also
consolidates the two different implementations of traversal of the
attribute/name nodes (one in compare_name, one for the execs).

(Bitbake rev: 84e535b5165c7e936c5b1486bdf4626ed3649f5f)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Christopher Larson ada59bde67 codeparser: merge the nested python parsing classes
The split is even less necessary now that we use ast.walk rather than an
actual NodeVisitor subclass.

(Bitbake rev: d6c44fac184abae8395bfa7078f06675218aa534)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie 9a68fb1364 data/siggen: Add vardepvalue mechanism to allow the variable dependency code to be forced to specific values
We have a problem if we want to inject specific information into the variable
dependency code. There are cases for example where we want a dependency
on the value of X but it doesn't matter how X was constructed or what
dependencies it might have had, we only care about the absolute value.
With the current code, its near enough impossible to do this.

This patch adds such a mechanism so the user can trigger this with code like:

baselib[vardepvalue] = "${baselib}"

It also refactors some of the code so we do variable lookups once
instead of doing this in two different functions.

[YOCTO #1583]

(Bitbake rev: 6c879b44ccf42dc73fe4467076e114700d7ba81b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie f87c92143e fetch2: Improve uri_replace to handle paths with no trailing '/'
Currently if you specify a mirror like:

file://.* http://linux.freescale.net/yocto/sstate-cache

it won't work as you expect whilst:

file://.* http://linux.freescale.net/yocto/sstate-cache/

will since it has the trailing slash.

This patch handles both cases correctly. It also adds some debug to
the uri_replace function since its near impossible to debug it without
some kind of output.

[YOCTO #1578]

(Bitbake rev: a0246bf09c93bb657eaf6ba61d090b247ed33640)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie f38e44bbb2 runqueue.py: Fix debug message to reference the correct task
(Bitbake rev: 035c673c463ca450245acf824e7b7e8f889bdc89)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie 4d7f50382e fetch2/local: Don't default to files in DL_DIR for file:// urls
Defaulting to any file in DL_DIR as the first match for a file:// url
doesn't make much sense and can lead to unexpected results.

This patch changes the logic so this is the last fallback location
instead. Whether it should be using DL_DIR at all for this is a
good question but something for another patch.

[YOCTO #1710]

(Bitbake rev: 5597a68fac0954c682b67471722c2643e2415f99)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Matthew McClintock 6803d97bdb siggen.py: sort task hash depedencies with basepath
Without this patch the tash hash dependencies can be in a order
that is dependent upon directory/filesystem layout. With this
change the data is sorted the same regardless.

Without this the dependent hashes could be in different orders
on different systems and consequently final md5 hash would differ
as well even though nothing else changed.

(Bitbake rev: 9a2029899c946ce9aa8adbc85f2cfe7a85b92182)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Matthew McClintock 81ed10442b bitbake: print out symmetric difference when comparing sigs
This is useful for really longs lists to pinpoint what has
actually changed

(Bitbake rev: f1eb6d3dcc10c42bb09383a87bde3afa69bc6ed9)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie 1a46002fad runqueue.py: Ensure we fully process the covered list
The existing looping code can mask an existing "found = True"
by forcing it to False each time. This can lead to dependency
lists not being fully searched and results in dependency errors.

An exmaple of this was the autobuilder building linux-yocto from
sstate but then rebuilding some of the recipe's tasks for no
apparent reason. Separating the logic into two variables solves this
problem since any "found = True" value is now always preserved.

(Bitbake rev: 61017fc5d30b7a13308d038872ec92efc1a84cef)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie 2747b2003e runqueue.py: Ensure setscene tasks don't break dependency order
If A depends upon B which depends upon C and the setscene for B
succeeds but C is going to get rebuilt, we should wait for C to
try and build A but currently we don't.

This is due to the timing of when we run the task_skip() as this
triggers other tasks to become buildable. This patch moves the timing
of that call to a more appropriate place allowing dependencies to
behave as expected.

(Bitbake rev: b7114d8e5d9b0720339bd5d24d243c0f2a7c1f3b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:12 +00:00
Richard Purdie 375297ea28 bitbake/runqueue.py: Sort the list of skipped tasks as it makes searching the list easier when debugging
(From Poky rev: 5de8a495fba657e1febc616bbc737a8136cc88f9)

(Bitbake rev: 110f6cccbcc5907e15262c05d5c47da101e1a47d)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Richard Purdie c2662a5095 bitbake/runqueue.py: Fix incorrect task number reference in debug message
(From Poky rev: 45887bbd5479041be05b914668f14de6ec9b9831)

(Bitbake rev: dc4439ca8c7db7ceee78bd0552f65ceddcff17a7)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Richard Purdie da56e3df88 parse_py: Use absolute paths for FILE
Its possible for relative paths to creep into FILE. These confuse the
build system no end as its not clear where they might be releative to.

This patch ensures we always use resolved absolute paths for FILE
so that things behave in a deterministic way.

(Bitbake rev: 658d7daa70e46c2b20973b90ee53f0bbadc8bf5d)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Richard Purdie 388dbe4928 siggen.py: Include list of variables in hashes
Ensure that the list of dependencies is included in the hash
as well as their contents

Prior to this, adding or removing dependencies with values
of "None" would not change the hash, despite diffsigs reporting
this difference.

(Bitbake rev: 727ca945177ce9bd44515cf611e3e95a09466d98)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Richard Purdie dbcce81f66 siggen.py: Fix diffsigs output for filename comparisions
When comparing sig files, if the recipe locations had changed, the
dependent tasks list would show as changed even if the actual hash
had not changed. This updates the code to only compare the base part
of the pathnames.

It also tweaks some of the output to add newlines to aid comparing
two lists of variables as it makes the location of the difference
clearer.

(Bitbake rev: 165a22ddcc647b945707fb5c483146bb336d5f66)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Christopher Larson 46ac868403 codeparser: make var_expands actually hold useful information
Previously, it was calling var_expands.update() rather than add(), with
a string argument, resulting in adding each character of that string to
the var_expands set, rather than the string itself.

(Bitbake rev: 8e4e75383e43d6da2c16ec5286186a0d0569b0f8)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Paul Eggleton 6e1105e1e8 lib/bb/runqueue: avoid marking runtime dependencies as covered
The code which populates setscene_covered list was adding a task to the
covered list if all of the tasks that depend upon it were also covered;
however, this means that tasks that would have installed "runtime"
dependencies were being marked as covered also, e.g. gmp-native and
mpfr-native are needed by gcc-cross at runtime since they are shared
libraries that gcc links to, but their do_populate_sysroot tasks were
being marked as covered, resulting in failures later on if gcc-cross was
available from sstate but mpfr-native and gmp-native weren't.

Since we currently have no real way to handle runtime dependencies for
native packages, add a workaround which avoids marking tasks as covered
if one or more of their revdeps are from a different recipe.

Fixes [YOCTO #1536].

(Bitbake rev: e492eb4dc9016cd0bed194377c6f2b85cf0ad113)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Richard Purdie 4494f59a26 utils.py: Fix lockfile retry handling
The lockfile retry parameter is expected to return immediately after
attempting to take the lock. There was a bug in the logic which this
patch fixed to ensure it does that.

(Bitbake rev: f421ef819f00ac659504d9af41bcc8323422ff8c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Joshua Lock 13590b23c6 hob: fix backtrace when dismissing open dialog
Clearly a logic/indentation error - we should only try and load the recipe
should the file-chooser return OK.

Fixes [YOCTO #1668]

(Bitbake rev: db59297aa1861614ffaea4295b9b054baa8a12b9)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Matthew McClintock 2c3861ee68 fetch2: Export additional variables to the fetchers
git could need these environment variables when working behind
a proxy

(Bitbake rev: dca46cc2e1c75b6add2c4801e2994a4812745f5b)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Matthew McClintock 9cf7aabecf fetch2/git: Make git fetch run with -f so rebased branches don't fail
git fetches can fail (or at least return failed) when trying to
fetch and prune rebased branches. This patch simply adds a -f
to the git fetch command so these failure are ignore

Generally, if some SHA was rebased away it's not coming back so
there is no point in not doing this force

(Bitbake rev: a7b75e4db52445b30ec0fc0053dcf454f5f7d2db)

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:16:11 +00:00
Scott Rifenbark 81d1a4aadf documentation/Makefile: new 'edison' variable for YP dev manual.
I discovered that the figures used in this manual differ depending
on the branch.  There are two figures that are different.  Thus,
the TARFILES variable in the makefile needed to be conditionalized.
If it is not, then the process that makes the tarball throws errors
because it cannot find the two figures from the other branch.

To fix this I introduced the 'BRANCH' variable.  It is to be used
only when you make or publish the YP Development Manual.  And, you
only use it to specify 'edison'.  If you are building from the 'master'
branch you don't need to use it.

Comments in the file have been updated to explain usage.

(From yocto-docs rev: 0341b19f75176fd4133fd66cb5536b765edf0294)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:03 +00:00
Scott Rifenbark 6578845f69 documentation/Makefile: fixes for missing tarfiles
I had added some edison-specific figures and they needed to
be included in the TARFILE variable for the YP development manual.
The fix now makes the TARFILE variable all-inclusive for all
.PNG files regardless of branch.  Consequently, there can be
some missing files when the manual is made but the errors are okay.
I documented the exceptions above the variable.

(From yocto-docs rev: be731afde47dfc85da6ba88f93910899ec259e87)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:03 +00:00
Scott Rifenbark b5a4e78df5 documentation/dev-manual/dev-manual-kernel-appendix.xml: edits to example
Poor flow for the config_smp example.  Upon reading this example
it did not stand well on its own.  I added some text, albeit
redundant but necessary I felt, so that the example would stand on
its own.

(From yocto-docs rev: 1677a873e9bd1124a5ff0234edc1ee05938c19b0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:02 +00:00
Scott Rifenbark 68b55c1e85 documentation/dev-manual/dev-manual-kernel-appendix.xml: Fixed repo name
I left "work" off the name of the copy of the clone repo
for the kernel example.

(From yocto-docs rev: 26f3dd9c82beb3c8d6e50c2132756bdb4b29b56d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:02 +00:00
Scott Rifenbark 4234beb034 documentation/dev-manual/dev-manual-kernel-appendix.xml: branch info added
The example now uses an edison branch of the poky-extras repo.
Now that that is necessary, there needs to be explanation in the
example on setting that branch up after creating the local
repository.

(From yocto-docs rev: 70599a07a6efb0ae2da04baa43b5bb99c9ec4e5d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:02 +00:00
Scott Rifenbark ddb5143d9d documentation/dev-manual/dev-manual-model.xml: updated figure
Because the names of the bare clone and copy of the bare
clone kernel repos changed in the example this figure needed
to be altered.

(From yocto-docs rev: e49ec4256bd9fe9f1193b70f8a5ab864c069c863)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:02 +00:00
Scott Rifenbark 25dcd673f5 documenation/dev-manual/figures: Figures altered.
Changing the name of the bare clone and copy of the bare
clone for the appendix A (kernel) example affected this
figure of the file structure.  I updated the figure, which
is now specific to 1.1.x and added it.  I also had to remove
the figure that will now be specific to (master) work.

(From yocto-docs rev: 048af1a6945991c66abef72de05c136e8071a9e5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:02 +00:00
Scott Rifenbark 1ad7977742 documentation/dev-manual: Changes to repo names and kernel example.
To make the kernel example more easily understood, Joshua Lock
suggested that the names used for the bare clone of the kernel
git repo and the copy of the bare clone be more different.  So
I have changed the example such that the bare clone repo is
named linux-yocto-3.0-1.1.x.git and the copy of the bare clone
(or working repo) is named my-linux-yocto-3.0-1.1.x-work.

Note that this also implies the use of the linux-yocto_3.0-1.1.x
kernel and not the linux-yocto_3.0 kernel.

All the changes made here should take care of the example.  I
did have to introduce a new figure that showed the kernel
repos based on the new names used in the example.  Also, I had
to delete the other from this branch.  The examples are now
diverging according to (master) work and 1.1.x work.

Reported-by: Joshua Lock <joshua.lock@intel.com>
(From yocto-docs rev: f4fdef6078fccfc2c72b6e0ad1dfae1f1ecb2aa6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:01 +00:00
Scott Rifenbark fe40f117c1 documentation/poky-ref-manual/faq.xml: Fixed links to python
The links to the 32-bit and 64-bit Python tarballs in
miscsupport were broken.  I fixed them.

(From yocto-docs rev: 6dd820fe8e3d22329a4d6e4edcbba72bf70841c4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:01 +00:00
Scott Rifenbark 0550d8c73e documentation/dev-manual/dev-manual-newbie.xml: updated download link
Found a link that was still yoctoproject.org/downloads.  I changed
to downloads.yoctoproject.org.

(From yocto-docs rev: 26c87f543c95efcd7e5a546b3cd0d0756a238fa5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:01 +00:00
Scott Rifenbark bc821a2ab5 documentation/adt-manual/adt-command.xml: Corrected wording for setup
Bad wording fixed to describe the changes to PATH when the setup
script is run.

(From yocto-docs rev: 95c6049995e8b51a46ba7fba57fcc240b6baeaaf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:01 +00:00
Scott Rifenbark aa72ed0b23 documentation/adt-manual/adt-eclipse.xml: Fixed yoctotools reference
The menu for the YoctoTools in Eclipse moved from underneath
"Windows" to the top level.  I fixed the reference to reflect
that change in the GUI.

(From yocto-docs rev: 89830569107200f89d78e0b32b98429a947abe36)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:01 +00:00
Scott Rifenbark e0a2bbd2a4 documentation/adt-manual/adt-eclipse.xml: Fixed menu reference
I changed the wording in an example to use "menu" instead of
the incorrect "navigator pane".

(From yocto-docs rev: d2ce174e8e427c279d90197eb896e1f4df183196)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:00 +00:00
Scott Rifenbark 1a2454fcba documentation/adt-manual/adt-eclipse.xml: Added more info for example.
I added a bit more information to the third step of the
example that reconfigures a project.

(From yocto-docs rev: d30a83e4f62015cbaba9e2532b7e69d1908dfb50)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:00 +00:00
Scott Rifenbark 92675a93ba documentation/adt-manual/adt-eclipse.xml: Removed redundant link
I removed a redundant link to the QS manual.

(From yocto-docs rev: 20c898194511bd943ca2a93b1a4caad0466fccd9)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:00 +00:00
Scott Rifenbark 1bafc89431 documentation/adt-manual/adt-eclipse.xml: Updates to plug-in install
I worked through these methods and discovered a bit more on how
they actually work and when the user would use a given method.
The updates reflect this new knowledge.

(From yocto-docs rev: 346652df7a3423b82a10d41aa2d7dcddb803ad6f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:06:00 +00:00
Scott Rifenbark dc785b64c1 documentation/adt-manual/adt-package.xml: Fixed reference to manual.
Removed redundant link for referencing a section of a different
manual.

(From yocto-docs rev: 44f4df93ead5c8d48dd536355770919871bdc283)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:59 +00:00
Scott Rifenbark 257dbe8d39 documentation/adt-manual/adt-prepare.xml: Updates for 1.1.1
These changes reflect working through the chapter using the
1.1.1 release.  Several areas needed tweaking.

(From yocto-docs rev: 566b8a492e502e88a1404f833db140a6408da592)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:59 +00:00
Scott Rifenbark c81c4cb0c7 documentation/poky-ref-manual/ref-variables.xml: PDF formatting fixed.
In the PDF version of the reference guide there were several glossary
variables that did not format correctly.  The issue is that the two-
column list had instances where the variable name overruns the
variable description.  I added an extra line return for these cases.

(From yocto-docs rev: f3ff26568b371807986e4ba77fe41cba6875efcc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:59 +00:00
Scott Rifenbark da3edbd85b documentation/adt-manual/adt-prepare.xml: added unpacking text
I added text to show how to unpack the generated ADT Installer
tarball.

(From yocto-docs rev: b0cf4554d3dde3a018f8f7901162474cb423ea12)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:59 +00:00
Scott Rifenbark 44aa4f320a documentation/adt-manual/adt-prepare.xml: update link to get ADT inst tarball
(From yocto-docs rev: b034cda6c18fc350636554b5ff8a4a89f503308d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:58 +00:00
Scott Rifenbark 38dbccd997 documentation/adt-manual/adt-intro.xml: Fixed broken perf link
(From yocto-docs rev: 13ddf9ab19f55e5f204ffa78180d89c47d51155f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:58 +00:00
Scott Rifenbark 6c27a7b50e documentation/adt-manual/adt-prepare.xml: Updated 6.0 to 6.0.1
Changes for the 1.1.1 release.

(From yocto-docs rev: 42ffeb43ea315b14e8b4668d3ab5ff8a16f1e7ac)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:58 +00:00
Scott Rifenbark 7ef3bc97b7 documentation/dev-manual/figures/kernel-example-repos.png: update figure
The figure that shows the kernel repos needed the git push
command fixed.  There was no ":" character in it.

(From yocto-docs rev: 69874766764788f08dc448b9835d41b6c67fcd8a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:58 +00:00
Scott Rifenbark 807b96f882 documentation/bsp-guide/bsp.xml: updated crownbay file structure
The file hiearchy was stale for the meta-crownbay examples in
recipes-graphics.  I updated in two places.

(From yocto-docs rev: a16bf8ae56efb907a50fbe4c16be0adfeec5c275)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:57 +00:00
Scott Rifenbark 2add98ffc8 documentation/bsp-guide/bsp.xml: Updated linux-yocto_3.0.bbappend example
This example had gone stale.  I cloned the meta-intel repo and
copied the edison branch version of the file into the manual.

(From yocto-docs rev: 963c53157f147c556cc4317f68fafeb0650268cc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:57 +00:00
Scott Rifenbark ed7fe93178 documentation/dev-manual/dev-manual-kernel-appendix.xml: menuconfig update
The example that shows menuconfig and where the .config file is
was updated to show the use of linux-yocto-3.0 kernel.

(From yocto-docs rev: a9f7a73842b428242da95f3dfe6a7b31c123ebc2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:57 +00:00
Scott Rifenbark 397081ef41 documentation/dev-manual: Updates to index of releases
Had to update the figure again and I updated the surrounding
text.

(From yocto-docs rev: d3a0cb2b24dabdf4a022a7426aeb2b80b40ae544)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:57 +00:00
Scott Rifenbark 570eeea297 documentation/dev-manual/figures/index-downloads.png: updated picture
Updated the picture that shows the index of releases.  they renamed
this from index of downloads.

(From yocto-docs rev: 098648434311bbe6de68fbbf89486ee1f9c0e4ec)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:56 +00:00
Scott Rifenbark b9232eb2b4 documentation/dev-manual/dev-manual-kernel-appendix.xml: cleared up note
There is note instructing the user to delete unused .bbappend files
or comment out the COMPATIBLE_MACHINE statements in those unused
files before running the build in the example.  the note was not
clear about the COMPATIBLE_MACHINE statement in the .bbappend file
that is actually being used.  I edited the text to be clear about
that.

(From yocto-docs rev: 44277b9c5d8a77958a4220fa790bc13e9ce697b3)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:56 +00:00
Scott Rifenbark 405578286d documentation/dev-manual/dev-manual-bsp-appendix.xml: hddimg size updated
The 'dd' example needed updating for the output that shows the
size of the image.

(From yocto-docs rev: f7cee3f3b9ccf2760de182b3d545e8d53ef83786)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:56 +00:00
Scott Rifenbark 1c937b6359 documentation/dev-manual/dev-manual-start.xml: updated to clone output
Updated the console output created when you create the bare clone
and the copy of the bare clone.

(From yocto-docs rev: 73130ec4a785417c5b8a91c0b577ac3681562b77)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:56 +00:00
Scott Rifenbark 567200dcf2 documentation/dev-manual/dev-manual-start.xml: poky-extra output updated
I updated the console output returned when you set up the
poky-extras repo.

(From yocto-docs rev: f4a6bea21df8dc6df1c30288a6ea93218e7d614d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:56 +00:00
Scott Rifenbark b4f5708c05 documentation/dev-manual/dev-manual-kernel-appendix.xml: General Edits
Better wording for the "Local Yocto Project Files Git Repository"
bulleted item.

(From yocto-docs rev: 03dea8208ba641efdfc9d1fa1d9afddc8c659cbf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:55 +00:00
Scott Rifenbark b8cb28fc2f documentation/dev-manual/dev-manual-bsp-appendix.xml: dd example updated
After building the BSP example the dd example command is being updated
with new image.

(From yocto-docs rev: ed9dc2a1af1c1160d03b0b12f06c91028120f177)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:55 +00:00
Tom Zanussi 495d37ab0b documentation/dev-manual/dev-manual-bsp-appendix.xml: BSP example scrub
As Reported by Robert P. J. Day.

Robert was working through this BSP example in the development manual
and ran into some problems and some confusion in areas.  This launched
a long "help-desk" session with Tom Zanussi.  In addressing Robert's
issues, Tom decided to make a run through of the example as it was
written.  For the most part the example was sound but needed some
technical tweaks as well as some expansion of the text to make things
clearer.  Tom submitted the patch that addressed these concerns.

Scott Rifenbark reviewed the patch and further modified some of the
writing to make it consistent with the existing writing in the manual.

(From yocto-docs rev: b95b9077bce1de55da4c0fc6208e2f2dac10c1e5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:55 +00:00
Scott Rifenbark 9d60cb9450 documentation/dev-manual/dev-manual-bsp-appendix.xml: recipes-bsp example
For some reason the example for the "Changing recipes-bsp" section
mysteriously had the wrong first command in the example to prepare
this stuff.  The example was removing something in the recipes-graphics
area.  Don't ask me how it got there.  I checked through the commits
in the Edison branch and can't find the change.  It could have happened
during 1.1.1 scrub.

Anyway, I have fixed the 'rm' command to be appropriate for the
example, which works with recipes-bsp.

(From yocto-docs rev: a53d46b5f0dbbdfac902abc5844085bee3aeb6d9)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:55 +00:00
Scott Rifenbark 5592e80877 documentation/dev-manual/dev-manual-start.xml: update meta-intel output
Verifying the 1.1.1 release and creating the local repo of meta-intel.
The console output is significantly different.  I have updated the
returned console output.

(From yocto-docs rev: 653e1214861e98501d37543403c5324c4d153112)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:54 +00:00
Scott Rifenbark 979ecf3eea documentation/dev-manual/dev-manual-model.xml: Updated machine link
Found a couple more occurrences of old links to the machines
area of the downloads.  Fixed them.

(From yocto-docs rev: 276352d49612bf77ed9e828c54bc1bc008345839)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:54 +00:00
Scott Rifenbark 770f5bb229 documentation/dev-manual/dev-manual-model.xml: Updated machine link
Changed a couple of links for the yocto-1.1.1/machines area.  These
links were old and pointing to yoctoproject.org/downloads.  They
are now changed to http://downloads.yoctoproject.org/releases..

(From yocto-docs rev: cee9d5eb0b095ba647411abaf12f591e216e461f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:54 +00:00
Scott Rifenbark 44211ed500 documentation/dev-manual/dev-manual-model.xml: Fixed external link
Found a link that had a spacing problem and should not have
been linking to the manual in general.  Fixed the spacing problem
and removed the links to the book in general.

(From yocto-docs rev: 0894e05dfa59b08f5c4e29a5aafbc2e5487f442c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:54 +00:00
Scott Rifenbark ac715efc14 documentation/dev-manual/dev-manual-newbie.xml: Fixed broken link to Git
Found another broken link to the Git documentation.  They must have changed
this stuff up.  So I set the link to point to the appropriate area in
the Git Community Book.  Talks about distributed workflows.

(From yocto-docs rev: b668c8c65fdc51e0100e9ddd1c54e4926579bbe2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:54 +00:00
Scott Rifenbark b256ae8f80 documentation/dev-manual/dev-manual-newbie.xml: fixed broken link
there was a link to some Git documentation referencing workflows that
apparently had gone stale.  I replaced the reference with a link to
the Git Community Book.

(From yocto-docs rev: 3a21f7454ec04e082d58646eecc1cffe3caa046c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:53 +00:00
Scott Rifenbark fa969ffb59 documentation/dev-manual/figures/git-workflow.png: Updated figure flow
The Git Workflow was missing a pull line from the second (bottom) contrib
box into the project's master Git repository.  I added the line.

(From yocto-docs rev: 3988e0197a7e3a6cde647f01da9ae41fd9465c75)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:53 +00:00
Scott Rifenbark e67311606e documentation/dev-manual/dev-manual-start.xml: top-level dir fixed
Changed the top-level directory created from unpacking the
edison-6.0.1 tarball from 'poky-1.1.1' to
'poky-edison-6.0.1'.

(From yocto-docs rev: 7af332806f1f4952f8e7672243d077e4ecde7fc5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:53 +00:00
Scott Rifenbark b17aecd70a documentation/dev-manual: Fixed 6.0 to 6.0.1 for 1.1.1 release.
Needed to change the "6.0" occurences to "6.0.1" in the examples.

(From yocto-docs rev: d6b40b3b0e98eba7f3221e79cb9612f8f10bffaf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:53 +00:00
Scott Rifenbark 1cb265f575 documentation/yocto-project-qs/yocto-project-qs.xml: update to pre-built
The pre-built section had a couple errors I discovered while trying
to verify the 1.1.1 release.  One is a wording problem putting the
last set of commands into context.  the other is that i needed
i586 as the expanded environment file in /opt/poky.

(From yocto-docs rev: d173f82e3e368b54889d6c1aa9bd51340e7e42be)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:53 +00:00
Scott Rifenbark 31b7cac818 documentation/yocto-project-qs/yocto-project-qs.xml: 6.0 fixes for 6.0.1
Updates to 6.0 to make them 6.0.1 for the 1.1.1 release.

(From yocto-docs rev: 19c8fb554c620d78edc7a0330e76e31a2a374ad2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:52 +00:00
Scott Rifenbark 05738313c3 documentation/yocto-project-qs: Updates for 1.1.1 Release
Decision made to treat every release like a major release.
This caused a scrub through the manual for the string "1.1"
and "6.0" and changed to "1.1.1" and "6.0.1".

(From yocto-docs rev: 3bd37946985b5a38860a61887d0bac4930c7cde1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:52 +00:00
Scott Rifenbark 25cf1a65ec documentation/poky-ref-manual: Updates for 1.1.1 Release
Decision made to treat every release like a major release.
This caused a scrub through the manual for the string "1.1"
and "6.0" and changed to "1.1.1" and "6.0.1".  Also the
release date changed to 17 February.

(From yocto-docs rev: 893d347409543cc690ab40b06384d4a0b1519ac0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:52 +00:00
Scott Rifenbark 442730168e documentation/kernel-manual: Updates for 1.1.1 Release
Decision made to treat every release like a major release.
This caused a scrub through the manual for the string "1.1"
and "6.0" and changed to "1.1.1" and "6.0.1".  Also the
release date changed to 17 February.

(From yocto-docs rev: 23938e6066b214aaba2e84fe4521504ad7f89b58)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:52 +00:00
Scott Rifenbark 2ca5c8c03e documentation/bsp-guide: Updates for 1.1.1 Release
Decision made to treat every release like a major release.
This caused a scrub through the manual for the string "1.1"
and "6.0" and changed to "1.1.1" and "6.0.1".  Also the
release date changed to 17 February.
(From yocto-docs rev: 8438b152ba13dab079b3918fecc418be5ddc19c0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:51 +00:00
Scott Rifenbark fa056279ea documentation/bsp-guide: Updated History table for 1.1.1 release.
(From yocto-docs rev: 0973325ae77fe6bdbf2fa6833005df2f7b0b554e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:51 +00:00
Scott Rifenbark 7ec098bedc documentation/adt-manual: Updates for 1.1.1 Release
Decision made to treat every release like a major release.
This caused a scrub through the manual for the string "1.1"
and "6.0" and changed to "1.1.1" and "6.0.1".  Also the
release date changed to 17 February.

(From yocto-docs rev: d603f89d42442dee6287381e7a0bfb7ddcdc2353)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:51 +00:00
Scott Rifenbark 68d048abfd documentation/adt-manual: Scrub for 1.1 occurrences
Several changes made to turn "1.1" into "1.1.1" for the Edison
point release.  There could be a couple more.  I am waiting on
clarification from Beth and Jessica.

(From yocto-docs rev: 7a27eba984c4baf7dc22a61a18f9c902acc6f9d6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:51 +00:00
Scott Rifenbark d5848aa719 documentation: cross-manual links hard-coded for 1.1.1 release.
All the links to any YP manual for the 1.1.1 release now use
"http://www.yoctoproject.org/docs/1.1.1/....".

(From yocto-docs rev: 178d16e8693550341a4d307e36af934ce0bfe4c3)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:50 +00:00
Scott Rifenbark 9edf601d2d documentation: Updates to Manual History Table for 1.1.1
All history table entries added for the five YP manuals.
At this commit the date was not known so a place holder date
of 12 January 2012 is in there.  I needed to commit this
separately so that I could move onto other changes for the
docs.

(From yocto-docs rev: 4983a6d66d659aa7a0cc5d4953716a55f24fb03b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:50 +00:00
Scott Rifenbark 155d0deae8 documentation/poky-ref-manual/technical-details.xml: edits per Richard Purdie
Richard reviewed the new sections and had a couple comments.  There
was one technical error and he also wanted YP worked out when it was
being used in the context of the code that was doing the work here.
So I replaced with more generic terms or specifically called out
BitBake as the responsible software.

(From yocto-docs rev: 89641ffa35d7978961790d750ce84073dc8520c1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:50 +00:00
Scott Rifenbark 85408dfd36 documentation/poky-ref-manual/ref-bitbake.xml: Updated BitBake Running a Task
I added more information about how BitBake actually runs a task.
The information has to do with how tightly BB controls the execution
environment of the build tasks to prevent contamination from the
build machine from leaking into the task execution environment.
This tight control actually causes some unexpected behavior during
builds.  For example, when a user exports and BB_ENV_EXTRAWHITE
an environment item such as CCACHE_DIR, the effects of the environment
item never make it to the BB task execution environment.  They only
make it to the data store.  The user actually has to take some extra
steps to export that environment item into the task execution environment.
The added information I put into the "Running a Task" section describes
these extra steps.

Fixes [YOCTO #689]
Reported-by: Wolfgang Denk <wd@denx.de>
(From yocto-docs rev: f75a9d384c0d5ccaefe7ac2195917531b153cf5e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:50 +00:00
Scott Rifenbark 43fb63af31 documenation/poky-ref-manual/technical-details.xml: Shared State
I updated the tips and tricks section to include two sub-sections.
The first if the debugging stuff from Richard's email.  The
second section is how to invalidate a section of the sstate
cache on a per-class basis.

Fixes [YOCTO #1500]

(From yocto-docs rev: e2cc31c112fc55c3f793f3c416311a1d317ceb37)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:49 +00:00
Scott Rifenbark 8add7fccde documentation/poky-ref-manual/technical-details.xml: more on YOCTO #1500
More work on this bug for sstate.  This commit represents the third
pass through the new chapter four (Technical Details) that is
dedicated to YP components and sstate at the moment.  The material
is unreviewed by Richard as of yet.

(From yocto-docs rev: ecaba811d3125e2ed1fc09df718d51e3eb30147f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:49 +00:00
Scott Rifenbark 01f5e6778c documenation/poky-ref-manual/technical-details.xml: Some general edits.
(From yocto-docs rev: c1684acf9249a6ace631a98f25aa256a542cee62)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:49 +00:00
Scott Rifenbark 1ff81200ac documentation/poky-ref-manual/extendpoky.xml: Fixed typo
Changed "versions" to "Versions" in the title.

(From yocto-docs rev: ce327ae04216e63315bcc735ba9b410582fe74b5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:49 +00:00
Scott Rifenbark d2f1ca8cba documentation/poky-ref-manual/extendpoky.xml: intro changed and order changed
Beefed up the introductory paragraph and I re-ordered the "Making and
Maintaining Changes" section towards the end of the chapter.

(From yocto-docs rev: a58c0e73d720ffb7a4931fbc196ea3831992b514)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:49 +00:00
Scott Rifenbark caab52f6cc documentation/poky-ref-manual/usingpoky.xml: updated intro paragraph
Beefed up the introductory paragraph a bit.

(From yocto-docs rev: 99e0b95d4827dcc309ab0f212801fc86758a297d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:48 +00:00
Scott Rifenbark b4eb195b34 documentation/poky-ref-manual/introduction.xml: Added reference
Added a reference to the YP development manual in the introductory
paragraph.

(From yocto-docs rev: 977eb862e27e0f2165a2d38cdaff06271726e9fc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:48 +00:00
Scott Rifenbark 3dbabb693d documentation/poky-ref-manual/introduction.xml: added new chapter
The list that describes the organization of the book needed the
"Technical Details" chapter added.

(From yocto-docs rev: bdaeb303e92f145fa6499e95ee88c629dd1c6486)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:48 +00:00
Scott Rifenbark 5dd34a717e documentation/poky-ref-manual: New chapter introduced
Long-term strategy for the YP Reference Manual is that it contains
reference material and not "how-to-information".  A step in this
direction is to isolate any discussions on components and other
areas of YP that need talked about.  So to start with, I have created
a new chapter for now named "Technical Details" that so far has
a discussion of some components and shared state.  This is a
step in the direction of making this manual a reference manual and
not a "how to" manual.

Changes included removing redundant material from the 'usingpoky.xml'
chapter and also adding the new chapter 'technical-details' into the
'poky-ref-manual.xml' file used for the make.

(From yocto-docs rev: a01477f787768230bc25da2d094326922be23dd4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:48 +00:00
Scott Rifenbark e7cfb3b469 documentation/poky-ref-manual/usingpoky.xml: Removed comments
Removed some comments that were buried in the file that were
notes for working on the sstate section.

(From yocto-docs rev: bd03315031bbb1b682dcd2253f85fc184822a28e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:47 +00:00
Scott Rifenbark c2494d3014 documentation/poky-ref-manual/usingpoky.xml: partial for YOCTO #1500
First draft of a re-write to the "Running a Build" section to try
and satisfy YOCTO #1500.  I segmented the section into three areas
rather than a single area.  This allowed me to create a sub-section
for the sstate stuff where it could be addressed on its own.  I sent
the draft out to Richard and Mark H. and got feedback from RP that
is going to cause further changes.  Thus, I am committing this partial
change.

(From yocto-docs rev: f040ed6979e988968863016103aa3ad4e7365159)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:05:47 +00:00
Scott Rifenbark 9d87cd9952 documentation/poky-ref-manual/introduction.xml: Fixed broken link
Robert identified this broken link to the stable Yocto Releases.

As Reported by: Robert P. J. Day
(From yocto-docs rev: acbcfe054ce345156346b3963b41e73f20b679cc)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:01:23 +00:00
Scott Rifenbark 1851a96b47 documentation/yocto-project-qs/yocto-project-qs.xml: Updated packages section
Split the instructions for getting the packages needed for Yocto
into sections that specifically support Ubuntu, Fedora, and openSUSE.
Also, added a couple packages to openSUSE.  I did not implement a
suggested change to include a note indicating future support of
the dash shell since it probably is not good policy to document plans
as they change.

Reported-by: Darren Hart
(From yocto-docs rev: 215af24bd6f697e4a3650f4669e12c6e191e2dab)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 16:00:05 +00:00
Scott Rifenbark efd2d7ee05 documentation/yocto-project-qs/yocto-project-qs.xml: Fixed broken link
Deleted the "www" from the URL to get the edison tarball.  This fixed
the link.

Reported-by: William Mills
(From yocto-docs rev: aa19ff9bfb465b6a6623cda1c7a080a0c3924995)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 15:59:07 +00:00
Scott Rifenbark b16bc3d277 documentation/poky-ref-manual/ref-classes.xml: insane.bbclass updated
Added explanation about this class being configurable for
generating warnings or errors through use of the WARN_QA and
ERROR_QA variables.  Also provided a list of tests that can
be tested for.

Fixes [YOCTO #1773]

Reported-by: Mark Hatle <mark.hatle@windriver.com>
(From yocto-docs rev: 2b15aa9076ec120d078bfcd570001a49e81df038)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2012-01-30 15:56:51 +00:00
Holger Hans Peter Freyther a56c10d89a lcr: Clean out the default config files 2012-01-23 02:32:32 +08:00
Holger Hans Peter Freyther 75abc06f34 lcr: Remove not installed files from the CONFFILES 2012-01-23 02:25:15 +08:00
Holger Hans Peter Freyther 23dbc00a4e openbsc: Upgrade git version to track 0.10.1+ 2012-01-16 16:38:41 +08:00
Holger Hans Peter Freyther 73bcd9a75c libosmocore: Upgrade git to after the 0.4.1 release
In this git version LAPDm is fixed in a way that it is working
for the osmo-bts again.
2012-01-16 16:38:41 +08:00
Holger Hans Peter Freyther 6e64338f29 libosmo-abis: Add recipe for upstream version 0.1.1 2012-01-16 16:38:41 +08:00
Holger Hans Peter Freyther 8f3955af20 lcr: Upgrade to post 1.10 and build from my personal branch
Update to 1.10 to work with newer osmo-nitb, including the version
handshake that was introduced.
2012-01-16 16:38:41 +08:00
Holger Hans Peter Freyther e77df798a7 asterisk: Band aid for a crash on RTP RTCP message
This might be a general TLS issue with Asterisk on ARM. I have not
looked into why this is happening. Create a band-aid.

Crash:
(gdb) bt
it crashed when formating/printing the &addr in the rtcp recv method
...

RTCP:
Packet generated from Ekiga 3.2.7 (Debian Unstable).

Cause:
Not very clear, maybe something with TLS handling of asterisk
2012-01-16 16:38:41 +08:00
Holger Hans Peter Freyther 9566715405 asterisk: Upgrade from version 1.8.7.0 to 1.8.8.1
Move along the stable track.
2012-01-16 16:38:37 +08:00
Holger Hans Peter Freyther c2d998c9b4 mISDN: Upgrade the mISDNuser library to post 2.0.5 2012-01-16 16:06:09 +08:00
Holger Hans Peter Freyther 8946d523ed libosmocore: Update the git recipe to include latest LAPD fix 2012-01-11 20:44:34 +08:00
Holger Hans Peter Freyther 183d75b24d libosmocore: Add version 0.4.1 of libosmocore, force re-build 2011-12-11 23:12:26 +01:00
Holger Hans Peter Freyther dca725b368 osmocom: Introduce META_TELEPHONY_OSMO_INC to easily bump version
For libosmocore updates we need a nice way to rebuild all libraries
using it. This can be done using the META_TELEPHONY_OSMO_INC variable.
2011-12-11 22:08:19 +01:00
Holger Hans Peter Freyther f58538edcd asterisk: Remove the CONFFILES that are not provided here 2011-12-11 21:38:31 +01:00
Holger Hans Peter Freyther 9d9e971a87 task: Add a task to build everything in this layer
Add a task to build test everything that is in this layer.
2011-12-11 17:36:35 +01:00
Holger Hans Peter Freyther f75ebc3f4b meta-toolchain-osmo: Include without direct addresssing
Use the BBPATH to find the recipe instead of assuming where this
layer has been placed.
2011-12-11 15:20:51 +01:00
Holger Hans Peter Freyther 447e9fa77d conf: Introduce the conf/layer.conf to make it work as a layer 2011-12-11 15:19:18 +01:00
Scott Rifenbark adcf8bf7b5 documentation/adt-manual/adt-prepare.xml: Fixed bad URL for edison tarball
The URL for the edision tarball was old and had been locked down in
the manual too early.  It changed and now this fixes it.

(From yocto-docs rev: 8790b84e3a2d04e557f048e30085813a1e8fb003)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-11-25 15:26:48 +00:00
Scott Rifenbark fda17235fd documentation/dev-manual/dev-manual-newbie.xml: Updates to Bugzilla use
I updated the Bug Tracking section to include rudimentary use of
Bugzilla for entering a new bug.

Fixes [YOCTO #237]

(From yocto-docs rev: 425965d7562f990c1f46901220caf4d79313336a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-11-25 15:26:37 +00:00
Holger Hans Peter Freyther 8083eb0be3 openggsn: Remove the ggsn.conf in CONFFILES as the file is not here 2011-11-14 20:41:20 +08:00
Holger Hans Peter Freyther 1d9cbe012b libosmocore: Build the latest git version of libosmocore 2011-11-11 22:15:00 +08:00
Holger Hans Peter Freyther 0b0ef8aae6 lcr: Introduce 1.10 of LCR with a custom start script for it. 2011-11-11 21:41:31 +08:00
Holger Hans Peter Freyther 6fe3d67299 misdn: Build the userspace library
Apply a local patch to increase the the buffer size, on different
platforms the kernel structs have holes that this calculation did
not account for.
2011-11-11 21:37:15 +08:00
Holger Hans Peter Freyther b49f5121bb libgsm: Introduce libgsm-1.0.13 recipe for LCR/mISDN 2011-11-11 21:36:15 +08:00
Holger Hans Peter Freyther f52b4a6ba8 asterisk: Introduce asterisk recipe for 1.8.7.0 2011-11-11 21:34:38 +08:00
Holger Hans Peter Freyther ba3023edbc ggsn: Remove the empty config file this should come from the machine integration
The integrator should install a config as he can decide on the IP
addresses and policy to be used.
2011-11-11 21:34:38 +08:00
Holger Hans Peter Freyther 60ee4cd504 Add existing sysmocom recipes 2011-11-11 21:26:06 +08:00
Scott Rifenbark c5bdef5617 documentation/adt-manual/adt-prepare.xml: Fixed broken link
Michael Tomer from Koko Fitclub reported that the link to the
ADT Installer tarball was broken.  Fixed the link.

As Reported by: Michael Tomer <michael.tomer@kokofitclub.com>
(From yocto-docs rev: 0a78be08b9fd2223737c50f3d0d83d14f3099834)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-11-08 21:49:45 +00:00
Scott Rifenbark 77640e96dd documentation/yocto-project-qs/yocto-project-qs.xml: Robert P. J. Day Review
As Reported By:  Robert P. J. Day.

Community member Robert P. J. Day scrubbed the Quick Start manual for Release
1.1.  He found several areas that were incorrect.  Many items were documented
pre-release and changed during the actual realeas.  Naming conventions for
images and such had to be changed.  Robert also found and suggested several
wording changes that resulted in clearer text.

I was not able to patch all the changes using the 'patch' command.  I need to
work out some process issues still in order to apply patches directly to the
yocto-docs repository.  Meanwhile, I hand-inserted the changes.  Also, some
text changes were modified slightly by me to conform to the books style, etc.

Kudos to Robert for such a detailed look at the YP Quick Start.

(From yocto-docs rev: 50145cde42b6203412dbba227cde300d5b10111b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-11-08 21:49:29 +00:00
Scott Rifenbark 98d9b82759 documentation/yocto-project-qs/yocto-project-qs.xml: dyslexic statement fixed.
I somehow had that having a host with multiple cores and threads could
be used to increase the build time.  It obviously should have been
"decrease".  Kudos to Bill Fishburn for finding this goof.

(From yocto-docs rev: 8ca44aab26d4a48745dbd0cbaffa0fe9b28d7063)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-31 22:38:17 +00:00
Scott Rifenbark 1aac5c310f documentation/yocto-project-qs/yocto-project-qs.xml: fix tarball URL
Community member Robert P.J. Day pointed out that the URL used to
reference the Edison tarball in the manual was incorrect.  It was
pointing to the old Poky area and not the Yocto-1.1 area.  I have
updated the example 'wget' command with the correct URL.

(From yocto-docs rev: 402500c03a625dd7e2561775926e3a983daa0ab6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-31 22:38:09 +00:00
Scott Rifenbark 1924f52cc8 documentation/adt-manual/adt-eclipse.xml: Added missing section for plug-in
Discovered a missing section for installation of the Eclipse Yocto Plug-in.
This information is critical to the release.  Jessica discovered the problem.
New section added that describes how to install the plug-in as a standard
"New Software" installation from within the Eclipse IDE.

(From yocto-docs rev: d4976ec56d39813a72519387897023f65a5884f6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-14 00:33:59 +01:00
Scott Rifenbark 6535ba6077 documentation/adt-manual/adt-eclipse.xml: fixed indigo typos
(From yocto-docs rev: cd2fe81bf9fe9fe4cc463861b62278654e7fff78)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-14 00:33:56 +01:00
Scott Rifenbark eae4945a9d documentation: Cleaned out bad links and replaced with good
The re-structuring of the web server that holds the documents created
some bad links.  I thought I had gotten them all but apparently not.
this is a drawback of not being able to test things until after stuff
is done.  In any case, I grepped through everything and this takes
care of it.

(From yocto-docs rev: cdbc3b3b7f6d6ff01024b977f966459cf414ad5c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-14 00:33:56 +01:00
Scott Rifenbark 5ec43fdbb8 documentation/dev-manual: Fixed five broken links and removed note
The restructuring of the web site where we store manuals broke some
links that were cut-and-pasted in from older work.  These slipped by
me so not changing them would direct the user to a 1.0 version of
the externally referenced manual rather than the 1.1 version.

I also got rid of a visible "WRITER'S NOTE" in the document that
was left behind.

(From yocto-docs rev: 1508826312a2fe35e5d693821a4c7737baafcb2e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-14 00:33:56 +01:00
Richard Purdie 5ed59ae0f2 local.conf.sample: Disable interactive patch resolution for now since doesn't work well
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-07 00:00:21 +01:00
Scott Rifenbark e02d553b45 documentation/dev-manual/dev-manual-kernel-appendix.xml: config example
I had to add some changes to the way we invoke qemu to show multiple
processor support.  I needed the qemuparam "-smp 2".  There are
other minor edits as well.

(From yocto-docs rev: 508863634ce537b0936f8e44f87b90bef678c122)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-06 18:51:26 +01:00
Scott Rifenbark 720446629b documentation/yocto-project-qs/yocto-project-qs.xml: release name and misc.
I somehow had either dreamed the word "einstein" into the release
for 1.1 and had it in there as part of the tarball name, etc.
I have replaced this obviously with "edison."

Other edits involved making the references to outside documents
more consistent.

(From yocto-docs rev: 2407b7dd89712c489d515e97d44e3c7dc0b64d20)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-06 18:51:21 +01:00
Scott Rifenbark db9d36f196 documentation/dev-manual/figures/kernel-example-repos.png: updated figure
Changed the pathnames for kernel 3.0 from 2.37

(From yocto-docs rev: 220ce5fbb3663940b5940445190d30d98f58a438)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-06 18:51:19 +01:00
Scott Rifenbark 4cca048ab8 documentation/dev-manual/dev-manual-kernel-appendix.xml: edits to the example
Some minor edits for the kernel example.

(From yocto-docs rev: 01e9f01662efad746fbfc34820b6efeb34affecd)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-06 18:51:15 +01:00
Scott Rifenbark 51b3d9dd53 documentation: Fixed links for yocto-1.1
After greping through the documentation directory, I addressed
all the <ulink> statements that used to have yocto-1.0 in the URL.
They are now yocto-1.1.

(From yocto-docs rev: 97d160263c5905fdeaf4ec285bc5359918790581)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-06 18:51:12 +01:00
Bruce Ashfield bc885cd8d3 linux-yocto: update live boot configuration
Updating the meta SRCREV to import a series of changes to synchronize
live booting between multiple targets:

  d05450e meta/fri2: enable booting from iso
  3da7d2a meta/fishriver: enable booting from iso
  52e1c49 meta/emenlow: enable booting from iso
  87918ae meta/crownbay: enable booting from iso

(From OE-Core rev: 7100c50c8697a3eec446b9189bf49ecbea9b7264)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-05 19:40:20 +01:00
Scott Rifenbark c657668a07 documentation/dev-manual/figures/wip.png: new figure added.
(From yocto-docs rev: f373d2b9f3530e31dc84b9333cfef93cdfd2c5e2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark 02e3d4dc70 documentation/dev-manual/dev-manual-start.xml: console updates and tar update
I re-ran the exmaples to set up various Git repos and updated the output.

Also fixed a bad tarball name from edison-1.1 to edison-6.0

(From yocto-docs rev: 6538d588fa35986ff301a22d327af73c337ec43c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark 57746012d0 documentation/dev-manual/dev-manual-kernel-appendix.xml: general updates
I made a pass through the book to clean up all areas in preparation to
running the examples again.  Most changes were punctuation, manual
section reference formats, and wordings.

(From yocto-docs rev: 0d054f79c82ddc204938dea187312d1a80d0a2e1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark 8a48ec4297 documenation/Makefile: Added a "WIP" figure dev manual for future work.
(From yocto-docs rev: 90964c51b1cd848a7bb0ddce5dcfd0a0f8c86223)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark 61637a5241 documentation/dev-manual/dev-manual-bsp-appendix.xml: changes to references
More changes to the internal section references.  Using <link> rather than
<xref> to get rid of the section number in the reference.

(From yocto-docs rev: 4351fd4898c517e25235611893b1cd059cbcc2f8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark 8a475908b5 documenation/dev-manual/dev-manual-bsp-appendix.xml: fixed reference form
I am using a certain form to reference other sections in the current
or other manual.  I updated the references to follow this form.

(From yocto-docs rev: 2ba41ac2f355dbe66af19e356f9246b7485585b5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Scott Rifenbark b7d2cf0525 documentation/dev-manual/dev-manual-bsp-appendix.xml: fixed typo.
(From yocto-docs rev: a66bb0402dd3f1499278277486e482b573a97777)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:13:27 +01:00
Khem Raj 4d7fbeda35 runqemu-export-rootfs: Add HOW-TO for ubuntu 11.10 for rpcbind problem
The existing instruction to tackle
RPC: Authentication error; why = Client credential too weak
Are not applicable to ubuntu 11.10 especially

Therefore add the magic needed for ubuntu 11.10

(From OE-Core rev: faae191e8c1920745e0ea9abf7b8b26eb4561096)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 23:11:39 +01:00
Scott Rifenbark baf536c62c documentation/adt-manual: changes for Jessica's review.
I made several changes based on feedback from Jessica Zhang.

1. Removed "SDKVERSION" as a way of identifying the directory in
   which a toolchain tarball is installed.  I replaced with "1.1"

2. Cleaned up the bitbake command verbage to consistently use
   'bitbake' command.

3. Cleaned up an erroneous reference to the toolchain environment
   setup scripts.  I was referring the user to the oe-init-build-env
   area.

4. Changed wording to indicate that the toolchain tarball is generated
   after running bitbake rather than installing the toolchain.

5. Replaced the gmae tarball file used in an example to be the
   regular taball.

(From yocto-docs rev: f7c3e4f4a666121a29825099d451eab1accb0616)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:41 +01:00
Scott Rifenbark 0c48a6805e documentation/dev-manual/dev-manual-start.xml: Updates for 1.1 repos names
I changed the bernard examples used when creating Git repos to reflect
the edison release.

(From yocto-docs rev: d345cb08905e7f5e21b1649af5e876317cc68931)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:41 +01:00
Scott Rifenbark 1ea2c63bf5 documentation/dev-manual/dev-manual-bsp-appendix.xml: scrubbed example
I changed several small things in the example as I worked through it
once again.  The commit IDs changed for using the atom-pc kernel.
Also the command to build the sato image can no longer use 'live'.

(From yocto-docs rev: faff1e7f21b5059dfe708c6a3d83116c7349fe55)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:41 +01:00
Scott Rifenbark f33f49a348 documentation/adt-manual/adt-eclipse.xml: edits to zip section
No need to use the long command to restart Eclipse.  It will have
been restarted as part of the procedure.  I updated the last paragraph
to simply point the user off to the next section.

(From yocto-docs rev: bca280e74f81a0401c520c8a59e9e07e16f28b8b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:41 +01:00
Scott Rifenbark cc6819ede7 documentation/adt-manual/adt-eclipse.xml: updates to zip method of plugin install.
These changes are for installing the YP Eclipse plug-in using a built out
ZIP file.

(From yocto-docs rev: ea50f63d448b4ff6026a9334440058511782461d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:41 +01:00
Scott Rifenbark 2a68be025b documentation/poky-ref-manual/extendpoky.xml: multilib edits
Feedback from Richard Purdie inserted.  I made an edit pass for
style to Richard's re-write.

(From yocto-docs rev: e5bb08e966614c610e6357642b3b2d1522332f7f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark f05471dcf8 documentation/adt-manual/adt-eclipse.xml: edits to the config steps
I made some slight edits to configuring the Eclipse IDE and the
procedure to install the plug-in from the zip file.  This is not
complete yet.

(From yocto-docs rev: 96de3d21946d64e6b877f067912da8677c3d373a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 5fe2c53493 documentation/kernel-manual/kernel-how-to.xml: Updated build strategy
This section used the term "tree construction" somewhat out of context.
The section really focuses on what the build process and the user does
prior to compilation.  I changed wording to indicate the tree is
validated to be sure that the SRC_URI point to the right stuff and
that the BSP build branch exists.

(From yocto-docs rev: e6332d5045b21354b53bbbe1203f9d52d4d97964)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 6b2ae5fd17 documentation/adt-manual/adt-prepare.xml: updates to getting images.
Made a few corrections to the section describing how to build
the tcf-agent into non-sdk images.

(From yocto-docs rev: e78dc3b3d3dd443506e78651cf9673358577c21d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 4eeeded4a7 documentation/adt-manual/adt-prepare.xml: Updated for building tcf-agent
The YP only ships one pre-built image that has the tcf-agent built
into it - core-image-sato-sdk.  There are a couple methods that exist
to create images that do not normally have this agent so that they
will have it.  I updated the "Getting the Images" section to
contain those steps.  Lianhao and Jessica Zhang were the technical
resources for these changes.  These changes are the first draft.

(From yocto-docs rev: 85432e4892c3fe924bf90961f89e8edfd9693e84)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 931db10bd0 documentation/poky-ref-manual/extendpoky.xml: Multilib section added
I created a section on how to prepare for and use the multilib
feature.  The information is leveraged off the "Multilib" wiki page
at http://wiki.yoctoproject.org/wiki/Multilib.  This is the first
draft of the changes.  I expect corrections.

(From yocto-docs rev: 8cf41c90f772018f4f144d63df911912cc298d70)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 522268be49 documentation/adt-manual/adt-prepare.xml: changed link
Updated a link that was an autobuilder link to be
http://www.yoctoproject.org/downloads/yocto-1.1/machines.

(From yocto-docs rev: 91a4056a285b53f8c73494e8af88d9a98d6d61e0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 8e17bffa42 documentation: Updated title pages.
Updated the title pages for the ADT, BSP, Dev, and Ref manuals to
contain the Oct 6 release date for the books.  Also, changed the
author field for the BSP guide to include Tom Zanussi as well
as Richard Purdie.

(From yocto-docs rev: 301da0a5b305e4b332397bb67f6a6a77751991d2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark cc004358f1 documentation/poky-ref-manual/ref-variables.xml: updated KERNEL_FEATURES
(From yocto-docs rev: 37a9cea71139ceda1d2a7da639f5555414ef497b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark 0e623482d5 documentation/kernel-manual: Added some references to other areas of YP docs.
(From yocto-docs rev: 20754cb376e65b7262b754afad839e0c2b82d7f7)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:40 +01:00
Scott Rifenbark ec31ee62d5 documentation/kernel-manual: Scrub for 1.1
I went through and made sure examples are relevant, wording is correct,
large blocks of unused text was removed, and some references included
to other YP documents.

(From yocto-docs rev: 2231082530dd9cecc234f5f024c4e246afb2968d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark a59ca8316b documentation/poky-ref-manual/ref-variables.xml: updates to KERNEL_FEATURES.
(From yocto-docs rev: ec1e2d71c576fe1c12031371de89a71770cebb1d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 4423b5b024 documentation/poky-ref-manual/ref-variables.xml: Added KERNEL_FEATURES
Added this variable description in the glossary.

(From yocto-docs rev: 12a9e5b4dfc399ff2037355aa1062f907a62e76d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark b47f39dbc3 documentation/poky-ref-manual/faq.xml: Removed wording that focues on GNOME
Per Paul Eggleton he suggested that the wording we had about YP focusing
on the GNOME Mobile environment was misleading now.  It was in there in the
original version of the FAQ but with time has become outdated.  I simply
removed the "GNOME" part and left the part that mentions about YP
being a stable
environment and well-suited for the embedded mobile environment.

(From yocto-docs rev: cc7103eda3fd77d89cecfffa23f0f798aa512132)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 9d72b706fa documentation/bsp-guide/bsp.xml: Added recipes-core section
In the example I use for the BSP structure I use the Crown Bay
BSP.  I neglected to include any explanation of the recipes-core
directory.  I have added some description around this area.

(From yocto-docs rev: ba56c86e5a4aa3fbf23b12d26ffe35a3b6193a78)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 5d4888723b documentation/yocto-project-qs/yocto-project-qs.xml: Supported Distros updated
I updated the section on the supported distribution section by including
a link to the wiki page that shows what distros we have tested and
their status.

(From yocto-docs rev: e66a18a13dc02af6a0846dd1ecf14aeafcbe5d61)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 49e3171850 documentation/adt-manual/adt-eclipse.xml: Added zip method for plug-in install
I added a new subsection to the section that talks about how to install
the YP eclipse plug-in.  According the Jessica, we should document
this method for installing the plug-in.

(From yocto-docs rev: dea5b1dacc16c08d61356e95bece2aec581dd16d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 66ddb69916 documentation/poky-ref-manual/ref-variables.xml: Variables updated
This is the second pass for re-documenting RDEPENDS, RRECOMMENDS,
MACHINE_ESSENTIALS_EXTRA_RDEPENDS, MACHINE_ESSENTIALS_EXTRA_RRECOMMENDS,
MACHINE_EXTRA_RDEPENDS, and MACHINE_EXTRA_RRECOMMENDS.  These
variables are in dire need of better explanations and examples.

(From yocto-docs rev: cc60bd4c50c7b19209dae06307aec26e962cf476)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark de1dcde413 documentation/poky-ref-manual: Updates to several variables.
I did complete rewrites of RDEPENDS, RRECOMMENDS,
MACHINE_ESSENTIAL_EXTRA_RDEPENDS, MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS,
MACHINE_EXTRA_RDEPENDS, and MACHINE_EXTRA_RRECOMMENDS.  These are
sent out for review but these changes represent the first attempt
to clear up confusion on how the six variables are used and relate
to each other.

(From yocto-docs rev: 1d93707fb9383d51322e96eb521e96fcac8bcc47)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:39 +01:00
Scott Rifenbark 9f36b1fe16 documentation/poky-ref-manual/ref-variables.xml: update RDEPENDS and RRECOMMENDS
Provided better descriptions of these variables and some examples on
how to use them.

(From yocto-docs rev: 3a5cce8c9ba02f90b3554a6f800f69c2e8e77911)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 38c7a8a069 documentation/poky-ref-manual/ref-variables.xml: update PREFERRED_VERSION
Added a more robust description and provided a couple of usage
examples.

(From yocto-docs rev: b8b842b57cc003f1351a551041fe4b3de2fcbfd6)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 23bac7cb0e documentation/poky-ref-manual/ref-variables.xml: update PREFERRED_PROVIDER
I added sterner wording on usage and provided an example.

(From yocto-docs rev: 32e07fafadb602b93c9f7b8a78e5baf4c7e1ab5e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 0021456aad documentation/poky-ref-manual/ref-variables.xml: update TCLIBC and POKYLIBC
Changed the description of POKYLIBC to note the variable is not supported
and provided a link to TCLIBC.  I added the entry for TCLIBC, which
was missing.

(From yocto-docs rev: d76a1ddb79577a3e121df3d590fb601b5e5fbb98)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark a568995f40 documentation/poky-ref-manual/ref-variables.xml: updates TCMODE and POKYMODE
Noted that POKYMODE is no longer supported and provided link to TCMODE.
Added richer description to TCMODE.

(From yocto-docs rev: a7a326c2c8f4c5f29f3a9723a6895a7113a78357)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark f82ac840aa documentation/poky-ref-manual/ref-variables.xml: edits to FILESYSTEM_PERMS_TABLES.
Some minor re-wordings to give some context on how to use these special
files and the variable to point to them.

(From yocto-docs rev: 4482b42f4a224bada7a0fa5fe4821a753ba55d80)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark cd2c80dedc documentation/dev-manual/dev-manual-newbie.xml: added information for licenses
I added the directory where the list of know licenses are in the YP
files structure (meta/files/common-licenses).

(From yocto-docs rev: 6a8db1a5ac653dbc8730e61293221c0b0890888d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark ed93525e65 documentation/poky-ref-manual/ref-variables.xml: updated RDEPENDS
Per Paul Eggleton's suggestion I updated the description of this
variable.  Some minor wording changes as well as covering two
automatic handling features.

(From yocto-docs rev: 15be3502ca20f657051e02d698b459328328fb14)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 4025831e90 documentation: scrubbed out 'glibc' and replaced with 'eglibc'
Several manuals and areas were still referring to 'glibc' as the
GNU version of the Unix statndrd C library.  We do not support this
any longer and now use 'eglibc' to build with.  Notable changes were
in the required packages area of the QS manual.  I also added a
bit in the reference guide saying how this release does not use
'glibc' to build with but rather 'eglibc'.

(From yocto-docs rev: c2c58914996d747c510706d78ecfd8f41c5e694d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 94c381f71b documentation/poky-ref-manual/extendpoky.xml: New section on static library
I added a new section to the "Adding a Package" section.  This section
describes how to define the *.a files for when you create a library
that has static linking.  Response to a comment from Paul Eggleton.

(From yocto-docs rev: 64499006ecd1e6b7573f1955a2f6e2f1a9564ce8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:38 +01:00
Scott Rifenbark 588e21b339 documentation/poky-ref-manual/ref-variables.xml: added FILESYSTEM_PERMS_TABLES
New glossary variable entry added.

(From yocto-docs rev: f9a214fa7714b9ca4741ac0c56d40e2d8a390292)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 14:01:37 +01:00
Richard Purdie 3429095e86 package_rpm: Ensure multilib code is only called in the multilib case
This fixes some error messages in the do_rootfs logs of non-multilib
builds.

(From OE-Core rev: fb554596e031cf92b62a19cabdd10e8e23ab4453)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:31 +01:00
Richard Purdie feb11f1079 populate_sdk_rpm: Add missing /bin/sh from rpm ignore list for the SDK
The target SDK packages don't need to fulfil a shell dependency
so add /bin/sh to the list of packages we don't need to resolve.

(From OE-Core rev: 9283255da08f45a368fa9355dbafd3840dfd5056)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:31 +01:00
Richard Purdie fbec475275 Remove help2man dependency
The help2man script is pretty useless to us. It requires to run the target
binary to extract help information which is not possible for any of our
cross compiled target binaries.

We're not interested in man pages for -cross/-native tools.

It therefore makes no sense to have this as a core build dependency.

This patch removes the dependeny and replaces it with a script
returning false. This will trigger autotool's missing utility
to use the copy of the man page included with the sources which
is what would already happen when we tried to run cross compiled
binaries anyway.

(From OE-Core rev: c6e0f23363f24ae9f02cd753621ce45470285b16)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:31 +01:00
Dongxiao Xu 317fc4fbd0 multilib: add MLPREFIX to deploy folder
Add MLPREFIX to multilib deploy forlder to avoid the confliction between
multilib and normal package deploy directory.

(From OE-Core rev: b5e8cad5a782015f2216325203847c287c778cac)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:31 +01:00
Dongxiao Xu 909dd5b306 tune-i586: fix hardcoded TUNE_PKGARCH
Use TUNE_FEATURES to determine the setting to TUNE_PKGARCH, which fixes
the wrong setting of PACKAGE_ARCH in multilib case.

(From OE-Core rev: d8051ce1af7a5a4b72c1f772ed35eff24a4beb6b)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:31 +01:00
Jessica Zhang 24623d149d Fixed a typo for setting up OECORE_ACLOCAL_OPTS for adt-installer case
(From OE-Core rev: 0e042e3650c3e940ff17465d6bd835e22d85f1f6)

Signed-off-by: Jessica Zhang <jessica.zhang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:30 +01:00
Dongxiao Xu 5687f68f3e libc-package.bbclass: add MLPREFIX when set values to PACKAGES
There are some places that PACKAGES are dynamically set. To support
multilib, we need to add MLPREFIX before the package name in those
settings.

(From OE-Core rev: 98d356a9f788291c849be7b51fcd8ad07a8a066e)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:30 +01:00
Dongxiao Xu f282b7a027 package_rpm: combine normal and multilib solution manifest together
When RPM does the real install, if the first manifest file is empty, the
installation will stop without handling the second manifest file.

Merge the two manifest files together to fix this issue.

(From OE-Core rev: 20e6f166858751c6305cd8a52f87cdf78c1a8126)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:30 +01:00
Dongxiao Xu 32b1c9150f multilib: remove the multilib handling to allarch
currently we have allarch type of recipes, which may still have
architecture dependency, like x11-common. So we need to drop the
handling to allarch in multilib case.

Also remove the PV postfix in python-pygobject DEPENDS, since multilib
code will treat a native package multilib capable.

[YOCTO #1497]
[YOCTO #1498]

(From OE-Core rev: d9dc64a251bc66f16a0c5d12aa872152d43c4776)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:30 +01:00
Dongxiao Xu 7a541d69dd multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipes
RDEPENDS of image type recipe needs to be mapped to make sure that the
packages included in the image should be multilib version.

Also add LINGUAS_INSTALL into MULTILIB_PACKAGE_INSTALL list.

[YOCTO #1496]
[YOCTO #1527]

(From OE-Core rev: ad52cf921b2e08f2a99f494b229d5b7099b33990)

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:29 +01:00
Joshua Lock aa1cb68ce2 ghostscript: disable check for time.h
ghostscript has it's own hacky check for time.h which hard-codes paths, this
means in the native case it fails on systems such as Ubuntu 11.10 where the
location of time.h has changed. Further it means the target build has had a
host-intrusion issue.

This patch disables the check for time.h, future releases of ghostscript
use standard autotools checks for time.h's location.

(From OE-Core rev: 59746f706fd71b58268745309dfa54b87ccdb967)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:29 +01:00
Saul Wold dc1f3a3bd0 zypper & sat-solver: needs RDEPENDS on rpm-lib
(From OE-Core rev: f8fe4ef09d6ab037928850bbb953e2b0a2da49e9)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:29 +01:00
Saul Wold 5fbb040355 rpm: ensure that magic file is relocatable
rpm-native was reading from /usr/share/misc/magic which is wrong
it needs to be set to read from the sysroot.  This also adds wrappers
to the rpm-build tools to ensure they know were to find the macros that
point to the right directories.

Fixes [YOCTO #1532]

(From OE-Core rev: 7ea42eadf8aec734202b70ba2427230e63749d94)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:59:29 +01:00
Bruce Ashfield 9886c510f9 linux-yocto/meta: eg20t and live boot config changes
Merging the following configuration changes:

 67a46a6 meta/common-pc-64: enable live booting for common-pc-64
 1010905 meta/common-pc: enable live booting for common-pc
 b3c5fa7 meta/atom-pc: enable live booting for atom-pc
 41c090e meta: update boot live config and move it to cfg/
 d51b0e7 eg20t: update config options

The first 4 make the live-boot configuration shared and then reuse
them for the boards that currently are live bootable. The eg20t
is a cleanup of obselete kernel options and is part of the cleanup
of options for the 3.0 kernel.

[YOCTO: #940]
[YOCTO: #686]

(From OE-Core rev: 4482970401a048433d5a862bfed4936259dcfcf5)

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:57:52 +01:00
Paul Eggleton 49de6096b1 beagleboard-audio: fix RDEPENDS on alsa-utils-amixer
Use RDEPENDS_${PN} instead of RDEPENDS.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-10-04 13:48:33 +01:00
Paul Eggleton 7eb193fc49 bitbake/lib/bb/msg.py: fix setting debug and verbosity levels
The debug and verbosity levels (as set by the -D and -v command line
options respectively)  were not being passed through within msg.py since
bitbake revision 45aad2f9647df14bcfa5e755b57e1ddab377939a due to
incorrect variable names.

Fixes [YOCTO #1513].

(Bitbake rev: c6e88b7c0e61f9586a275df53f48b90687c5f92f)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-26 19:35:58 +01:00
Joshua Lock 4aa6a8e9a6 hob: store recipe path at load time
This fixes the internal dirtiness tracking such that if the Save menu item
is selected after loading a recipe the existing file is updated rather than
the user being prompted for the path to create a recipe at.

(Bitbake rev: 00fc1d7249b5e217cc7c36ac71b63ddad1c5b769)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-26 19:35:47 +01:00
Joshua Lock a1f3aff110 hob: fix building with current selections after reparse
After the reparse we were setting the model to reflect the values before
the reparse was triggered but clearing the internal variables used to test
whether these values are set, leading to the UI erroneously reporting that
selections had not been made.

(Bitbake rev: 656eafe0f2c9ec7730d33e15705b8c720f787c49)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-26 19:35:36 +01:00
Joshua Lock bb351c2f41 ui/crumbs/hobeventhandler: fix variable name typo
(Bitbake rev: f7d0560307707fe10bf80820f1e6ae300864f915)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-26 19:35:23 +01:00
Joshua Lock bed552f8d0 ui/crumbs/hobeventhandler: move remaining getVariable calls to init
Instead of calling getVariable commands each time the BBPATH and BBFILES
entries need testing cache the results as a member variable at object
instantiation.

Fixes [YOCTO #1521]

(Bitbake rev: 109e1597671dfb7222672e268190aabc727960ca)

Signed-off-by: Joshua Lock <josh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-26 19:35:11 +01:00
Scott Rifenbark 41c564fe60 documentation/poky-ref-manual/ref-classes.xml: documented useradd.bbclass
New section per Paul Eggleton's request.

(From yocto-docs rev: ffedb53e5c706cffb83978f1704a606d29233e36)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:25 +01:00
Scott Rifenbark cae817e833 documentation/poky-ref-manual/ref-variables.xml: added BAD_RECOMMENDATIONS
New variable for images that use the ipkg packaging system.  These
are packages you don't want to install even when the recipe calls
for it.

(From yocto-docs rev: 78d53b5da4bbd6889a34be8a1c795a5658cb6b1e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:25 +01:00
Scott Rifenbark 7bb8b8f438 documentation/poky-ref-manual/ref-classes.xml: fixed insane.bbclass added others
I fixed the insane.bbclass description to say that it checks for common
problemos that occur during runtime and not build time.  Also got rid of the
"ever-increasing" statement as that is not true according to Paul Eggleton.

Added many new .bbclass files to the commented out section of the
undocumented classes as well as removed a bunch.

(From yocto-docs rev: c341951185d5af6576718f8ada057afcca923e6e)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:24 +01:00
Scott Rifenbark c32652716d documenation/poky-ref-manual/ref-variables.xml: debug-tweaks qualified
I noted that the developer should remove this option from
EXTRA_IMAGE_FEATURES before they create a production image.

(From yocto-docs rev: 8de6c789d1a1ed5e721c16f53bb27de18ae88238)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:24 +01:00
Scott Rifenbark 748fd4543b documentation/adt-manual/adt-command.xml: Note about running configure
YOCTO #1504: Added a note indicating what to do if the configure
script complains about --with-libtool-sysroot option.

(From yocto-docs rev: 575f4057ddfc2774a62bf349fd05d62b79dd278b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:24 +01:00
Scott Rifenbark 56f7ed979c documentation/dev-manual/dev-manual-model.xml: edit pass
These changes are the second edit pass for the new section.
There are some minor changes.

(From yocto-docs rev: 6c81617a2782d2f02d4900a68dd4e8c6eeb70fa1)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:24 +01:00
Scott Rifenbark 3a15c9f8d0 documentation/dev-manual/figures/app-dev-flow.png: Updated app flow image
(From yocto-docs rev: 5c0c04ccc2d1fdac89dc1394805e4b8c4cc2c082)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:23 +01:00
Scott Rifenbark fc7ceaead0 documentation/dev-manual: Added TM to first Eclipse in chapters.
(From yocto-docs rev: 0f8b655da637ebf7708bdfff1473707c9ea3b8ef)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:23 +01:00
Scott Rifenbark a626a5c208 documentation/dev-manual/dev-manual-model.xml: Edits and start of app section.
General edits up through the BSP and Kernel overview sections.  I also put
in place holder text and began on the application development over
section.

(From yocto-docs rev: 9c1b681ff253b469bffc355f0a938643997d85d4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:23 +01:00
Scott Rifenbark cb333ad6f3 documentation/dev-manual/dev-manual-kernel-appendix.xml: added line break
There is an example whose output exceeds the PDF manual version's
page width.  I had to artificially break the line up.

(From yocto-docs rev: d8a5714a2f8193c1efc8a7080b8f6e0744da610a)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:23 +01:00
Scott Rifenbark 5b58674c6b documentation/dev-manual: model changes and updated figure
Edits to the dev-manual-model.xml chapter for general improvements.
Also had to update the figure that shows the kernel development flow.

(From yocto-docs rev: 2aacccb03d167eac74a1b45c39a9edac160efc7f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:23 +01:00
Scott Rifenbark 1017d2aec8 documentation/dev-manual/dev-manual-newbie.xml: note for maintainer
Added a note indicating where you can find the maintainer for yocto
code.  Suggestion by Robert Berger.

(From yocto-docs rev: 8e55cc4c460582964b0267b4f43c14e7100f17fe)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:22 +01:00
Scott Rifenbark 9786db045f documentation/dev-manual/dev-manual-kernel-appendix.xml: Robert Berger feedback.
somehow I lost three or four changes that are credited to Robert
Berger (Community Member).  I have re-introduced them here.

(From yocto-docs rev: a23564ada0e072bea63739aeb1eb5c66d595e728)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:22 +01:00
Scott Rifenbark 158b84844e documentation/dev-manual/dev-manual-newbie.xml: addes link to commit page
I provided a link to the OpenEmbedded wiki page created by Mark Hatle
that provides good guidelines on how to create well-formed commit
messages.

(From yocto-docs rev: ea7b0100a7b45c369cb67daa0705dcc5acef40c8)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:22 +01:00
Scott Rifenbark 421c22d32c documentation/dev-manual/dev-manual-newbie.xml: edits and enhancements.
General pass-through for consistency in referencing sections.
Also, added Darren Hart's review comments for the "Submitting a
Change" section.  I added more about the mailing lists and how to
submit a proper commit message.

(From yocto-docs rev: d9c8f5db8c862b1be724915cc43da6d12b88b97d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:21 +01:00
Scott Rifenbark 90ccadecc3 documentation/poky-ref-manual/resources.xml: Updates to mailing lists.
I updated the mailing lists to be more specific and to be formatted
differently.

(From yocto-docs rev: 50b5cf2d331b120cfa9de0ba77ea1da1240d42e4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:21 +01:00
Scott Rifenbark 07638448b0 documentation/dev-manual/dev-manual-start.xml: formats and re-wordings.
Applied consistent section referencing formats.  Also cleaned up some
terminolgy for the YP Git repo.

(From yocto-docs rev: fa3cbb835b61158357d3f6fb9ebe017b9ba405cf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:21 +01:00
Scott Rifenbark f343aa4cc6 documentation/dev-manual/dev-manual-intro.xml: minor edits.
Some indentations applied.  Also, a few minor changes to some
wordings.

(From yocto-docs rev: a166f41a5bbf3590d8a2fabbee267bdd190f19dd)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:21 +01:00
Scott Rifenbark 5cd07954ea documentation/dev-manual/dev-manual-intro.xml: re-wrote the intro paragraphs.
(From yocto-docs rev: 5091b7c62c61b4c9ea14fb7a77cc4600437a9dbb)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:21 +01:00
Scott Rifenbark e0338b844f documentation/yocto-project-qs/yocto-project-qs.xml: Fixed text for filesystem
I needed to reference the image differently for the pre-built section.

(From yocto-docs rev: 10568a0a8c4160af995089e481ccc2772e81d805)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:20 +01:00
Scott Rifenbark cde57ddf84 documentation/yocto-project-qs/yocto-project-qs.xml: General edits
This was a final scrub of the manual.  I updated all examples and links
to be current for what I think will be the 1.1 release.  I also added
some cross-referencing into the YP dev manual that now exist.

(From yocto-docs rev: 4c10b0e04856817a1d03aee7a9ed6e4d5d73a3ac)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:20 +01:00
Scott Rifenbark bee5046908 documentation/adt-manual/adt-eclipse.xml: various minor clean ups.
(From yocto-docs rev: 6caabfaed1ec440511727e163b9c3bb7afe966ae)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:20 +01:00
Scott Rifenbark 4e6b4c09a5 documentation/adt-manual/adt-prepare.xml: fixed broken cross-link.
(From yocto-docs rev: 90f6bd0aff8346df24d691e0c9424a0a99af2095)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:20 +01:00
Scott Rifenbark 89496194ba documentation/adt-manual/adt-prepare.xml: applied Jessica Zhang revisions
These changes reflect corrections resulting from Jessica Zhang's review
of the sections.

(From yocto-docs rev: c3fed39bc3909c38424e7e72c40471dcb0053c8d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:19 +01:00
Scott Rifenbark 19f9b25947 documentation/adt-manual/adt-prepare.xml: Title correction
(From yocto-docs rev: 536665ac8b28426f2869ceffca3ea2f6f4d1eef4)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:19 +01:00
Scott Rifenbark f97e445fc6 documentation/adt-manual/adt-prepare.xml: toolchain enhancements
After working through this stuff I was still confused as to how to
guide the user toward proper toolchain installation and on what they
needed to do for collecting their kernel and filesystem images.
These changes included some information on when and how to extract
the rootfs when the user is booting to NFS.  Plus some other
general items like the significance of meta-toolchain-sdk as
compared to meta-toolchain.

(From yocto-docs rev: 2cc88b5193888a074ffd87cb253b9cfe08146877)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:19 +01:00
Scott Rifenbark 2766a88a3b documentation/adt-manual/adt-prepare.xml: removed terms
I had definitions for "The Yocto Project Files" and "The Yocto
Project Build Tree" in this chapter.  They were misplaced.  I have
deleted them and moved them to the development manual.

(From yocto-docs rev: 9238e75abc4578043fd625b3796b86d42204e16f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:19 +01:00
Scott Rifenbark b57c529115 documentation/dev-manual/dev-manual-newbie.xml: new terms
I moved the terms "Yocto Project Files" and "Yocto Project Build
Tree" into this development manual.  They were previous defined
in the ADT manual.  It makes more sense to have them where with other
terms.

(From yocto-docs rev: 2133110fd280db8cfbe998e6b46cdee0b260e777)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:18 +01:00
Scott Rifenbark 319f4ee481 documentation/adt-manual/adt-eclipse.xml: Fixed the section formatting.
I made changes to the section titles so they have quotes around them
for easier reading in the PDF manual.

(From yocto-docs rev: 5bea470682c3d834f30ab0d2fcba148ea33d653f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:18 +01:00
Scott Rifenbark 2cf26ef150 documentation/adt-manual/adt-eclipse.xml: writer note and re-wording
I added a development writer note and I noted that running a project
as an eclipse application pops a new instance of Eclipse.

(From yocto-docs rev: 6408ff7f4d59a0e535e560c7c0c63a3f373c640b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:18 +01:00
Scott Rifenbark 2c1b5b1054 documentation/adt-manual/adt-prepare.xml: writer notes and section format
I added a couple of writer notes for development purposes.  I also
formated the section title references so they have quotes around them
for easier reading in the PDF verison.

(From yocto-docs rev: 37adb580cf6c1369da43fc4ef7aaa4cc1cee0e5c)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:18 +01:00
Scott Rifenbark b8be92c34d documentation/adt-manual/adt-eclipse.xml: minor edits
fixed some section naming conventions and minor wordings.

(From yocto-docs rev: 768d386c135c57ed3573e08bac72cad47fa101ce)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:17 +01:00
Scott Rifenbark 6b4133b08f documentation/poky-ref-manual/resources.xml: re-wrote Contributions
The information in the "Contributions" section has been migrated to
a "Submitting a Change" section in the YP Development Manual.
I re-wrote this section here to simply make a general statement
about how you can submit a change and then provided a reference
link to the appropriate section in the dev manual.

(From yocto-docs rev: 038caebb2815a8f09d35e99d5a2a0be76b05cacf)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:17 +01:00
Scott Rifenbark 96d43c2410 documentation/dev-manual/dev-manual-newbie.xml: re-write change submit
The section on submitting a change was very sparse and incomplete.
I have significantly upgraded this section to provide more details.

(From yocto-docs rev: af43bb1e4902c45afb5ac4b0f099877acd7a81a2)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:57:17 +01:00
Richard Purdie cde2aa61cf neon: Add libproxy to DEPENDS to ensure determinstic builds
(From OE-Core rev: ed2a606909b9490ac57a3ad3db7a15e83a8664f9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:56:35 +01:00
Richard Purdie 1d18aeafa6 libsndfile1: Disable external codec librbaries since we don't list in DEPENDS
(From OE-Core rev: 34a14ce3ea78be299175e1a803f92519aa02355b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:56:24 +01:00
Richard Purdie b8a67d3000 cairo: Disable bfd symbol loopup since we don't list it in DEPENDS
(From OE-Core rev: ac8b7e275a8789b6605ef84a3b128aea2518b596)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:56:15 +01:00
Richard Purdie c3c8084855 gtk+: Explicitly disable xinerama since we don't have it as a DEPENDS
(From OE-Core rev: dbc25ca76d482f30186562fc51f5b3bdf48c0a7b)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:56:06 +01:00
Richard Purdie cd0ef4d7c1 gnome-desktop: Ensure we're deterministic about startup-notification dependency
Without this change we may or may not include startup-notification support.

We therefore explictly include it in the dependency list.

(From OE-Core rev: 8ad24306d8bc9c2fd73f4b814eb1a64c04707da5)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 17:56:00 +01:00
Saul Wold c9e35a126a attr/acl: add SSTATEPOSTINSTFUNC
Added a native sstate post install function to fix the links
created between /lib and /usr/lib for the library files. These
links could point to an invalid build area when using shared state.

(From OE-Core rev: 8ab7b681cdb43c6c21c187b8cd01faa39727824a)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-25 15:28:27 +01:00
Richard Purdie 4456226e45 populate_sdk_rpm: add pkgconfig(pkg-config) to the list
(From OE-Core rev: 368b150416688654e35229a63b87177b52e83d02)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-23 19:57:13 +01:00
Saul Wold bf8f071c5b populate_sdk_rpm: add items to the INSTALL_PROVIDESNAME_RPM list
This fixes a problem when building meta-toolchain-gmae, by adding items that
will be provided by the host system, such as /bin/bash, /usr/bin/env and
libGL.so

(From OE-Core rev: 01361f9d25b0a0027bbbe713b93051a4663b14fc)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
RP: libGL.so() -> libGL.so
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-23 01:08:17 +01:00
Elizabeth Flanagan 3b1e8a214e poky.conf: flipping DISTRO_VERSION and DISTRO_NAME
In preparation for the final edison buildout, flipping DISTRO*

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>
2011-09-22 16:28:12 -07:00
Darren Hart 1015dfce8d intltool: add libxml-parser-perl-native dependency to -native version
Fixes [YOCTO #1514]

Without a native dependency on libxml-parser-perl-native,
shared-mime-info-native can fail its do_configure task.

checking for XML::Parser... configure: error: XML::Parser perl module is
required for intltool

Testing: Successfully built shared-mime-info and shared-mime-info-native for
qemuppc.

(From OE-Core rev: 51b1df89828e677232e125181209b26d3c5ec928)

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Joshua Lock <josh@linux.intel.com>
CC: Richard Purdie <richard.purdie@linuxfoundation.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
CC: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:10 +01:00
Richard Purdie a0b1c14587 multilib.bbclass: Partially fix multlib image targets
This patch partially fixes problems when building multilib extended
images such as libXX-core-image-minimal. Its not a perfect/complete
solution but works much better than any previous code did.

[YOCTO #1496] (partial)
[YOCTO #1497] (partial)
[YOCTO #1498] (partial)

(From OE-Core rev: 00c38774ef0232cc2be924ed8e59220e7c452096)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:10 +01:00
Dexuan Cui 66934fc311 qemu-config: use pkg_postinst to generate the proper shutdown.desktop
[YOCTO #1507]

We need to remove the file qemuarm/shutdown.desktop, or else, on qemuarm,
due to the PACKAGE_ARCH overriding from all to qemuarm in base.bbclass,
the generated deb file will be stored at
tmp/deploy/deb/qemuarm/qemu-config_1.0-r21_allarch.deb rather than
tmp/deploy/deb/all/qemu-config_1.0-r21_all.deb, and the package qemu-config
won't be installable -- task-base finally rdepends on qemu-config, so we get
the do_rootfs failure:

The following packages have unmet dependencies:
|   task-base-extended: Depends: task-base but it is not going to be installed
| E: Broken packages

There is also a generic shutdown.desktop, we can keep it and use a proper
pkg_postinst to cope with the case of qemuarm.

(From OE-Core rev: 751212d5effdceab91d95705e647cf07e6820940)

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:10 +01:00
Richard Purdie 80de0f946b diffstat: Add missing file from previous commit
(From OE-Core rev: 6f4e6d6d41f874844b186b9e5b63a1b851becb52)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:10 +01:00
Richard Purdie 5e65389335 diffstat: Fix a build failure when using libdir=/usr/lib64
(From OE-Core rev: 9a846d83a39339de6d7cc0da050a50d7f4e093c7)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:10 +01:00
Zhai Edwin d513e5f92c qemugl: Use local variable rather than "push" to save register
New gcc uses "%esp" rather than "%ebp" to index local variable in stack, and
push between save-to/restore-from stack decrease "%esp", which leads wrong
index. Saving registers via local variables to make gcc aware of this and avoid
stack disorder.

[YOCTO #1442] got fixed

(From OE-Core rev: afc9edc27e77e80fdd24b4c8c538f91672940e75)

Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:09 +01:00
Saul Wold e9f8b99215 gnome-desktop: Fix python path in scripts to use target path
(From OE-Core rev: 22fd67f854f70f79ea94af11c61ef63939d54ac2)

Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-09-22 22:28:09 +01:00
620 changed files with 25703 additions and 5277 deletions

8
.gitignore vendored
View File

@ -9,11 +9,9 @@ build*/pyshtables.py
pstage/
scripts/oe-git-proxy-socks
sources/
meta-darwin
meta-maemo
meta-extras
meta-m2
meta-prvt*
meta-*
!meta-skeleton
!meta-demoapps
*.swp
*.orig
*.rej

View File

@ -68,12 +68,12 @@ Intel Atom based PCs and devices (atom-pc)
The atom-pc MACHINE is tested on the following platforms:
o Asus eee901
o Asus EeePC 901
o Acer Aspire One
o Toshiba NB305
o Intel Embedded Development Board 1-N450 (Black Sand)
and is likely to work on many unlisted atom based devices. The MACHINE type
and is likely to work on many unlisted Atom based devices. The MACHINE type
supports ethernet, wifi, sound, and i915 graphics by default in addition to
common PC input devices, busses, and so on.
@ -83,26 +83,18 @@ 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.
Hard Disk:
1. Build a directdisk image format. This will generate proper partition tables
that will in turn be written to the physical media. For example:
$ bitbake core-image-minimal-directdisk
2. Use the "dd" utility to write the image to the raw block device. For example:
# dd if=core-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb
USB Device:
1. Build an hddimg image format. This is a simple filesystem without partition
tables and is suitable for USB keys. For example:
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 atom-pc machine, this image type is built
automatically for any image you build. For example:
$ bitbake core-image-minimal-live
$ 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-live-atom-pc.hddimg of=/dev/sdb
# dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb
If the device fails to boot with "Boot error" displayed, it is likely the BIOS
cannot understand the physical layout of the disk (or rather it expects a
@ -126,7 +118,7 @@ USB Device:
b. Copy the contents of the poky image to the USB-ZIP mode device:
# mount -o loop core-image-minimal-live-atom-pc.hddimg /tmp/image
# mount -o loop core-image-minimal-atom-pc.hddimg /tmp/image
# mount /dev/sdb4 /tmp/usbkey
# cp -rf /tmp/image/* /tmp/usbkey
@ -150,7 +142,7 @@ faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
the NAND flash. The beagleboard MACHINE is tested on the following platforms:
o Beagleboard C4
o Beagleboard xM Rev A
o Beagleboard xM rev A & B
The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
these instructions assume you have erased the NAND on the C4 so its boot

View File

@ -4,6 +4,10 @@ import os
import sys
import warnings
sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
from bb import fetch2
import logging
logger = logging.getLogger("BitBake")
try:
import cPickle as pickle
@ -16,13 +20,20 @@ class BBConfiguration(object):
Manages build options and configurations for one run
"""
def __init__(self, debug, debug_domains):
setattr(self, "data", {})
setattr(self, "file", [])
setattr(self, "cmd", None)
setattr(self, "dump_signatures", True)
setattr(self, "debug", debug)
setattr(self, "debug_domains", debug_domains)
def __init__(self, **options):
self.data = {}
self.file = []
self.cmd = None
self.dump_signatures = True
self.prefile = []
self.postfile = []
self.parse_only = True
def __getattr__(self, attribute):
try:
return super(BBConfiguration, self).__getattribute__(attribute)
except AttributeError:
return None
_warnings_showwarning = warnings.showwarning
def _showwarning(message, category, filename, lineno, file=None, line=None):
@ -39,82 +50,70 @@ warnings.showwarning = _showwarning
warnings.simplefilter("ignore", DeprecationWarning)
import bb.event
# Need to map our I/O correctly. stdout is a pipe to the server expecting
# events. We save this and then map stdout to stderr.
eventfd = os.dup(sys.stdout.fileno())
bb.event.worker_pipe = os.fdopen(eventfd, 'w', 0)
# map stdout to stderr
os.dup2(sys.stderr.fileno(), sys.stdout.fileno())
# Replace those fds with our own
#logout = data.expand("${TMPDIR}/log/stdout.%s" % os.getpid(), self.cfgData, True)
#mkdirhier(os.path.dirname(logout))
#newso = open("/tmp/stdout.%s" % os.getpid(), 'w')
#os.dup2(newso.fileno(), sys.stdout.fileno())
#os.dup2(newso.fileno(), sys.stderr.fileno())
# Don't read from stdin from the parent
si = file("/dev/null", 'r')
os.dup2(si.fileno( ), sys.stdin.fileno( ))
# We don't want to see signals to our parent, e.g. Ctrl+C
os.setpgrp()
# Save out the PID so that the event can include it the
# events
bb.event.worker_pid = os.getpid()
bb.event.useStdout = False
hashfile = sys.argv[1]
buildfile = sys.argv[2]
taskname = sys.argv[3]
import bb.cooker
p = pickle.Unpickler(file(hashfile, "rb"))
hashdata = p.load()
buildfile = sys.argv[1]
taskname = sys.argv[2]
if len(sys.argv) >= 4:
dryrun = sys.argv[3]
else:
dryrun = False
if len(sys.argv) >= 5:
hashfile = sys.argv[4]
p = pickle.Unpickler(file(hashfile, "rb"))
hashdata = p.load()
else:
hashdata = None
debug = hashdata["msg-debug"]
debug_domains = hashdata["msg-debug-domains"]
verbose = hashdata["verbose"]
handler = bb.event.LogHandler()
logger.addHandler(handler)
bb.utils.init_logger(bb.msg, verbose, debug, debug_domains)
#An example to make debug log messages show up
#bb.msg.init_msgconfig(True, 3, [])
cooker = bb.cooker.BBCooker(BBConfiguration(debug, debug_domains), None)
cooker.parseConfiguration()
console = logging.StreamHandler(sys.stdout)
format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
bb.msg.addDefaultlogFilter(console)
console.setFormatter(format)
cooker.bb_cache = bb.cache.init(cooker)
cooker.status = bb.cache.CacheData()
def worker_fire(event, d):
if isinstance(event, logging.LogRecord):
console.handle(event)
bb.event.worker_fire = worker_fire
bb.event.worker_pid = os.getpid()
(fn, cls) = cooker.bb_cache.virtualfn2realfn(buildfile)
initialenv = os.environ.copy()
config = BBConfiguration()
def register_idle_function(self, function, data):
pass
cooker = bb.cooker.BBCooker(config, register_idle_function, initialenv)
config_data = cooker.configuration.data
cooker.status = config_data
cooker.handleCollections(bb.data.getVar("BBFILE_COLLECTIONS", config_data, 1))
fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
buildfile = cooker.matchFile(fn)
fn = cooker.bb_cache.realfn2virtual(buildfile, cls)
fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
cooker.buildSetVars()
# Load data into the cache for fn and parse the loaded cache data
the_data = cooker.bb_cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
cooker.bb_cache.setData(fn, buildfile, the_data)
cooker.bb_cache.handle_data(fn, cooker.status)
#exportlist = bb.utils.preserved_envvars_export_list()
#bb.utils.filter_environment(exportlist)
the_data = bb.cache.Cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
if taskname.endswith("_setscene"):
the_data.setVarFlag(taskname, "quieterrors", "1")
bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
for h in hashdata["hashes"]:
bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
for h in hashdata["deps"]:
bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
if hashdata:
bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
for h in hashdata["hashes"]:
bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
for h in hashdata["deps"]:
bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
ret = 0
if sys.argv[4] != "True":
if dryrun != "True":
ret = bb.build.exec_task(fn, taskname, the_data)
sys.exit(ret)

View File

@ -149,8 +149,7 @@ def exec_func(func, d, dirs = None):
adir = dirs[-1]
else:
adir = data.getVar('B', d, 1)
if not os.path.exists(adir):
adir = None
bb.utils.mkdirhier(adir)
ispython = flags.get('python')
if flags.get('fakeroot') and not flags.get('task'):
@ -223,7 +222,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
with open(runfile, 'w') as script:
script.write('#!/bin/sh -e\n')
if bb.msg.loggerVerbose:
if bb.msg.loggerDefaultVerbose:
script.write("set -x\n")
data.emit_func(function, script, d)
if cwd:
@ -234,7 +233,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
cmd = runfile
if bb.msg.loggerVerbose:
if bb.msg.loggerDefaultVerbose:
logfile = LogTee(logger, sys.stdout)
else:
logfile = sys.stdout

View File

@ -150,117 +150,79 @@ def parser_cache_savemerge(d):
bb.utils.unlockfile(glf)
Logger = logging.getLoggerClass()
class BufferedLogger(Logger):
def __init__(self, name, level=0, target=None):
Logger.__init__(self, name)
self.setLevel(level)
self.buffer = []
self.target = target
def handle(self, record):
self.buffer.append(record)
def flush(self):
for record in self.buffer:
self.target.handle(record)
self.buffer = []
class PythonParser():
class ValueVisitor():
"""Visitor to traverse a python abstract syntax tree and obtain
the variables referenced via bitbake metadata APIs, and the external
functions called.
getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
def warn(self, func, arg):
"""Warn about calls of bitbake APIs which pass a non-literal
argument for the variable name, as we're not able to track such
a reference.
"""
getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
expands = ("d.expand", "bb.data.expand", "data.expand")
execs = ("bb.build.exec_func", "bb.build.exec_task")
try:
funcstr = codegen.to_source(func)
argstr = codegen.to_source(arg)
except TypeError:
self.log.debug(2, 'Failed to convert function and argument to source form')
else:
self.log.debug(1, self.unhandled_message % (funcstr, argstr))
@classmethod
def _compare_name(cls, strparts, node):
"""Given a sequence of strings representing a python name,
where the last component is the actual Name and the prior
elements are Attribute nodes, determine if the supplied node
matches.
"""
def visit_Call(self, node):
name = self.called_node_name(node.func)
if name in self.getvars:
if isinstance(node.args[0], ast.Str):
self.var_references.add(node.args[0].s)
else:
self.warn(node.func, node.args[0])
elif name in self.execfuncs:
if isinstance(node.args[0], ast.Str):
self.var_execs.add(node.args[0].s)
else:
self.warn(node.func, node.args[0])
elif name and isinstance(node.func, (ast.Name, ast.Attribute)):
self.execs.add(name)
if not strparts:
return True
current, rest = strparts[0], strparts[1:]
def called_node_name(self, node):
"""Given a called node, return its original string form"""
components = []
while node:
if isinstance(node, ast.Attribute):
if current == node.attr:
return cls._compare_name(rest, node.value)
components.append(node.attr)
node = node.value
elif isinstance(node, ast.Name):
if current == node.id:
return True
return False
@classmethod
def compare_name(cls, value, node):
"""Convenience function for the _compare_node method, which
can accept a string (which is split by '.' for you), or an
iterable of strings, in which case it checks to see if any of
them match, similar to isinstance.
"""
if isinstance(value, basestring):
return cls._compare_name(tuple(reversed(value.split("."))),
node)
components.append(node.id)
return '.'.join(reversed(components))
else:
return any(cls.compare_name(item, node) for item in value)
break
def __init__(self, value):
self.var_references = set()
self.var_execs = set()
self.direct_func_calls = set()
self.var_expands = set()
self.value = value
@classmethod
def warn(cls, func, arg):
"""Warn about calls of bitbake APIs which pass a non-literal
argument for the variable name, as we're not able to track such
a reference.
"""
try:
funcstr = codegen.to_source(func)
argstr = codegen.to_source(arg)
except TypeError:
logger.debug(2, 'Failed to convert function and argument to source form')
else:
logger.debug(1, "Warning: in call to '%s', argument '%s' is "
"not a literal", funcstr, argstr)
def visit_Call(self, node):
if self.compare_name(self.getvars, node.func):
if isinstance(node.args[0], ast.Str):
self.var_references.add(node.args[0].s)
else:
self.warn(node.func, node.args[0])
elif self.compare_name(self.expands, node.func):
if isinstance(node.args[0], ast.Str):
self.warn(node.func, node.args[0])
self.var_expands.update(node.args[0].s)
elif isinstance(node.args[0], ast.Call) and \
self.compare_name(self.getvars, node.args[0].func):
pass
else:
self.warn(node.func, node.args[0])
elif self.compare_name(self.execs, node.func):
if isinstance(node.args[0], ast.Str):
self.var_execs.add(node.args[0].s)
else:
self.warn(node.func, node.args[0])
elif isinstance(node.func, ast.Name):
self.direct_func_calls.add(node.func.id)
elif isinstance(node.func, ast.Attribute):
# We must have a qualified name. Therefore we need
# to walk the chain of 'Attribute' nodes to determine
# the qualification.
attr_node = node.func.value
identifier = node.func.attr
while isinstance(attr_node, ast.Attribute):
identifier = attr_node.attr + "." + identifier
attr_node = attr_node.value
if isinstance(attr_node, ast.Name):
identifier = attr_node.id + "." + identifier
self.direct_func_calls.add(identifier)
def __init__(self):
#self.funcdefs = set()
def __init__(self, name, log):
self.var_references = set()
self.var_execs = set()
self.execs = set()
#self.external_cmds = set()
self.references = set()
self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
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):
h = hash(str(node))
if h in pythonparsecache:
@ -271,24 +233,25 @@ class PythonParser():
code = compile(check_indent(str(node)), "<string>", "exec",
ast.PyCF_ONLY_AST)
visitor = self.ValueVisitor(code)
for n in ast.walk(code):
if n.__class__.__name__ == "Call":
visitor.visit_Call(n)
self.visit_Call(n)
self.references.update(visitor.var_references)
self.references.update(visitor.var_execs)
self.execs = visitor.direct_func_calls
self.references.update(self.var_references)
self.references.update(self.var_execs)
pythonparsecache[h] = {}
pythonparsecache[h]["refs"] = self.references
pythonparsecache[h]["execs"] = self.execs
class ShellParser():
def __init__(self):
def __init__(self, name, log):
self.funcdefs = set()
self.allexecs = set()
self.execs = set()
self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
self.unhandled_template = "unable to handle non-literal command '%s'"
self.unhandled_template = "while parsing %s, %s" % (name, self.unhandled_template)
def parse_shell(self, value):
"""Parse the supplied shell code in a string, returning the external
@ -403,8 +366,7 @@ class ShellParser():
cmd = word[1]
if cmd.startswith("$"):
logger.debug(1, "Warning: execution of non-literal "
"command '%s'", 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

@ -288,7 +288,9 @@ class BBCooker:
self.status = bb.cache.CacheData(self.caches_array)
self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
fn = self.matchFile(buildfile)
fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
fn = self.matchFile(fn)
fn = bb.cache.Cache.realfn2virtual(fn, cls)
elif len(pkgs_to_build) == 1:
self.updateCache()

View File

@ -49,6 +49,7 @@ from bb import data_smart
from bb import codeparser
import bb
logger = data_smart.logger
_dict_type = data_smart.DataSmart
def init():
@ -258,7 +259,7 @@ def emit_func(func, o=sys.__stdout__, d = init()):
emit_var(key, o, d, False) and o.write('\n')
emit_var(func, o, d, False) and o.write('\n')
newdeps = bb.codeparser.ShellParser().parse_shell(d.getVar(func, True))
newdeps = bb.codeparser.ShellParser(func, logger).parse_shell(d.getVar(func, True))
seen = set()
while newdeps:
deps = newdeps
@ -267,39 +268,45 @@ def emit_func(func, o=sys.__stdout__, d = init()):
for dep in deps:
if bb.data.getVarFlag(dep, "func", d):
emit_var(dep, o, d, False) and o.write('\n')
newdeps |= bb.codeparser.ShellParser().parse_shell(d.getVar(dep, True))
newdeps |= bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
newdeps -= seen
def update_data(d):
"""Performs final steps upon the datastore, including application of overrides"""
d.finalize()
def build_dependencies(key, keys, shelldeps, d):
def build_dependencies(key, keys, shelldeps, vardepvals, d):
deps = set()
vardeps = d.getVarFlag(key, "vardeps", True)
try:
if d.getVarFlag(key, "func"):
value = d.getVar(key, False)
if key in vardepvals:
value = d.getVarFlag(key, "vardepvalue", True)
elif d.getVarFlag(key, "func"):
if d.getVarFlag(key, "python"):
parsedvar = d.expandWithRefs(d.getVar(key, False), key)
parser = bb.codeparser.PythonParser()
parsedvar = d.expandWithRefs(value, key)
parser = bb.codeparser.PythonParser(key, logger)
parser.parse_python(parsedvar.value)
deps = deps | parser.references
else:
parsedvar = d.expandWithRefs(d.getVar(key, False), key)
parser = bb.codeparser.ShellParser()
parsedvar = d.expandWithRefs(value, key)
parser = bb.codeparser.ShellParser(key, logger)
parser.parse_shell(parsedvar.value)
deps = deps | shelldeps
if vardeps is None:
parser.log.flush()
deps = deps | parsedvar.references
deps = deps | (keys & parser.execs) | (keys & parsedvar.execs)
else:
parser = d.expandWithRefs(d.getVar(key, False), key)
parser = d.expandWithRefs(value, key)
deps |= parser.references
deps = deps | (keys & parser.execs)
deps |= set((d.getVarFlag(key, "vardeps", True) or "").split())
deps |= set((vardeps or "").split())
deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
except:
bb.note("Error expanding variable %s" % key)
raise
return deps
return deps, value
#bb.note("Variable %s references %s and calls %s" % (key, str(deps), str(execs)))
#d.setVarFlag(key, "vardeps", deps)
@ -307,12 +314,14 @@ def generate_dependencies(d):
keys = set(key for key in d.keys() if not key.startswith("__"))
shelldeps = set(key for key in keys if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
vardepvals = set(key for key in keys if d.getVarFlag(key, "vardepvalue"))
deps = {}
values = {}
tasklist = bb.data.getVar('__BBTASKS', d) or []
for task in tasklist:
deps[task] = build_dependencies(task, keys, shelldeps, d)
deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
newdeps = deps[task]
seen = set()
while newdeps:
@ -321,11 +330,11 @@ def generate_dependencies(d):
newdeps = set()
for dep in nextdeps:
if dep not in deps:
deps[dep] = build_dependencies(dep, keys, shelldeps, d)
deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, vardepvals, d)
newdeps |= deps[dep]
newdeps -= seen
#print "For %s: %s" % (task, str(taskdeps[task]))
return tasklist, deps
return tasklist, deps, values
def inherits_class(klass, d):
val = getVar('__inherit_cache', d) or []

View File

@ -68,8 +68,14 @@ class VariableParse:
code = match.group()[3:-1]
codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
parser = bb.codeparser.PythonParser()
parser = bb.codeparser.PythonParser(self.varname, logger)
parser.parse_python(code)
if self.varname:
vardeps = self.d.getVarFlag(self.varname, "vardeps", True)
if vardeps is None:
parser.log.flush()
else:
parser.log.flush()
self.references |= parser.references
self.execs |= parser.execs

View File

@ -197,6 +197,7 @@ def uri_replace(ud, uri_find, uri_replace, d):
uri_decoded = list(decodeurl(ud.url))
uri_find_decoded = list(decodeurl(uri_find))
uri_replace_decoded = list(decodeurl(uri_replace))
logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, uri_find_decoded, uri_replace_decoded))
result_decoded = ['', '', '', '', '', {}]
for i in uri_find_decoded:
loc = uri_find_decoded.index(i)
@ -209,12 +210,18 @@ def uri_replace(ud, uri_find, uri_replace, d):
result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
if uri_find_decoded.index(i) == 2:
if ud.mirrortarball:
result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.mirrortarball))
if result_decoded[loc].endswith("/"):
result_decoded[loc] = os.path.dirname(result_decoded[loc])
result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.mirrortarball))
elif ud.localpath:
result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.localpath))
if result_decoded[loc].endswith("/"):
result_decoded[loc] = os.path.dirname(result_decoded[loc])
result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.localpath))
else:
return ud.url
return encodeurl(result_decoded)
result = encodeurl(result_decoded)
logger.debug(2, "For url %s returning %s" % (ud.url, result))
return result
methods = []
urldata_cache = {}
@ -385,7 +392,8 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
exportvars = ['PATH', 'GIT_PROXY_COMMAND', 'GIT_PROXY_HOST',
'GIT_PROXY_PORT', 'GIT_CONFIG', 'http_proxy', 'ftp_proxy',
'https_proxy', 'no_proxy', 'ALL_PROXY', 'all_proxy',
'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME']
'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME',
'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
for var in exportvars:
val = bb.data.getVar(var, d, True)

View File

@ -190,7 +190,7 @@ class Git(FetchMethod):
logger.debug(1, "No Origin")
runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d)
fetch_cmd = "%s fetch --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
fetch_cmd = "%s fetch -f --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
runfetchcmd(fetch_cmd, d)
runfetchcmd("%s prune-packed" % ud.basecmd, d)
@ -220,7 +220,7 @@ class Git(FetchMethod):
if os.path.exists(destdir):
bb.utils.prunedir(destdir)
runfetchcmd("git clone -s -n %s %s" % (ud.clonedir, destdir), d)
runfetchcmd("git clone -s -n %s/ %s" % (ud.clonedir, destdir), d)
if not ud.nocheckout:
os.chdir(destdir)
if subdir != "":

View File

@ -50,9 +50,6 @@ class Local(FetchMethod):
path = url.split("://")[1]
path = path.split(";")[0]
newpath = path
dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
if os.path.exists(dldirfile):
return dldirfile
if path[0] != "/":
filespath = data.getVar('FILESPATH', d, True)
if filespath:
@ -62,6 +59,7 @@ class Local(FetchMethod):
if filesdir:
newpath = os.path.join(filesdir, path)
if not os.path.exists(newpath) and path.find("*") == -1:
dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
return dldirfile
return newpath

View File

@ -106,8 +106,8 @@ def init_msgconfig(verbose, debug, debug_domains = []):
"""
Set default verbosity and debug levels config the logger
"""
bb.msg.loggerDebugLevel = debug
bb.msg.loggerVerbose = verbose
bb.msg.loggerDefaultDebugLevel = debug
bb.msg.loggerDefaultVerbose = verbose
bb.msg.loggerDefaultDomains = debug_domains
def addDefaultlogFilter(handler):

View File

@ -148,7 +148,7 @@ def handle(fn, d, include):
# DONE WITH PARSING... time to evaluate
if ext != ".bbclass":
data.setVar('FILE', fn, d)
data.setVar('FILE', abs_fn, d)
statements.eval(d)

View File

@ -102,7 +102,7 @@ def handle(fn, data, include):
feeder(lineno, s, fn, statements)
# DONE WITH PARSING... time to evaluate
bb.data.setVar('FILE', fn, data)
bb.data.setVar('FILE', abs_fn, data)
statements.eval(data)
if oldfile:
bb.data.setVar('FILE', oldfile, data)

View File

@ -47,9 +47,10 @@ if hasattr(sqlite3, 'enable_shared_cache'):
@total_ordering
class SQLTable(collections.MutableMapping):
"""Object representing a table/domain in the database"""
def __init__(self, cursor, table):
self.cursor = cursor
def __init__(self, cachefile, table):
self.cachefile = cachefile
self.table = table
self.cursor = connect(self.cachefile)
self._execute("CREATE TABLE IF NOT EXISTS %s(key TEXT, value TEXT);"
% table)
@ -63,6 +64,8 @@ class SQLTable(collections.MutableMapping):
except sqlite3.OperationalError as exc:
if 'database is locked' in str(exc) and count < 500:
count = count + 1
self.cursor.close()
self.cursor = connect(self.cachefile)
continue
raise
@ -188,7 +191,7 @@ class PersistData(object):
del self.data[domain][key]
def connect(database):
return sqlite3.connect(database, timeout=30, isolation_level=None)
return sqlite3.connect(database, timeout=5, isolation_level=None)
def persist(domain, d):
"""Convenience factory for SQLTable objects based upon metadata"""
@ -201,5 +204,4 @@ def persist(domain, d):
bb.utils.mkdirhier(cachedir)
cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3")
connection = connect(cachefile)
return SQLTable(connection, domain)
return SQLTable(cachefile, domain)

View File

@ -1203,8 +1203,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
if task in self.rq.scenequeue_covered:
continue
if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
self.rq.scenequeue_covered.add(task)
found = True
ok = True
for revdep in self.rqdata.runq_revdeps[task]:
if self.rqdata.runq_fnid[task] != self.rqdata.runq_fnid[revdep]:
ok = False
break
if ok:
found = True
self.rq.scenequeue_covered.add(task)
# Detect when the real task needs to be run anyway by looking to see
# if any of its dependencies within the same package are scheduled
@ -1227,9 +1233,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
for task in self.rq.scenequeue_covered:
self.task_skip(task)
event.fire(bb.event.StampUpdate(self.rqdata.target_pairs, self.rqdata.dataCache.stamp), self.cfgData)
schedulers = self.get_schedulers()
@ -1323,8 +1326,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
task = self.sched.next()
if task is not None:
fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
taskname = self.rqdata.runq_task[task]
if task in self.rq.scenequeue_covered:
logger.debug(2, "Setscene covered task %s (%s)", task,
self.rqdata.get_user_idstring(task))
self.task_skip(task)
return True
if self.rq.check_stamp_task(task, taskname):
logger.debug(2, "Stamp current task %s (%s)", task,
self.rqdata.get_user_idstring(task))
@ -1412,18 +1421,20 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
sq_revdeps.append(copy.copy(self.rqdata.runq_revdeps[task]))
sq_revdeps_new.append(set())
if (len(self.rqdata.runq_revdeps[task]) == 0) and task not in self.rqdata.runq_setscene:
endpoints[task] = None
endpoints[task] = set()
for task in self.rqdata.runq_setscene:
for dep in self.rqdata.runq_depends[task]:
endpoints[dep] = task
if dep not in endpoints:
endpoints[dep] = set()
endpoints[dep].add(task)
def process_endpoints(endpoints):
newendpoints = {}
for point, task in endpoints.items():
tasks = set()
if task:
tasks.add(task)
tasks |= task
if sq_revdeps_new[point]:
tasks |= sq_revdeps_new[point]
sq_revdeps_new[point] = set()
@ -1448,6 +1459,28 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
elif len(sq_revdeps_new[task]) != 0:
bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, aborting. Please report this problem.")
# Resolve setscene inter-task dependencies
# e.g. do_sometask_setscene[depends] = "targetname:do_someothertask_setscene"
# Note that anything explicitly depended upon will have its reverse dependencies removed to avoid circular dependencies
for task in self.rqdata.runq_setscene:
realid = self.rqdata.taskData.gettask_id(self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]], self.rqdata.runq_task[task] + "_setscene", False)
idepends = self.rqdata.taskData.tasks_idepends[realid]
for (depid, idependtask) in idepends:
if depid not in self.rqdata.taskData.build_targets:
continue
depdata = self.rqdata.taskData.build_targets[depid][0]
if depdata is None:
continue
dep = self.rqdata.taskData.fn_index[depdata]
taskid = self.rqdata.get_task_id(self.rqdata.taskData.getfn_id(dep), idependtask.replace("_setscene", ""))
if taskid is None:
bb.msg.fatal("RunQueue", "Task %s depends upon nonexistant task %s:%s" % (self.rqdata.taskData.tasks_name[realid], dep, idependtask))
sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid))
# Have to zero this to avoid circular dependencies
sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set()
#for task in xrange(len(sq_revdeps_squash)):
# print "Task %s: %s.%s is %s " % (task, self.taskData.fn_index[self.runq_fnid[self.runq_setscene[task]]], self.runq_task[self.runq_setscene[task]] + "_setscene", sq_revdeps_squash[task])
@ -1506,8 +1539,9 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
for task in xrange(len(self.sq_revdeps)):
if task not in valid_new and task not in noexec:
realtask = self.rqdata.runq_setscene[task]
logger.debug(2, 'No package found, so skipping setscene task %s',
self.rqdata.get_user_idstring(task))
self.rqdata.get_user_idstring(realtask))
self.task_failoutright(task)
logger.info('Executing SetScene Tasks')
@ -1580,7 +1614,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
taskname = self.rqdata.runq_task[realtask] + "_setscene"
if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask]):
logger.debug(2, 'Stamp for underlying task %s(%s) is current, so skipping setscene variant',
task, self.rqdata.get_user_idstring(task))
task, self.rqdata.get_user_idstring(realtask))
self.task_failoutright(task)
return True
@ -1622,7 +1656,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
for task in oldcovered:
self.rq.scenequeue_covered.add(self.rqdata.runq_setscene[task])
logger.debug(1, 'We can skip tasks %s', self.rq.scenequeue_covered)
logger.debug(1, 'We can skip tasks %s', sorted(self.rq.scenequeue_covered))
self.rq.state = runQueueRunInit
return True

View File

@ -72,11 +72,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
def _build_data(self, fn, d):
tasklist, gendeps = bb.data.generate_dependencies(d)
tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
taskdeps = {}
basehash = {}
lookupcache = {}
for task in tasklist:
data = d.getVar(task, False)
@ -101,6 +100,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
alldeps = seen - self.basewhitelist
for dep in sorted(alldeps):
data = data + dep
if dep in lookupcache:
var = lookupcache[dep]
else:
@ -135,7 +135,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
k = fn + "." + task
data = dataCache.basetaskhash[k]
self.runtaskdeps[k] = []
for dep in sorted(deps):
for dep in sorted(deps, key=clean_basepath):
# We only manipulate the dependencies for packages not in the whitelist
if self.twl and not self.twl.search(dataCache.pkg_fn[fn]):
# then process the actual dependencies
@ -159,7 +159,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
k = fn + "." + task
if runtime == "customfile":
sigfile = stampbase
elif runtime:
elif runtime and k in self.taskhash:
sigfile = stampbase + "." + task + ".sigdata" + "." + self.taskhash[k]
else:
sigfile = stampbase + "." + task + ".sigbasedata" + "." + self.basehash[k]
@ -180,7 +180,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
data['gendeps'][dep] = self.gendeps[fn][dep]
data['varvals'][dep] = self.lookupcache[fn][dep]
if runtime:
if runtime and k in self.taskhash:
data['runtaskdeps'] = self.runtaskdeps[k]
data['runtaskhashes'] = {}
for dep in data['runtaskdeps']:
@ -217,19 +217,32 @@ def dump_this_task(outfile, d):
task = "do_" + d.getVar("BB_CURRENTTASK", True)
bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile")
def clean_basepath(a):
if a.startswith("virtual:"):
b = a.rsplit(":", 1)[0] + a.rsplit("/", 1)[1]
else:
b = a.rsplit("/", 1)[1]
return b
def clean_basepaths(a):
b = {}
for x in a:
b[clean_basepath(x)] = a[x]
return b
def compare_sigfiles(a, b):
p1 = pickle.Unpickler(file(a, "rb"))
a_data = p1.load()
p2 = pickle.Unpickler(file(b, "rb"))
b_data = p2.load()
def dict_diff(a, b):
def dict_diff(a, b, whitelist=set()):
sa = set(a.keys())
sb = set(b.keys())
common = sa & sb
changed = set()
for i in common:
if a[i] != b[i]:
if a[i] != b[i] and i not in whitelist:
changed.add(i)
added = sa - sb
removed = sb - sa
@ -237,20 +250,23 @@ def compare_sigfiles(a, b):
if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
print "basewhitelist changed from %s to %s" % (a_data['basewhitelist'], b_data['basewhitelist'])
print "changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist'])
if 'taskwhitelist' in a_data and a_data['taskwhitelist'] != b_data['taskwhitelist']:
print "taskwhitelist changed from %s to %s" % (a_data['taskwhitelist'], b_data['taskwhitelist'])
print "changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist'])
if a_data['taskdeps'] != b_data['taskdeps']:
print "Task dependencies changed from %s to %s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
print "Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
if a_data['basehash'] != b_data['basehash']:
print "basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash'])
changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'])
changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'], a_data['basewhitelist'] & b_data['basewhitelist'])
if changed:
for dep in changed:
print "List of dependencies for variable %s changed from %s to %s" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep])
print "changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep])
if added:
for dep in added:
print "Dependency on variable %s was added" % (dep)
@ -265,7 +281,9 @@ def compare_sigfiles(a, b):
print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
changed, added, removed = dict_diff(a_data['runtaskhashes'], b_data['runtaskhashes'])
a = clean_basepaths(a_data['runtaskhashes'])
b = clean_basepaths(b_data['runtaskhashes'])
changed, added, removed = dict_diff(a, b)
if added:
for dep in added:
print "Dependency on task %s was added" % (dep)
@ -274,9 +292,10 @@ def compare_sigfiles(a, b):
print "Dependency on task %s was removed" % (dep)
if changed:
for dep in changed:
print "Hash for dependent task %s changed from %s to %s" % (dep, a_data['runtaskhashes'][dep], b_data['runtaskhashes'][dep])
print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
elif 'runtaskdeps' in a_data and 'runtaskdeps' in b_data and sorted(a_data['runtaskdeps']) != sorted(b_data['runtaskdeps']):
print "Tasks this task depends on changed from %s to %s" % (sorted(a_data['runtaskdeps']), sorted(b_data['runtaskdeps']))
print "changed items: %s" % a_data['runtaskdeps'].symmetric_difference(b_data['runtaskdeps'])
def dump_sigfile(a):
p1 = pickle.Unpickler(file(a, "rb"))

View File

@ -88,6 +88,8 @@ class HobHandler(gobject.GObject):
deploy_dir = self.server.runCommand(["getVariable", "DEPLOY_DIR"])
self.image_out_dir = os.path.join(deploy_dir, "images")
self.image_output_types = self.server.runCommand(["getVariable", "IMAGE_FSTYPES"]).split(" ")
self.bbpath = self.server.runCommand(["getVariable", "BBPATH"])
self.bbfiles = self.server.runCommand(["getVariable", "BBFILES"])
def run_next_command(self):
if self.current_command and not self.generating:
@ -263,8 +265,7 @@ class HobHandler(gobject.GObject):
self.build_queue = targets
if not self.bbpath_ok:
bbpath = self.server.runCommand(["getVariable", "BBPATH"])
if self.image_dir in bbpath.split(":"):
if self.image_dir in self.bbpath.split(":"):
self.bbpath_ok = True
else:
nbbp = self.image_dir
@ -272,8 +273,8 @@ class HobHandler(gobject.GObject):
if not self.bbfiles_ok:
import re
pattern = "%s/\*.bb" % self.image_dir
bbfiles = self.server.runCommand(["getVariable", "BBFILES"]).split(" ")
for files in bbfiles:
for files in self.bbfiles.split(" "):
if re.match(pattern, files):
self.bbfiles_ok = True
@ -327,7 +328,7 @@ class HobHandler(gobject.GObject):
return self.image_output_types
def get_image_deploy_dir(self):
return self.img_out_dir
return self.image_out_dir
def make_temp_dir(self):
bb.utils.mkdirhier(self.image_dir)

View File

@ -39,6 +39,7 @@ class HobPrefs(gtk.Dialog):
self.selected_image_types = handler.remove_image_output_type(ot)
self.configurator.setConfVar('IMAGE_FSTYPES', "%s" % " ".join(self.selected_image_types).lstrip(" "))
self.reload_required = True
def sdk_machine_combo_changed_cb(self, combo, handler):
sdk_mach = combo.get_active_text()

View File

@ -179,6 +179,10 @@ class RunningBuild (gobject.GObject):
# that we need to attach to a task.
self.tasks_to_iter[(package, task)] = i
# If we don't handle these the GUI does not proceed
elif isinstance(event, bb.build.TaskInvalid):
return
elif isinstance(event, bb.build.TaskBase):
current = self.tasks_to_iter[(package, task)]
parent = self.tasks_to_iter[(package, None)]

View File

@ -304,13 +304,11 @@ class MainWindow (gtk.Window):
self.image_combo.disconnect(self.image_combo_id)
self.image_combo_id = None
self.model.set_selected_image(self.selected_image)
self.selected_image = None
if not self.image_combo_id:
self.image_combo_id = self.image_combo.connect("changed", self.image_changed_cb)
if self.selected_packages:
self.model.set_selected_packages(self.selected_packages)
self.selected_packages = None
def reset_clicked_cb(self, button):
lbl = "<b>Reset your selections?</b>\n\nAny new changes you have made will be lost"
@ -398,11 +396,13 @@ class MainWindow (gtk.Window):
gtk.RESPONSE_OK))
response = chooser.run()
rep = BuildRep(None, None, None)
recipe = chooser.get_filename()
if response == gtk.RESPONSE_OK:
rep.loadRecipe(chooser.get_filename())
rep.loadRecipe(recipe)
self.save_path = recipe
self.model.load_image_rep(rep)
self.dirty = False
chooser.destroy()
self.model.load_image_rep(rep)
self.dirty = False
def bake_clicked_cb(self, button):
build_image = True

View File

@ -443,7 +443,7 @@ def lockfile(name, shared=False, retry=True):
return lf
lf.close()
except Exception:
continue
pass
if not retry:
return None
@ -505,7 +505,6 @@ def preserved_envvars_exported():
'SHELL',
'TERM',
'USER',
'USERNAME',
]
def preserved_envvars_exported_interactive():

View File

@ -1,48 +1,61 @@
# This is a single Makefile to handle all generated Yocto Project documents.
# The Makefile needs to live in the documents directory and all figures used
# in any manuals must be PNG files and live in the individual book's figures
# directory.
# in any manuals must be .PNG files and live in the individual book's figures
# directory. Note that the figures for the Yocto Project Development Manual
# differ between the 'master' and 'edison' branches.
#
# The Makefile has these targets:
#
# pdf: generates a PDF version of a manual. Not valid for the Quick Start
# html: generates an HTML version of a manual.
# tarball: creates a tarball for the doc files.
# pdf: generates a PDF version of a manual. Not valid for the Quick Start
# html: generates an HTML version of a manual.
# tarball: creates a tarball for the doc files.
# validate: validates
# publish: pushes generated files to the Yocto Project website
# clean: removes files
# publish: pushes generated files to the Yocto Project website
# clean: removes files
#
# The Makefile generates an HTML and PDF version of every document except the
# Yocto Project Quick Start. The Quick Start is in HTML form only. The variable
# The command-line argument DOC represents the folder name in which a particular
# document is stored. The command-line argument VER represents the distro
# version of the Yocto Release for which the manuals are being generated.
# DOC is used to indicate the folder name for a given manual. The variable
# VER represents the distro version of the Yocto Release for which the manuals
# are being generated. The variable BRANCH is used to indicate the 'edison'
# branch and is used only when DOC=dev-manual (making the YP Development
# Manual).
#
# To build the HTML and PDF versions of the manual you must invoke the Makefile
# with the DOC argument. If you are going to publish the manual then you
# you must invoke the Makefile with both the DOC and the VER argument.
# If you are building the 'edison' version of the YP DEvelopment Manual then
# you must use the DOC and BRANCH arguments.
#
# Examples:
#
# make DOC=bsp-guide
# make DOC=yocto-project-qs
# make pdf DOC=poky-ref-manual
# make DOC=dev-manual BRANCH=edison
#
# The first example generates the HTML and PDF versions of the BSP Guide.
# The second example generates the HTML version only of the Quick Start. Note that
# the Quick Start only has an HTML version available. The third example generates
# both the PDF and HTML versions of the Yocto Project Reference Manual.
# both the PDF and HTML versions of the Yocto Project Reference Manual. The
# last example generates both the PDF and HTML 'edison' versions of the YP
# Development Manual.
#
# Use the publish target to push the generated manuals to the Yocto Project
# website. All files needed for the manual's HTML form are pushed as well as the
# PDF version (if applicable).
# Examples:
#
# make publish DOC=bsp-guide VER=1.1
# make publish DOC=adt-manual VER=1.1
# make publish DOC=bsp-guide VER=1.2
# make publish DOC=adt-manual VER=1.2
# make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
# make publish DOC=dev-manual VER=1.2
#
# The first example publishes the 1.1 version of both the PDF and HTML versions of
# the BSP Guide. The second example publishes the 1.1 version of both the PDF and
# HTML versions of the ADT Manual.
# The first example publishes the 1.2 version of both the PDF and HTML versions of
# the BSP Guide. The second example publishes the 1.2 version of both the PDF and
# HTML versions of the ADT Manual. The third example publishes the PDF and HTML
# 'edison' versions of the YP Development Manual. Finally, the last example publishes
# the PDF and HTML 'master' versions of the YP Development Manual.
#
ifeq ($(DOC),bsp-guide)
@ -66,10 +79,32 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
--stringparam section.label.includes.component.label 1 \
--xinclude
ALLPREQ = html pdf tarball
TARFILES = style.css dev-manual.html dev-manual.pdf figures/bsp-dev-flow.png figures/dev-title.png \
#
# Note that the tarfile might produce the "Cannot stat: No such file or directory" error
# message for .PNG files that are not present when building a particular branch. The
# list of files is all-inclusive for all branches.
#
ifeq ($(BRANCH),edison)
TARFILES = style.css dev-manual.html dev-manual.pdf \
figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
figures/kernel-example-repos.png figures/kernel-overview-1.png figures/kernel-overview-2.png \
figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png
figures/kernel-example-repos-edison.png \
figures/kernel-overview-1.png figures/kernel-overview-2.png \
figures/kernel-overview-3-edison.png \
figures/source-repos.png figures/yp-download.png \
figures/wip.png
else
TARFILES = style.css dev-manual.html dev-manual.pdf \
figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
figures/kernel-example-repos.png \
figures/kernel-overview-1.png figures/kernel-overview-2.png \
figures/kernel-overview-3.png \
figures/source-repos.png figures/yp-download.png \
figures/wip.png
endif
MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
FIGURES = figures
STYLESHEET = $(DOC)/*.css

View File

@ -12,9 +12,9 @@
Toolchain Tarball)</link>".
And, that sourcing your architecture-specific environment setup script
initializes a suitable cross-toolchain development environment.
This setup occurs by adding the compiler, QEMU scripts, QEMU binary,
During the setup, locations for the compiler, QEMU scripts, QEMU binary,
a special version of <filename>pkgconfig</filename> and other useful
utilities to the <filename>PATH</filename> variable.
utilities are added to the <filename>PATH</filename> variable.
Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename>
are also defined so that,
for example, <filename>configure.sh</filename> can find pre-generated
@ -28,7 +28,7 @@
<title>Autotools-Based Projects</title>
<para>
For an autotools-based project, you can use the cross-toolchain by just
For an Autotools-based project, you can use the cross-toolchain by just
passing the appropriate host option to <filename>configure.sh</filename>.
The host option you use is derived from the name of the environment setup
script in <filename>/opt/poky</filename> resulting from unpacking the
@ -47,6 +47,20 @@
This single command updates your project and rebuilds it using the appropriate
cross-toolchain tools.
</para>
<note>
If <filename>configure</filename> script results in problems recognizing the
<filename>--with-libtool-sysroot=&lt;sysroot-dir&gt;</filename> option,
regenerate the script to enable the support by doing the following and then
re-running the script:
<literallayout class='monospaced'>
$ libtoolize --automake
$ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
[-I &lt;dir_containing_your_project-specific_m4_macros&gt;]
$ autoconf
$ autoheader
$ automake -a
</literallayout>
</note>
</section>
<section id='makefile-based-projects'>

View File

@ -29,8 +29,7 @@
<para>
To develop within the Eclipse IDE, you need to do the following:
<orderedlist>
<listitem><para>Be sure the optimal version of the Eclipse IDE
is installed.</para></listitem>
<listitem><para>Install the optimal version of the Eclipse IDE.</para></listitem>
<listitem><para>Configure the Eclipse IDE.</para></listitem>
<listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
<listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
@ -54,10 +53,12 @@
<para>
Once you have downloaded the tarball, extract it into a clean
directory.
For example, the following command unpacks and installs the Eclipse IDE
into a clean directory named <filename>eclipse</filename>:
For example, the following commands unpack and install the Eclipse IDE
tarball found in the <filename>Downloads</filename> area
into a clean directory using the default name <filename>eclipse</filename>:
<literallayout class='monospaced'>
$ tar -xzvf ~/Downloads/Eclipse-SDK-3.7-linux-gtk-x86_64.tar.gz
$ cd ~
$ tar -xzvf ~/Downloads/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
</literallayout>
</para>
@ -96,16 +97,18 @@
Follow these general steps to configure Eclipse:
<orderedlist>
<listitem><para>Start the Eclipse IDE.</para></listitem>
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.
<listitem><para>Make sure you are in your Workbench and select
"Install New Software" from the "Help" pull-down menu.
</para></listitem>
<listitem><para>Select <filename>Indego - http://download.eclipse.org/releases/indego</filename>
<listitem><para>Select <filename>indigo - http://download.eclipse.org/releases/indigo</filename>
from the "Work with:" pull-down menu.</para></listitem>
<listitem><para>Expand the box next to <filename>Programming Languages</filename>
and select the <filename>Autotools Support for CDT (incubation)</filename>
and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.</para></listitem>
<listitem><para>After the Eclipse IDE restarts, click the
<listitem><para>After the Eclipse IDE restarts and from the Workbench, select
"Install New Software" from the "Help" pull-down menu.</para></listitem>
<listitem><para>Click the
"Available Software Sites" link.</para></listitem>
<listitem><para>Check the box next to
<filename>http://download.eclipse.org/tm/updates/3.3</filename>
@ -118,12 +121,13 @@
and select every item except <filename>RSE Unit Tests</filename> and
<filename>RSE WinCE Services (incubation)</filename>.</para></listitem>
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
<listitem><para>After the Eclipse IDE restarts, click the
"Available Software Sites" link.</para></listitem>
<listitem><para>Check the box next to
<filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
<listitem><para>If necessary, select
"Install New Software" from the "Help" pull-down menu so you can click the
"Available Software Sites" link again.</para></listitem>
<listitem><para>After clicking "Available Software Sites", check the box next to
<filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
and click "OK".</para></listitem>
<listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
<listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
from the "Work with:" pull-down menu.</para></listitem>
<listitem><para>Check the box next to <filename>CDT Main Features</filename>.
</para></listitem>
@ -136,39 +140,134 @@
</section>
<section id='installing-the-eclipse-yocto-plug-in'>
<title>Installing the Eclipse Yocto Plug-in</title>
<title>Installing or Accessing the Eclipse Yocto Plug-in</title>
<para>
To install the Eclipse Yocto Plug-in, follow these special steps.
The steps are WIP and are not final.
Once they are final they will be replaced with the actual steps:
<orderedlist>
<listitem><para>Open a shell and create a Git repository with:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/yocto-eclipse yocto-eclipse
</literallayout></para></listitem>
<listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
<listitem><para>Expand the "General" box and pick "existing projects into workspace".
</para></listitem>
<listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
</para></listitem>
<listitem><para>There will be three things there.
Select each one and install one at a time.
Do all three.</para></listitem>
<listitem><para>Restart everything.</para></listitem>
</orderedlist>
You can install the Eclipse Yocto Plug-in into the Eclipse application
one of two ways: using the Eclipse IDE and installing the plug-in as new software, or
using a built zip file.
If you don't want to permanently install the plug-in but just want to try it out
within the Eclipse environment, you can import the plug-in project from the
Yocto Project source repositories.
</para>
<para>
At this point I should be able to invoke Eclipse from the shell using the following:
<literallayout class='monospaced'>
$ cd ~/eclipse
$ ./eclipse -vmargs -XX:PermSize=256M
</literallayout>
What is shown is the default projects in the left pane.
I should be able to right-click on one of these and run as an Eclipse application to
bring up the Eclipse instance again with the Eclipse Yocto Plug-in working.
</para>
<section id='new-software'>
<title>Installing the Plug-in as New Software</title>
<para>
To install the Eclipse Yocto Plug-in as new software directly into the Eclipse IDE,
follow these steps:
<orderedlist>
<listitem><para>Start up the Eclipse IDE.</para></listitem>
<listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem>
<listitem><para>Click "Add..." in the "Work with:" area.</para></listitem>
<listitem><para>Enter
<filename>http://downloads.yoctoproject.org/releases/eclipse-plugin/1.1.1</filename>
in the URL field and provide a meaningful name in the "Name" field.</para></listitem>
<listitem><para>Click "OK" to have the entry added to the "Work with:"
drop-down list.</para></listitem>
<listitem><para>Select the entry for the plug-in from the "Work with:" drop-down
list.</para></listitem>
<listitem><para>Check the box next to <filename>Development tools and SDKs for Yocto Linux</filename>.
</para></listitem>
<listitem><para>Complete the remaining software installation steps and
then restart the Eclipse IDE to finish the installation of the plug-in.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='zip-file-method'>
<title>Installing the Plug-in from a Zip File</title>
<para>
To install the Eclipse Yocto Plug-in by building and installing a plug-in
zip file, follow these steps:
<orderedlist>
<listitem><para>Open a shell and create a Git repository with:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
</literallayout>
For this example, the repository is named
<filename>~/yocto-eclipse</filename>.</para></listitem>
<listitem><para>Locate the <filename>build.sh</filename> script in the
Git repository you created in the previous step.
The script is located in the <filename>scripts</filename>.</para></listitem>
<listitem><para>Be sure to set and export the <filename>ECLIPSE_HOME</filename> environment
variable to the top-level directory in which you installed the Indigo
version of Eclipse.
For example, if your Eclipse directory is <filename>$HOME/eclipse</filename>,
use the following:
<literallayout class='monospaced'>
$ export ECLIPSE_HOME=$HOME/eclipse
</literallayout></para></listitem>
<listitem><para>Run the <filename>build.sh</filename> script and provide the
name of the Git branch along with the Yocto Project release you are
using.
Here is an example that uses the <filename>master</filename> Git repository
and the <filename>1.1.1</filename> release:
<literallayout class='monospaced'>
$ scripts/build.sh master 1.1.1
</literallayout>
After running the script, the file
<filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
is in the current directory.</para></listitem>
<listitem><para>If necessary, start the Eclipse IDE and be sure you are in the
Workbench.</para></listitem>
<listitem><para>Select "Install New Software" from the "Help" pull-down menu.
</para></listitem>
<listitem><para>Click "Add".</para></listitem>
<listitem><para>Provide anything you want in the "Name" field.</para></listitem>
<listitem><para>Click "Archive" and browse to the ZIP file you built
in step four.
This ZIP file should not be "unzipped", and must be the
<filename>*archive.zip</filename> file created by running the
<filename>build.sh</filename> script.</para></listitem>
<listitem><para>Check the box next to the new entry in the installation window and complete
the installation.</para></listitem>
<listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
</orderedlist>
</para>
<para>
At this point you should be able to configure the Eclipse Yocto Plug-in as described in the
"<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
section.</para>
</section>
<section id='yocto-project-source'>
<title>Importing the Plug-in Project into the Eclipse Environment</title>
<para>
Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories
is useful when you want to try out the latest plug-in from the tip of plug-in's
development tree.
It is important to understand when you import the plug-in you are not installing
it into the Eclipse application.
Rather, you are importing the project and just using it.
To import the plug-in project, follow these steps:
<orderedlist>
<listitem><para>Open a shell and create a Git repository with:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
</literallayout>
For this example, the repository is named
<filename>~/yocto-eclipse</filename>.</para></listitem>
<listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
<listitem><para>Expand the "General" box and select "existing projects into workspace"
and then click "Next".</para></listitem>
<listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
</para></listitem>
<listitem><para>There will be three things there.
Select each one and install one at a time.
Do all three.</para></listitem>
</orderedlist>
</para>
<para>
The left navigation pane in the Eclipse application shows the default projects.
Right-click on one of these projects and run it as an Eclipse application.
This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
</para>
</section>
</section>
<section id='configuring-the-eclipse-yocto-plug-in'>
@ -186,7 +285,7 @@
To start, you need to do the following from within the Eclipse IDE:
<itemizedlist>
<listitem><para>Choose <filename>Windows -&gt; Preferences</filename> to display
the Preferences Dialog</para></listitem>
the <filename>Preferences</filename> Dialog</para></listitem>
<listitem><para>Click <filename>Yocto ADT</filename></para></listitem>
</itemizedlist>
</para>
@ -223,12 +322,12 @@
</para></listitem>
<listitem><para><emphasis>Point to the Toolchain:</emphasis>
If you are using a stand-alone pre-built toolchain, you should be pointing to the
<filename>/opt/poky/$SDKVERSION</filename> directory.
<filename>/opt/poky/1.1.1</filename> directory.
This is the location for toolchains installed by the ADT Installer or by hand.
Sections <link linkend='configuring-and-running-the-adt-installer-script'>
Configuring and Running the ADT Installer Script</link> and
<link linkend='using-an-existing-toolchain-tarball'>
Using a Cross-Toolchain Tarball</link> describe two ways to install
Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring
and Running the ADT Installer Script</link>" and
"<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain
Tarball</link>" describe two ways to install
a stand-alone cross-toolchain in the
<filename>/opt/poky</filename> directory.
<note>It is possible to install a stand-alone cross-toolchain in a directory
@ -237,8 +336,8 @@
<para>If you are using a system-derived toolchain, the path you provide
for the <filename>Toolchain Root Location</filename>
field is the Yocto Project's build directory.
See section <link linkend='using-the-toolchain-from-within-the-build-tree'>
Using BitBake and the Yocto Project Build Tree</link> for
See section "<link linkend='using-the-toolchain-from-within-the-build-tree'>Using
BitBake and the Yocto Project Build Tree</link>" for
information on how to install the toolchain into the Yocto
Project build tree.</para></listitem>
<listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
@ -255,10 +354,8 @@
The pull-down menu should have the supported architectures.
If the architecture you need is not listed in the menu, you
will need to build the image.
See the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'> Building an Image</ulink> section of the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink> for more information.</para></listitem>
See the "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section
of The Yocto Project Quick Start for more information.</para></listitem>
</itemizedlist>
</para>
</section>
@ -350,28 +447,33 @@
<title>Configuring the Cross-Toolchains</title>
<para>
The previous section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>
Configuring the Eclipse Yocto Plug-in</link>", set up the default project
The earlier section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring
the Eclipse Yocto Plug-in</link>", sets up the default project
configurations.
You can change these settings for a given project by following these steps:
You can override these settings for a given project by following these steps:
<orderedlist>
<listitem><para>Select <filename>Window -&gt; Preferences</filename>:
This selection brings up the <filename>Preferences</filename> Dialog.
If the Yocto ADT Preferences are not automatically displayed, you can navigate to
that dialog by selection <filename>Yocto ADT</filename> in the left-hand
panel.</para>
<para>Yocto ADT Settings are inherited from the default project configuration.
The information in this dialog is identical to that chosen earlier
for the Cross Compiler Options and Target Options as described in
<link linkend='configuring-the-eclipse-yocto-plug-in'>
Configuring the Eclipse Yocto Plug-in</link> section.</para></listitem>
<listitem><para>Select <filename>Project -&gt; Change Yocto Project Settings</filename>:
This selection brings up the <filename>Project Yocto Settings</filename> Dialog
and allows you to make changes specific to an individual project.
</para>
<para>By default, the Cross Compiler Options and Target Options for a project
are inherited from settings you provide using the <filename>Preferences</filename>
Dialog as described earlier
in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
Yocto Plug-in</link>" section.
The <filename>Project Yocto Settings</filename>
Dialog allows you to override those default settings
for a given project.</para></listitem>
<listitem><para>Make your configurations for the project and click "OK".</para></listitem>
<listitem><para>Select <filename>Project -&gt; Reconfigure Project</filename>:
This selection reconfigures the project by running
<filename>autogen.sh</filename> in the workspace for your project.
The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
<filename>autoconf</filename>, <filename>autoheader</filename>,
<filename>automake --a</filename>, and
<filename>./configure</filename>.</para></listitem>
<filename>./configure</filename>.
Click on the <filename>Console</filename> tab beneath your source code to
see the results of reconfiguring your project.</para></listitem>
</orderedlist>
</para>
</section>
@ -391,20 +493,20 @@
<para>
To start the QEMU emulator from within Eclipse, follow these steps:
<orderedlist>
<listitem><para>Expose the <filename>Run -&gt; External Tools -&gt; External Tools
Configurations...</filename> menu.
<listitem><para>Expose the <filename>Run -&gt; External Tools</filename> menu.
Your image should appear as a selectable menu item.
</para></listitem>
<listitem><para>Select your image from the menu.
Doing so launches a new window.</para></listitem>
<listitem><para>Enter your host root password in the shell window at the prompt.
<listitem><para>Select your image from the menu to launch the
emulator in a new window.</para></listitem>
<listitem><para>If needed, enter your host root password in the shell window at the prompt.
This sets up a <filename>Tap 0</filename> connection needed for running in user-space
NFS mode.</para></listitem>
<listitem><para>Wait for QEMU to launch.</para></listitem>
<listitem><para>Once QEMU launches you need to determine the IP Address
for the user-space NFS.
You can do that by going to a terminal in the QEMU and entering the
<filename>ifconfig</filename> command.</para></listitem>
<listitem><para>Once QEMU launches, you can begin operating within that
environment.
For example, you could determine the IP Address
for the user-space NFS by using the <filename>ifconfig</filename> command.
</para></listitem>
</orderedlist>
</para>
</section>
@ -413,8 +515,8 @@
<title>Deploying and Debugging the Application</title>
<para>
Once the QEMU emulator is running the image, you can deploy your application and use the emulator
to perform debugging.
Once the QEMU emulator is running the image, using the Eclipse IDE
you can deploy your application and use the emulator to perform debugging.
Follow these steps to deploy the application.
<orderedlist>
<listitem><para>Select <filename>Run -&gt; Debug Configurations...</filename></para></listitem>
@ -435,8 +537,8 @@
<listitem><para>Click <filename>Next</filename>.</para></listitem>
<listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address
determined earlier.</para></listitem>
<listitem><para>Click <filename>Finish</filename> to close the new connections
Dialog.</para></listitem>
<listitem><para>Click <filename>Finish</filename> to close the
<filename>New Connections</filename> Dialog.</para></listitem>
<listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick
the IP Address you entered.</para></listitem>
<listitem><para>Click <filename>Debug</filename> to bring up a login screen
@ -454,7 +556,7 @@
your development experience.
These tools are aids in developing and debugging applications and images.
You can run these user-space tools from within the Eclipse IDE through the
<filename>Window -&gt; YoctoTools</filename> menu.
<filename>YoctoTools</filename> menu.
</para>
<para>

View File

@ -114,7 +114,7 @@
<listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
to keep track of certain types of hardware and software events.
For more information on these types of counters see
<ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click
<ulink url='https://perf.wiki.kernel.org/'></ulink> and click
on “Perf tools.”</para></listitem>
<listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
that simplifies information gathering about a running Linux system.

View File

@ -31,17 +31,27 @@
<revision>
<revnumber>1.0</revnumber>
<date>6 April 2011</date>
<revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.0.1</revnumber>
<date>23 May 2011</date>
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>6 October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1.1</revnumber>
<date>15 March 2012</date>
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>2010-2011</year>
<year>2010-2012</year>
<holder>Linux Foundation</holder>
</copyright>
@ -53,7 +63,7 @@
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and the
<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
Application Developer's Toolkit (ADT) User's Guide</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.

View File

@ -54,9 +54,7 @@
<note>
For build performance information related to the PMS, see
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>
in <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
</note>
<para>

View File

@ -9,60 +9,9 @@
In order to use the ADT, you must install it, <filename>source</filename> a script to set up the
environment, and be sure both the kernel and filesystem image specific to the target architecture
exist.
This chapter describes how to be sure you meet the ADT requirements.
</para>
<para>
This chapter describes two important terms and how to be sure you meet the ADT requirements.
</para>
<section id='yocto-project-files'>
<title>Yocto Project Files and Build Areas</title>
<para>
Before learning how to prepare your system for the ADT, you need to understand
two important terms used throughout this manual:
<itemizedlist>
<listitem><para><emphasis>The Yocto Project Files:</emphasis>
This term refers to the directory structure created as a result of downloading
and unpacking a Yocto Project release tarball or setting up a Git repository
by cloning <filename>git://git.yoctoproject.org/poky</filename>.</para>
<para>The Yocto Project files contain BitBake, Documentation, metadata and
other files that all support the development environment.
Consequently, you must have the Yocto Project files in place on your development
system in order to do any development using the Yocto Project.</para>
<para>The name of the top-level directory of the Yocto Project file structure
is derived from the Yocto Project release tarball.
For example, downloading and unpacking <filename>poky-edison-6.0.tar.bz2</filename>
results in a Yocto Project source tree whose Yocto Project source directory is named
<filename>poky-edison-6.0</filename>.
If you create a Git repository, then you can name the repository anything you like.</para>
<para>You can find instruction on how to set up the Yocto Project files on your
host development system by reading the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
Getting Setup</ulink> section in
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.</para></listitem>
<listitem><para><emphasis>Yocto Project Build Tree:</emphasis>
This term refers to the area where the Yocto Project builds images.
The area is created when you <filename>source</filename> the Yocto Project setup
environment script that is found in the Yocto Project files area.
(e.g. <filename>oe-init-build-env</filename>).
You can create the Yocto Project build tree anywhere you want on your
development system.
Here is an example that creates the tree in <filename>mybuilds</filename>
and names the Yocto Project build directory <filename>YP-6.0</filename>:
<literallayout class='monospaced'>
$ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
</literallayout>
If you don't specifically name the build directory, then BitBake creates it
in the current directory and uses the name <filename>build</filename>.
Also, if you supply an existing directory, then BitBake uses that
directory as the Yocto Project build directory and populates the build tree
beneath it.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='installing-the-adt'>
<title>Installing the ADT</title>
@ -70,7 +19,8 @@
The following list describes how you can install the ADT, which includes the cross-toolchain.
Regardless of the installation you choose, you must <filename>source</filename> the cross-toolchain
environment setup script before you use the toolchain.
See the "<link linkend='setting-up-the-environment'>Setting Up the Environment</link>"
See the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the
Cross-Development Environment</link>"
section for more information.
<itemizedlist>
<listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
@ -85,8 +35,8 @@
If you use this method, you just get the cross-toolchain and QEMU - you do not
get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
<listitem><para><emphasis>Use the Toolchain from within a Yocto Project Build Tree:</emphasis>
If you already have a Yocto Project build tree, you can install the cross-toolchain
using that tree.
If you already have a Yocto Project build tree, you can build the cross-toolchain
within tree.
However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you
do not get any of the other benefits without taking separate steps.</para></listitem>
</itemizedlist>
@ -105,15 +55,18 @@
<para>
The ADT Installer is contained in the ADT Installer tarball.
You can download the tarball into any directory from
<ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/adt-installer/'></ulink>.
You can download the tarball into any directory from the
<ulink url='http://downloads.yoctoproject.org/releases'>Index of Releases</ulink>, specifically
at
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/adt_installer'></ulink>.
Or, you can use BitBake to generate the tarball inside the existing Yocto Project
build tree.
</para>
<para>
If you use BitBake to generate the ADT Installer tarball, you must
<filename>source</filename> the Yocto Project environment setup script located
<filename>source</filename> the Yocto Project environment setup script
(<filename>oe-init-build-env</filename>) located
in the Yocto Project file structure before running the <filename>bitbake</filename>
command that creates the tarball.
</para>
@ -128,9 +81,9 @@
$ cd ~
$ mkdir yocto-project
$ cd yocto-project
$ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
$ tar xjf poky-edison-6.0.tar.bz2
$ source poky-edison-6.0/oe-init-build-env
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
$ tar xjf poky-edison-6.0.1.tar.bz2
$ source poky-edison-6.0.1/oe-init-build-env
$ bitbake adt-installer
</literallayout>
</para>
@ -142,6 +95,14 @@
<para>
Before running the ADT Installer script, you need to unpack the tarball.
You can unpack the tarball in any directory you wish.
For example, this command copies the ADT Installer tarball from where
it was built into the home directory and then unpacks the tarball into
a top-level directory named <filename>adt-installer</filename>:
<literallayout class='monospaced'>
$ cd ~
$ cp ~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
$ tar -xjf adt_installer.tar.bz2
</literallayout>
Unpacking it creates the directory <filename>adt-installer</filename>,
which contains the ADT Installer script (<filename>adt_installer</filename>)
and its configuration file (<filename>adt_installer.conf</filename>).
@ -204,18 +165,19 @@
<para>
After you have configured the <filename>adt_installer.conf</filename> file,
run the installer using the following command:
run the installer for this example using the following commands:
<literallayout class='monospaced'>
$ adt_installer
$ cd ~/adt-installer
$ ./adt_installer
</literallayout>
</para>
<note>
The ADT Installer requires the <filename>libtool</filename> package to complete.
If you install the recommended packages as described in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
Packages</ulink> section of
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
section of
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>, then you will have libtool installed.
</note>
@ -230,7 +192,7 @@
<para>
Once the installation completes, the ADT, which includes the cross-toolchain, is installed.
You will notice environment setup files for the cross-toolchain in
<filename>/opt/poky/$SDKVERSION</filename>,
<filename>/opt/poky/1.1.1</filename>,
and image tarballs in the <filename>adt-installer</filename>
directory according to your installer configurations, and the target sysroot located
according to the <filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> variable
@ -245,64 +207,76 @@
<para>
If you want to simply install the cross-toolchain by hand, you can do so by using an existing
cross-toolchain tarball.
If you install the cross-toolchain by hand, you will have to set up the target sysroot separately.
If you use this method to install the cross-toolchain and you still need to install the target
sysroot, you will have to install sysroot separately.
</para>
<para>
Follow these steps:
<orderedlist>
<listitem><para>Go to
<ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/toolchain'></ulink>
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain'></ulink>
and find the folder that matches your host development system
(i.e. <filename>i686</filename> for 32-bit machines or
<filename>x86_64</filename> for 64-bit machines).</para></listitem>
<listitem><para>Go into that folder and download the toolchain tarball whose name
includes the appropriate target architecture.
For example, if your host development system is an Intel-based 64-bit system and
you are going to use your cross-toolchain for an ARM-based target, go into the
you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the
<filename>x86_64</filename> folder and download the following tarball:
<literallayout class='monospaced'>
yocto-eglibc-x86_64-arm-toolchain-gmae-1.1.tar.bz2
</literallayout>
<note>As an alternative to steps one and two, you can build the toolchain tarball
poky-eglibc-x86_64-i586-toolchain-1.1.1.tar.bz2
</literallayout>
<note><para>As an alternative to steps one and two, you can build the toolchain tarball
if you have a Yocto Project build tree.
Use the <filename>bitbake meta-toolchain</filename> command after you have
sourced the <filename>oe-build-init script</filename> located in the Yocto
If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
command.
The resulting tarball will support such development.
However, if you are not concerned with GMAE,
you can generate the tarball using <filename>bitbake meta-toolchain</filename>.</para>
<para>Use the appropriate <filename>bitbake</filename> command only after you have
sourced the <filename>oe-build-init-env</filename> script located in the Yocto
Project files.
When the <filename>bitbake</filename> command completes, the toolchain tarball will
When the <filename>bitbake</filename> command completes, the tarball will
be in <filename>tmp/deploy/sdk</filename> in the Yocto Project build tree.
</note></para></listitem>
</para></note></para></listitem>
<listitem><para>Make sure you are in the root directory with root privileges and then expand
the tarball.
The tarball expands into <filename>/opt/poky/$SDKVERSION</filename>.
Once the tarball in unpacked, the cross-toolchain is installed.
The tarball expands into <filename>/opt/poky/1.1.1</filename>.
Once the tarball is expanded, the cross-toolchain is installed.
You will notice environment setup files for the cross-toolchain in the directory.
Here is an example where the tarball exists in the user's <filename>Downloads</filename>
directory:
<literallayout class='monospaced'>
# cd /
# tar -xjf /home/scottrif/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
</literallayout>
</para></listitem>
</orderedlist>
</para>
<para>
After installing the toolchain, you must locate the target sysroot tarball and unpack it
into a location of your choice.
</para>
</section>
<section id='using-the-toolchain-from-within-the-build-tree'>
<title>Using BitBake and the Yocto Project Build Tree</title>
<para>
A final way of installing just the cross-toolchain is to use BitBake within an existing
Yocto Project build tree.
Follow these steps:
A final way of installing just the cross-toolchain is to use BitBake to build the
toolchain within an existing Yocto Project build tree.
This method does not install the toolchain into the <filename>/opt</filename> directory.
As with the previous method, if you need to install the target sysroot, you must
do this separately.
</para>
<para>
Follow these steps to build and install the toolchain into the build tree:
<orderedlist>
<listitem><para>Source the environment setup script located in the Yocto Project
files.
The script has the string <filename>init-build-env</filename>
as part of the name.</para></listitem>
<listitem><para>Source the environment setup script
<filename>oe-init-build-env</filename> located in the Yocto Project
files.</para></listitem>
<listitem><para>At this point, you should be sure that the
<filename>MACHINE</filename> variable
in the <filename>local.conf</filename> file found in the Yocto Project
file structure's <filename>conf</filename> directory
in the <filename>local.conf</filename> file found in the
<filename>conf</filename> directory of the Yocto Project build directory
is set for the target architecture.
Comments within the <filename>local.conf</filename> file list the values you
can use for the <filename>MACHINE</filename> variable.
@ -313,83 +287,168 @@
command.</note></para></listitem>
<listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the
cross-toolchain installation.
<note>If you change your working directory after you
<note>If you change out of your working directory after you
<filename>source</filename> the environment setup script and before you run
the BitBake command, the command will not work.
the <filename>bitbake</filename> command, the command might not work.
Be sure to run the <filename>bitbake</filename> command immediately
after checking or editing the <filename>local.conf</filename> but without
changing your working directory.</note>
Once BitBake finishes, the cross-toolchain is installed.
changing out of your working directory.</note>
Once the <filename>bitbake</filename> command finishes,
the tarball for the cross-toolchain is generated within the Yocto Project build tree.
You will notice environment setup files for the cross-toolchain in the
Yocto Project build tree in the <filename>tmp</filename> directory.
Setup script filenames contain the strings <filename>environment-setup</filename>.
</para></listitem>
</orderedlist>
</para>
<para>
After installing the toolchain, you must locate the target sysroot tarball and unpack
it in a directory of your choice.
</para>
</section>
</section>
<section id='setting-up-the-environment'>
<title>Setting Up the Environment</title>
<section id='setting-up-the-cross-development-environment'>
<title>Setting Up the Cross-Development Environment</title>
<para>
Before you can use the cross-toolchain, you need to set up the toolchain environment by
sourcing the environment setup script.
Before you can develop using the cross-toolchain, you need to set up the
cross-development environment by sourcing the toolchain's environment setup script.
If you used the ADT Installer or used an existing ADT tarball to install the ADT,
then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename>
then you can find this script in the <filename>/opt/poky/1.1.1</filename>
directory.
If you used BitBake and the Yocto Project Build Tree to install the cross-toolchain,
then you can find the environment setup scripts in in the Yocto Project build tree
in the <filename>tmp</filename> directory.
If you installed the toolchain in the build tree, you can find the environment setup
script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
</para>
<para>
Be sure to run the environment setup script that matches the architecture for
Be sure to source the environment setup script that matches the architecture for
which you are developing.
Environment setup scripts begin with the string “<filename>environment-setup</filename>
and include as part of their name the architecture.
For example, the environment setup script for a 64-bit IA-based architecture would
be the following:
For example, the command to source the toolchain environment setup script
for a 64-bit IA-based machine would be the following:
<literallayout class='monospaced'>
/opt/poky/1.1/environment-setup-x86_64-poky-linux
$ source /opt/poky/1.1.1/environment-setup-x86_64-poky-linux
</literallayout>
</para>
</section>
<section id='kernels-and-filesystem-images'>
<title>Kernels and Filesystem Images</title>
<section id='securing-kernel-and-filesystem-images'>
<title>Securing Kernel and Filesystem Images</title>
<para>
You will need to have a kernel and filesystem image to boot using your
hardware or the QEMU emulator.
That means you either have to build them or know where to get them.
You can find a quick example of how to build an image in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
Building an Image</ulink> section of
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>.
<note><para>
The Yocto Project provides basic kernels and filesystem images for several
hardware or the QEMU emulator.
Furthermore, if you plan on booting your image using NFS or you want to use the root filesystem
as the target sysroot, you need to extract the root filesystem.
</para>
<section id='getting-the-images'>
<title>Getting the Images</title>
<para>
To get the kernel and filesystem images, you either have to build them or download
pre-built versions.
You can find examples for both these situations in the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#test-run'>A
Quick Test Run</ulink>" section of The Yocto Project Quick Start.
</para>
<para>
The Yocto Project provides basic kernel and filesystem images for several
architectures (<filename>x86</filename>, <filename>x86-64</filename>,
<filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>)
that you can use unaltered in the QEMU emulator.
These kernels and filesystem images reside in the Yocto Project release
area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/machines/'></ulink>
and are ideal for experimentation within Yocto Project.</para>
<para>If you plan on remotely deploying and debugging your application from within the
Eclipse IDE, you must have an image that supports Sato.
For information on the image types you can build using the Yocto Project, see
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
Reference: Images</ulink> in
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.</para>
</note>
</para>
These kernel images reside in the Yocto Project release
area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'></ulink>
and are ideal for experimentation within Yocto Project.
For information on the image types you can build using the Yocto Project, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in The Yocto Project Reference Manual.
</para>
<para>
If you plan on remotely deploying and debugging your application from within the
Eclipse IDE, you must have an image that contains the Yocto Target Communication
Framework (TCF) agent (<filename>tcf-agent</filename>).
By default, the Yocto Project provides only one type pre-built image that contains the
<filename>tcf-agent</filename>.
And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
</para>
<para>
If you want to use a different image type that contains the <filename>tcf-agent</filename>,
you can do so one of two ways:
<itemizedlist>
<listitem><para>Modify the <filename>conf/local.conf</filename> configuration file in
the Yocto Project build directory and then rebuild the image.
With this method, you need to modify the <filename>EXTRA_IMAGE_FEATURES</filename>
variable to have the value of "tools-debug" before rebuilding the image.
Once the image is rebuilt, the <filename>tcf-agent</filename> will be included
in the image and is launched automatically after the boot.</para></listitem>
<listitem><para>Manually build the <filename>tcf-agent</filename>.
To build the agent, follow these steps:
<orderedlist>
<listitem><para>Be sure the ADT is installed as described in the
"<link linkend='installing-the-adt'>Installing the ADT</link>" section.
</para></listitem>
<listitem><para>Set up the cross-development environment as described in the
"<link linkend='setting-up-the-cross-development-environment'>Setting
Up the Cross-Development Environment</link>" section.</para></listitem>
<listitem><para>Get the <filename>tcf-agent</filename> source code, which is
stored using the Subversion SCM, using the following command:
<literallayout class='monospaced'>
$ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \
&lt;-r #rev_number&gt;
</literallayout></para></listitem>
<listitem><para>Modify the <filename>Makefile.inc</filename> file
for the cross-compilation environment by setting the
<filename>OPSYS</filename> and <filename>MACHINE</filename>
variables according to your target.</para></listitem>
<listitem><para>Use the cross-development tools to build the
<filename>tcf-agent</filename>.
Before you "Make" the file, be sure your cross-tools are set up first.
See the "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
section for information on how to make sure the cross-tools are set up
correctly.</para>
<para>If the build is successful, the <filename>tcf-agent</filename> output will
be <filename>obj/$(OPSYS)/$(MACHINE)/Debug/agent</filename>.</para></listitem>
<listitem><para>Deploy the agent into the image's root filesystem.</para></listitem>
</orderedlist>
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='extracting-the-root-filesystem'>
<title>Extracting the Root Filesystem</title>
<para>
You must extract the root filesystem if you want to boot the image using NFS
or you want to use the root filesystem as the target sysroot.
For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you
to use QEMU to boot under NFS.
Another example is if you want to develop your target application using the
root filesystem as the target sysroot.
</para>
<para>
To extract the root filesystem, first <filename>source</filename>
the cross-development environment setup script and then
use the <filename>runqemu-extract-sdk</filename> command on the
filesystem image tarball.
For example, the following commands set up the environment by sourcing
the setup script from within the build directory and then extracting
the root filesystem from a previously built filesystem image tarball named
<filename>core-image-sato-sdk-qemux86.tar.bz2</filename>.
The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
directory:
<literallayout class='monospaced'>
$ source $HOME/poky/build/tmp/environment-setup-i586-poky-linux
$ runqemu-extract-sdk \
tmp/deploy/images/core-image-sato-sdk-qemux86.tar.bz2 \
$HOME/qemux86-sato
</literallayout>
In this case, you could now point to the target sysroot at
<filename>$HOME/qemux86-sato</filename>.
</para>
</section>
</section>
</chapter>

View File

@ -19,10 +19,17 @@
<authorgroup>
<author>
<firstname>Richard</firstname> <surname>Purdie</surname>
<firstname>Tom</firstname> <surname>Zanussi</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
</affiliation>
<email>tom.zanussi@intel.com</email>
</author>
<author>
<firstname>Richard</firstname> <surname>Purdie</surname>
<affiliation>
<orgname>Linux Foundation</orgname>
</affiliation>
<email>richard.purdie@linuxfoundation.org</email>
</author>
</authorgroup>
@ -30,24 +37,33 @@
<revhistory>
<revision>
<revnumber>0.9</revnumber>
<date>27 October 2010</date>
<revremark>This manual revision is the initial manual and corresponds to the
Yocto Project 0.9 Release.</revremark>
<date>24 November 2010</date>
<revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>6 April 2011</date>
<revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.0.1</revnumber>
<date>23 May 2011</date>
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>6 October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1.1</revnumber>
<date>15 March 2012</date>
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>2010-2011</year>
<year>2010-2012</year>
<holder>Linux Foundation</holder>
</copyright>
@ -59,7 +75,7 @@
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and the
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
Board Support Package (BSP) Developer's Guide</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.

View File

@ -30,9 +30,9 @@
<note>
The information here does not provide an example of how to create a BSP.
For examples on how to create a BSP, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
BSP Development Example</ulink> in
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
You can also see the
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
@ -100,10 +100,9 @@
"
</literallayout>
For more detailed information on layers, see the
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>
BitBake Layers</ulink> section of the Yocto Project Reference Manual.
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>BitBake Layers</ulink>" section of the Yocto Project Reference Manual.
You can also see the detailed examples in the appendices of
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
@ -145,12 +144,12 @@
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
meta-crownbay/recipes-core
meta-crownbay/recipes-core/tasks
meta-crownbay/recipes-core/tasks/task-core-tools.bbappend
meta-crownbay/recipes-graphics/
meta-crownbay/recipes-graphics/xorg-xserver/
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin-1.6/.gitignore
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
@ -371,6 +370,24 @@
</para></note>
</section>
<section id='bsp-filelayout-core-recipes'>
<title>Core Recipe Files</title>
<para>
You can find these files in the Yocto Project file's directory structure at:
<literallayout class='monospaced'>
meta-&lt;bsp_name&gt;/recipes-core/*
</literallayout>
</para>
<para>
This directory contains recipe files for the core.
For example, in the Crown Bay BSP there is the
<filename>task-core-tools.bbappend</filename> file, which is an append file used
to recommend that the SystemTap package be included as a package when the image
is built.
</para>
</section>
<section id='bsp-filelayout-recipes-graphics'>
<title>Display Support Files</title>
<para>
@ -387,7 +404,6 @@
For example, the Crown Bay BSP contains the following files that support
building a BSP that supports and does not support the Intel EMGD:
<literallayout class='monospaced'>
meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
@ -445,11 +461,11 @@
KMACHINE_crownbay-noemgd = "yocto/standard/crownbay"
KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
</literallayout>
This append file contains statements used to support the Crown Bay BSP for both
Intel EMGD and non-EMGD.
@ -464,8 +480,8 @@
KMACHINE_crownbay = "yocto/standard/crownbay"
KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
SRCREV_machine_pn-linux-yocto_crownbay ?= "6b4b9acde5fb0ff66ae58fa98274bfe631501499"
SRCREV_meta_pn-linux-yocto_crownbay ?= "5b535279e61197cb194bb2dfceb8b7a04128387c"
SRCREV_machine_pn-linux-yocto_crownbay ?= "2247da9131ea7e46ed4766a69bb1353dba22f873"
SRCREV_meta_pn-linux-yocto_crownbay ?= "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
</literallayout>
The append file defines <filename>crownbay</filename> as the compatible machine,
defines the <filename>KMACHINE</filename>, points to some configuration fragments
@ -522,7 +538,7 @@
The configuration options will likely end up in that location anyway if the BSP gets
added to the Yocto Project.
For information on how to add these configurations directly, see
<ulink url='http://yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
<ulink url='http://yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink>.</para>
<para>
In general, however, the Yocto Project maintainers take care of moving the

View File

@ -10,8 +10,11 @@
The example assumes the following:
<itemizedlist>
<listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a base BSP from
which to work from.</para></listitem>
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from
which to work.
The example begins with the Crown Bay BSP as the starting point
but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
</para></listitem>
<listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
<listitem><para>Example was developed on an Intel-based Core i7 platform running
Ubuntu 10.04 LTS released in April of 2010.</para></listitem>
@ -24,11 +27,30 @@
<para>
You need to have the Yocto Project files available on your host system.
You can get files through tarball extraction or by cloning the <filename>poky</filename>
Git repository.
See the bulleted item
<link linkend='local-yp-release'>Yocto Project Release</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
for information on how to get these files.
Git repository.
The following paragraphs describe both methods.
For additional information, see the bulleted item
"<link linkend='local-yp-release'>Yocto Project Release</link>".
</para>
<para>
As mentioned, one way to get the Yocto Project files is to use Git to clone the
<filename>poky</filename> repository:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/poky
$ cd poky
</literallayout>
Alternatively, you can start with the downloaded Poky "edison" tarball:
<literallayout class='monospaced'>
$ tar xfj poky-edison-6.0.1.tar.bz2
$ cd poky
</literallayout>
<note>If you're using the tarball method, you can ignore all the following steps that
ask you to carry out Git operations.
You already have the results of those operations
in the form of the edison release tarballs.
Consequently, there is nothing left to do other than extract those tarballs into the
proper locations.</note>
</para>
<para>
@ -40,14 +62,13 @@
$ git branch -a
$ git tag -l
</literallayout>
For this example we are going to use the Yocto Project 1.1 Release,
which maps to the <filename>1.1</filename> branch in the repository.
These commands create a local branch named <filename>1.1</filename>
For this example we are going to use the Yocto Project 1.1.1 Release, which is code
named "edison".
These commands create a local branch named <filename>edison</filename>
that tracks the remote branch of the same name.
<literallayout class='monospaced'>
$ cd poky
$ git checkout -b 1.1 origin/1.1
Switched to a new branch '1.1'
$ git checkout -b edison origin/edison
Switched to a new branch 'edison'
</literallayout>
</para>
</section>
@ -56,15 +77,20 @@
<title>Choosing a Base BSP</title>
<para>
For this example, the base BSP is the Intel Atom Processor E660 with Intel Platform
For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
<trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform
Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
The BSP layer is <filename>meta-crownbay</filename>.
The BSP layer is <filename>meta-crownbay</filename>.
The base BSP is simply the BSP
we will be using as a starting point, so don't worry if you don't actually have Crown Bay
hardware.
The remainder of the example transforms the base BSP into a BSP that should be
able to boot on generic atom-pc (netbook) hardware.
</para>
<para>
For information on how to choose a base BSP, see
<xref linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</xref>
earlier in this manual.
"<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
</para>
</section>
@ -73,30 +99,55 @@
<para>
You need to have the base BSP layer on your development system.
Like the local Yocto Project files, you can get the BSP
layer one of two ways:
Similar to the local Yocto Project files, you can get the BSP
layer a couple of different ways:
download the BSP tarball and extract it, or set up a local Git repository that
has the Yocto Project BSP layers.
You should use the same method that you used to get the local Yocto Project files earlier.
See <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
for information on how to get the BSP files.
</para>
<para>
This example assumes a local <filename>meta-intel</filename> Git repository
inside the local <filename>poky</filename> Git repository.
The <filename>meta-intel</filename> Git repository contains all the metadata
that supports BSP creation.
See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
the BSP files.
</para>
<para>
This example assumes the BSP layer will be located within a directory named
<filename>meta-intel</filename> contained within the <filename>poky</filename>
parent directory.
The following steps will automatically create the
<filename>meta-intel</filename> directory and the contained meta-crownbay
starting point in both the Git and the tarball cases.
</para>
<para>
If you're using the Git method, you could do the following to create
the starting layout after you have made sure you are in the <filename>poky</filename>
directory created in the previous steps:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/meta-intel.git
$ cd meta-intel
</literallayout>
Alternatively, you can start with the downloaded <filename>meta-intel</filename>
edison tarball.
Again, be sure that you are already in the <filename>poky</filename> directory
as described previously:
<literallayout class='monospaced'>
$ tar xfj crownbay-noemgd-edison-6.0.1.tar.bz2
$ cd meta-intel
</literallayout>
</para>
<para>
The <filename>meta-intel</filename> directory contains all the metadata
that supports BSP creation.
If you're using the Git method, the following
step will switch to the edison metadata.
If you're using the tarball method, you already have the correct metadata and can
skip to the next step.
Because <filename>meta-intel</filename> is its own Git repository, you will want
to be sure you are in the appropriate branch for your work.
For this example we are going to use the <filename>1.1</filename> branch.
For this example we are going to use the <filename>edison</filename> branch.
<literallayout class='monospaced'>
$ cd meta-intel
$ git checkout -b 1.1 origin/1.1
Switched to a new branch 'bernard'
$ git checkout -b edison origin/edison
Switched to a new branch 'edison'
</literallayout>
</para>
</section>
@ -105,23 +156,20 @@
<title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
<para>
Now that you have the local Yocto Project files and the base BSP files you need to create a
Now that you have the local Yocto Project files and the base BSP files, you need to create a
new layer for your BSP.
To create your BSP layer you simply copy the <filename>meta-crownbay</filename>
To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
layer to a new layer.
</para>
<para>
For this example the new layer will be named <filename>meta-mymachine</filename>.
The name must follow the BSP layer naming convention, which is
For this example, the new layer will be named <filename>meta-mymachine</filename>.
The name should follow the BSP layer naming convention, which is
<filename>meta-&lt;name&gt;</filename>.
The following example assumes your working directory is <filename>meta-intel</filename>
The following assumes your working directory is <filename>meta-intel</filename>
inside the local Yocto Project files.
If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting
<filename>meta-crownbay</filename> directory structure to a location of your choice.
Good practice for a Git repository, however, is to just copy the new layer alongside
the existing
BSP layers in the <filename>meta-intel</filename> Git repository:
To start your new layer, just copy the new layer alongside the existing
BSP layers in the <filename>meta-intel</filename> directory:
<literallayout class='monospaced'>
$ cp -a meta-crownbay/ meta-mymachine
</literallayout>
@ -148,7 +196,7 @@
</para>
<para>
First, since in this example the new BSP will not support EMGD we will get rid of the
First, since in this example the new BSP will not support EMGD, we will get rid of the
<filename>crownbay.conf</filename> file and then rename the
<filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
Much of what we do in the configuration directory is designed to help the Yocto Project
@ -163,25 +211,32 @@
</para>
<para>
The next step makes changes to <filename>mymachine.conf</filename> itself.
The only changes needed for this example are changes to the comment lines.
Here we simply substitute the Crown Bay name with an appropriate name.
Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
The only changes we want to make for this example are to the comment lines.
Changing comments, of course, is never strictly necessary, but it's alway good form to make
them reflect reality as much as possible.
Here, simply substitute the Crown Bay name with an appropriate name for the BSP
(<filename>mymachine</filename> in this case) and change the description to
something that describes your hardware.
</para>
<para>
Note that inside the <filename>mymachine.conf</filename> is the
<filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement.
This statement identifies the kernel that the BSP is going to use.
In this case the BSP is using <filename>linux-yocto</filename>, which is the
In this case, the BSP is using <filename>linux-yocto</filename>, which is the
current Linux Yocto kernel based on the Linux 3.0 release.
</para>
<para>
The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
The next configuration file in the new BSP layer we need to edit is
<filename>meta-mymachine/conf/layer.conf</filename>.
This file identifies build information needed for the new layer.
You can see the
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>
Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>The Board
Support Packages (BSP) Development Guide</ulink>
for more information on this configuration file.
Basically, we are changing the existing statements to work with our BSP.
</para>
@ -212,10 +267,10 @@
<para>
Now we will take a look at the recipes in your new layer.
The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.
When you create a BSP you use these areas for appropriate recipes and append files.
When you create a BSP, you use these areas for appropriate recipes and append files.
Recipes take the form of <filename>.bb</filename> files.
If you want to leverage the existing recipes the Yocto Project build system uses
but change those recipes you can use <filename>.bbappend</filename> files.
but change those recipes, you can use <filename>.bbappend</filename> files.
All new recipes and append files for your layer must go in the layers
<filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>,
<filename>recipes-core</filename>, and
@ -232,7 +287,7 @@
the remaining one that doesn't support EMGD.
These commands take care of the <filename>recipes-bsp</filename> recipes:
<literallayout class='monospaced'>
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/*emgd*
$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
</literallayout>
@ -248,7 +303,6 @@
be sure to rename remaining directories appropriately.
The following commands clean up the <filename>recipes-graphics</filename> directory:
<literallayout class='monospaced'>
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-emgd*
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine
@ -304,13 +358,17 @@
The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
statements point to the exact commits used by the Yocto Project development team
in their source repositories that identify the right kernel for our hardware.
In other words, the <filename>SRCREV</filename> values are simply Git commit
IDs that identify which commit on each
of the kernel branches (machine and meta) will be checked out and used to build
the kernel.
</para>
<para>
However, in the <filename>meta-mymachine</filename> layer in
<filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
file named <filename>linux-yocto_3.0.bbappend</filename> that
is appended to the recipe of the same name in <filename>meta/recipes-kernel/link</filename>.
is appended to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
Thus, the <filename>SRCREV</filename> statements in the "append" file override
the more general statements found in <filename>meta</filename>.
</para>
@ -321,14 +379,14 @@
Here are the statements:
<literallayout class='monospaced'>
SRCREV_machine_pn-linux-yocto_crownbay ?= \
"372c0ab135978bd8ca3a77c88816a25c5ed8f303"
"2247da9131ea7e46ed4766a69bb1353dba22f873"
SRCREV_meta_pn-linux-yocto_crownbay ?= \
"d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
"372c0ab135978bd8ca3a77c88816a25c5ed8f303"
"2247da9131ea7e46ed4766a69bb1353dba22f873"
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
"d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
</literallayout>
</para>
@ -343,30 +401,54 @@
</para>
<para>
To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>
To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
we delete the two <filename>SRCREV</filename> statements that support
EMGD (the top pair).
EMGD (the top pair).
We also change the remaining pair to specify <filename>mymachine</filename>
and insert the commit identifiers to identify the kernel in which we
are interested, which will be based on the <filename>atom-pc-standard</filename>
kernel.
In this case, because we're working with the edison branch of everything, we
need to use the <filename>SRCREV</filename> values for the atom-pc branch
that are associated with the edison release.
To find those values, we need to find the <filename>SRCREV</filename>
values that edison uses for the atom-pc branch, which we find in the
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
file.
</para>
<para>
The machine <filename>SRCREV</filename> we want is in the
<filename>SRCREV_machine_atom-pc</filename> variable.
The meta <filename>SRCREV</filename> isn't specified in this file, so it must be
specified in the base kernel recipe in the
<filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
file, in the <filename>SRCREV_meta variable</filename> found there.
It happens to be the same as the value we already inherited from the
<filename>meta-crownbay</filename> BSP.
Here are the final <filename>SRCREV</filename> statements:
<literallayout class='monospaced'>
SRCREV_machine_pn-linux-yocto_mymachine ?= \
"fce17f046d3756045e4dfb49221d1cf60fcae329"
"1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= \
"84f1a422d7e21fbc23a687035bdf9d42471f19e0"
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
</literallayout>
</para>
<para>
If you are familiar with Git repositories you probably wont have trouble locating the
In this example, we're using the <filename>SRCREV</filename> values we
found already captured in the edison release because we're creating a BSP based on
edison.
If, instead, we had based our BSP on the master branches, we would want to use
the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
We will not be doing that for this example.
However, if you do base a future BSP on master and
if you are familiar with Git repositories, you probably wont have trouble locating the
exact commit strings in the Yocto Project source repositories you need to change
the <filename>SRCREV</filename> statements.
You can find all the <filename>machine</filename> and <filename>meta</filename>
branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37'>here</ulink>
[WRITER's NOTE: Need new link to the 3.0 source repo area when it is available].
branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.
</para>
<para>
@ -395,19 +477,25 @@
Because we are not interested in supporting EMGD those three can be deleted.
The remaining three must be changed so that <filename>mymachine</filename> replaces
<filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
Because we are using the atom-pc branch for this new BSP, we can also find
the exact branch we need for the KMACHINE variable in our new BSP from the value
we find in the
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
file we looked at in a previous step.
In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all
the edits:
<literallayout class='monospaced'>
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
COMPATIBLE_MACHINE_mymachine = "mymachine"
KMACHINE_mymachine = "yocto/standard/mymachine"
KMACHINE_mymachine = "yocto/standard/common-pc/atom-pc"
KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
SRCREV_machine_pn-linux-yocto_mymachine ?= \
"fce17f046d3756045e4dfb49221d1cf60fcae329"
"1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
SRCREV_meta_pn-linux-yocto_mymachine ?= \
"84f1a422d7e21fbc23a687035bdf9d42471f19e0"
"d05450e4aef02c1b7137398ab3a9f8f96da74f52"
</literallayout>
</para>
</section>
@ -486,14 +574,14 @@
<para>
The appendix
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
on configuration variables.
</para>
</section>
<section id='building-the-image-app'>
<title>Building the Image</title>
<title>Building and Booting the Image</title>
<para>
To build the image for our <filename>meta-mymachine</filename> BSP enter the following command
@ -502,7 +590,7 @@
For example, moving your working directory around could cause problems.
Here is the command for this example:
<literallayout class='monospaced'>
$ bitbake k core-image-sato-live
$ bitbake -k core-image-sato
</literallayout>
</para>
@ -514,6 +602,65 @@
If the build results in any type of error you should check for misspellings in the
files you changed or problems with your host development environment such as missing packages.
</para>
<para>
Finally, once you have an image, you can try booting it from a device
(e.g. a USB device).
To prepare a bootable USB device, insert a USB flash drive into your build system and
copy the <filename>.hddimage</filename>, located in the
<filename>poky/build/tmp/deploy/images</filename>
directory after a successful build to the flash drive.
Assuming the USB flash drive takes device <filename>/dev/sdc</filename>,
use <filename>dd</filename> to copy the live image to it.
For example:
<literallayout class='monospaced'>
# dd if=core-image-sato-mymachine-20120111232235.hddimg of=/dev/sdc
# sync
# eject /dev/sdc
</literallayout>
You should now have a bootable USB flash device.
</para>
<para>
Insert the device
into a bootable USB socket on the target, and power it on.
The system should boot to the Sato graphical desktop.
</para>
<para>
For reference, the sato image produced by the previous steps for edison
should look like the following in terms of size.
If your sato image is much different from this,
you probably made a mistake in one of the above steps:
<literallayout class='monospaced'>
358709248 2012-01-11 20:43 core-image-sato-mymachine-20120111232235.hddimg
</literallayout>
<note>The previous instructions are also present in the README that was copied
from meta-crownbay, which should also be updated to reflect the specifics of your
new BSP.
That file and the <filename>README.hardware</filename> file in the top-level
<filename>poky</filename> directory
also provides some suggestions for things to try if booting fails and produces
strange error messages.</note>
</para>
<para>
Because this new image is not in any way tailored to the system you're
booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
example, it might not be completely functional though it should at least boot to a text
prompt.
Specifically, it might fail to boot into graphics without some tweaking.
If this ends up being the case, a possible next step would be to replace the
<filename>mymachine.conf</filename>
contents with the contents of <filename>atom-pc.conf</filename> and replace
<filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
in <filename>meta-yocto</filename> and see if it fares any better.
In any case, following the previous steps should
probably give you a buildable and bootable image.
Getting things working like you want
them to for your hardware will normally require some amount of experimentation with
configuration settings.
</para>
</section>
</appendix>

View File

@ -4,179 +4,178 @@
<chapter id='dev-manual-intro'>
<title>The Yocto Project Development Manual</title>
<section id='intro'>
<title>Introduction</title>
<para>
WRITER NOTE: The goal of this manual is to provide an over-arching development guide for using the Yocto Project.
The intent is to give the reader the “big picture” around development.
Much of the information in the manual will be detailed in other manuals.
For example, detailed information on Git, repositories and open-source in general can be found in many places.
Another example is getting set up to use the Yocto Project, which our Yocto Project Quick Start covers.
However, this manual needs to at least address it.
One might ask “What becomes of the Poky Reference Manual?”
This manual, over time, needs to develop into a pure reference manual where all procedural information
eventually ends up in an appropriate guide.
A good example of information perfect for the Poky Reference Manual is the appendix on variable
definitions (glossary).
</para>
<para>
Welcome to the Yocto Project Development Manual!
This manual gives you an idea of how to use the Yocto Project to develop embedded Linux
images and user-space applications to run on targeted devices.
Reading this manual gives you an overview of image, kernel, and user-space application development
using the Yocto Project.
Because much of the information in this manual is general, it contains many references to other
sources where you can find more detail.
For example, detailed information on Git, repositories and open-source in general
can be found in many places.
Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
</para>
<section id='intro'>
<title>Introduction</title>
<para>
The Yocto Project Development Manual, however, does provide detailed examples on how to create a
Board Support Package (BSP), change the kernel source code, and re-configure the kernel.
You can find this information in the appendices of the manual.
</para>
</section>
<para>
Welcome to the Yocto Project Development Guide!
This guide provides a general view of the development process using the Yocto Project.
This guide is just that a guide.
It helps you understand the bigger picture involving development using the Yocto Project.
</para>
</section>
<section id='what-this-manual-provides'>
<title>What this Manual Provides</title>
<section id='what-this-manual-provides'>
<title>What this Manual Provides</title>
<para>
The following list describes what you can get from this guide:
<itemizedlist>
<listitem><para>Information that lets you get set
up to develop using the Yocto Project.</para></listitem>
<listitem><para>Information to help developers that are new to the open source environment
and to the distributed revision control system Git, which the Yocto Project
uses.</para></listitem>
<listitem><para>An understanding of common end-to-end development models.</para></listitem>
<listitem><para>Development case overviews for both system development and user-space
applications.</para></listitem>
<listitem><para>An overview and understanding of the emulation environment used with
the Yocto Project (QEMU).</para></listitem>
<!-- <listitem><para>A discussion of target-level analysis techniques, tools, tips,
and tricks.</para></listitem>
<listitem><para>Considerations for deploying your final product.</para></listitem> -->
<listitem><para>An understanding of basic kernel architecture and
concepts.</para></listitem>
<!-- <listitem><para>Information that will help you migrate an existing project to the
Yocto Project development environment.</para></listitem> -->
<listitem><para>Many references to other sources of related information.</para></listitem>
</itemizedlist>
</para>
</section>
<para>
The following list describes what you can get from this guide:
<itemizedlist>
<listitem><para>Information that lets you get set
up to develop using the Yocto Project.</para></listitem>
<listitem><para>Information to help developers that are new to the open source environment
and to the distributed revision control system Git, which the Yocto Project
uses.</para></listitem>
<listitem><para>An understanding of common end-to-end development models.</para></listitem>
<listitem><para>Development case overviews for both system development and user-space
applications.</para></listitem>
<listitem><para>An overview and understanding of the emulation environment used with
the Yocto Project (QEMU).</para></listitem>
<listitem><para>A discussion of target-level analysis techniques, tools, tips,
and tricks.</para></listitem>
<listitem><para>Considerations for deploying your final product.</para></listitem>
<listitem><para>An understanding of basic kernel architecture and
concepts.</para></listitem>
<listitem><para>Information that will help you migrate an existing project to the
Yocto Project development environment.</para></listitem>
<listitem><para>Many references to other sources of related information.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='what-this-manual-does-not-provide'>
<title>What this Manual Does Not Provide</title>
<section id='what-this-manual-does-not-provide'>
<title>What this Manual Does Not Provide</title>
<para>
This manual will not give you the following:
<itemizedlist>
<listitem><para>Step-by-step instructions if those instructions exist in other Yocto
Project documentation.
For example, The Application Development Toolkit (ADT) Users Guide contains detailed
instruction on how to obtain and configure the
<trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem>
<listitem><para>Reference material.
This type of material resides in an appropriate reference manual.
For example, system variables are documented in the
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink>.</para></listitem>
<listitem><para>Detailed public information that is not specific to the Yocto Project.
For example, exhaustive information on how to use Git is covered better through the
Internet than in this manual.</para></listitem>
</itemizedlist>
</para>
</section>
<para>
This manual will not give you the following:
<itemizedlist>
<listitem><para>Step-by-step instructions if those instructions exist in other Yocto
Project documentation.
For example, The Application Development Toolkit (ADT) Users Guide contains detailed
instruction on how to obtain and configure the Eclipse Yocto Plug-in.</para></listitem>
<listitem><para>Reference material.
This type of material resides in an appropriate reference manual.
For example, system variables are documented in the Poky Reference Manual.</para></listitem>
<listitem><para>Detailed public information that is not specific to the Yocto Project.
For example, exhaustive information on how to use Git is covered better through the
Internet than in this manual.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='other-information'>
<title>Other Information</title>
<section id='other-information'>
<title>Other Information</title>
<para>
Because this manual presents overview information for many different topics, you will
need to supplement it with other information.
The following list presents other sources of information you might find helpful:
<itemizedlist>
<listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>:
</emphasis> The home page for the Yocto Project provides lots of information on the project
as well as links to software and documentation.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started
with the Yocto Project quickly and start building an image.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference
guide to the Yocto Project build component known as "Poky."
The manual also contains a reference chapter on Board Support Package (BSP)
layout.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
This guide provides information that lets you get going with the ADT to
develop projects using the Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
This guide defines the structure for BSP components.
Having a commonly understood structure encourages standardization.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
This manual describes the architecture of the Yocto Project kernel and provides
some work flow examples.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
Yocto Eclipse Plug-in</ulink>:</emphasis> A step-by-step instructional video that
demonstrates how an application developer uses Yocto Plug-in features within
the Eclipse IDE.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis>
A list of commonly asked questions and their answers.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.0-release-notes-poky-5.0'>
Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
release of the Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
The bug tracking application the Yocto Project uses.
If you find problems with the Yocto Project, you should report them using this
application.</para></listitem>
<listitem><para><emphasis>
Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing
lists, click on the following URLs and follow the instructions:
<itemizedlist>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a
Yocto Discussions mailing list.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
Yocto Project Discussions mailing list.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
for a mailing list to receive offical Yocto Project announcements for developments and
as well as Yocto Project milestones.</para></listitem>
</itemizedlist></para></listitem>
<listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
Two IRC channels on freenode are available
for Yocto Project and Poky discussions: <filename>#yocto</filename> and
<filename>#poky</filename>.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
The company where the Yocto Project build system Poky was first developed.
OpenedHand has since been acquired by Intel Corporation.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
The company who acquired OpenedHand in 2008 and continues development on the
Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
from and to which it contributes.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://developer.berlios.de/projects/bitbake/'>
Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://bitbake.berlios.de/manual/'>
BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
</para></listitem>
<listitem><para><emphasis>
<ulink url='http://pimlico-project.org/'>Pimlico</ulink>:</emphasis>
A suite of lightweight Personal Information Management (PIM) applications designed
primarily for handheld and mobile devices.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
</emphasis> An open source machine emulator and virtualizer.</para></listitem>
</itemizedlist>
</para>
</section>
<para>
Because this manual presents overview information for many different topics, you will
need to supplement it with other information.
The following list presents other sources of information you might find helpful:
<itemizedlist>
<listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>:
</emphasis> The home page for the Yocto Project provides lots of information on the project
as well as links to software and documentation.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started
with the Yocto Project quickly and start building an image.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference
guide to the Yocto Project build component known as "Poky."
The manual also contains a reference chapter on Board Support Package (BSP)
layout.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
This guide provides information that lets you get going with the ADT to
develop projects using the Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
This guide defines the structure for BSP components.
Having a commonly understood structure encourages standardization.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
This manual describes the architecture of the Yocto Project kernel and provides
some work flow examples.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
Yocto Eclipse Plug-in</ulink>:</emphasis> A step-by-step instructional video that
demonstrates how an application developer uses Yocto Plug-in features within
the Eclipse IDE.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis>
A list of commonly asked questions and their answers.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.0-release-notes-poky-5.0'>
Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
release of the Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
The bug tracking application the Yocto Project uses.
If you find problems with the Yocto Project, you should report them using this
application.</para></listitem>
<listitem><para><emphasis>
Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing
lists, click on the following URLs and follow the instructions:
<itemizedlist>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a
Yocto Project Discussions mailing list.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
for a mailing list to receive offical Yocto Project announcements for developments and
as well as Yocto Project milestones.</para></listitem>
</itemizedlist></para></listitem>
<listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
Two IRC channels on freenode are available
for Yocto Project and Poky discussions: <filename>#yocto</filename> and
<filename>#poky</filename>.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
The company where the Yocto Project build system Poky was first developed.
OpenedHand has since been acquired by Intel Corporation.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
The company who acquired OpenedHand in 2008 and continues development on the
Yocto Project.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
from and to which it contributes.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://developer.berlios.de/projects/bitbake/'>
Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://bitbake.berlios.de/manual/'>
BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
</para></listitem>
<listitem><para><emphasis>
<ulink url='http://pimlico-project.org/'>Pimlico</ulink>:</emphasis>
A suite of lightweight Personal Information Management (PIM) applications designed
primarily for handheld and mobile devices.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
</emphasis> An open-source machine emulator and virtualizer.</para></listitem>
</itemizedlist>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4

View File

@ -47,7 +47,7 @@
<listitem><para>The <filename>poky-extras</filename> Git repository placed
within the local Yocto Project files Git repository</para></listitem>
<listitem><para>A bare clone of the Linux Yocto kernel upstream Git
repository that you want to modify
repository to which you want to push your modifications.
</para></listitem>
<listitem><para>A copy of that bare clone in which you make your source
modifcations</para></listitem>
@ -56,15 +56,16 @@
<para>
The following figure summarizes these four areas.
Within each rectangular that represents a data structure an URL appears at the
Within each rectangular that represents a data structure, a
host development directory pathname appears at the
lower left-hand corner of the box.
These URLs are the locations used in this example.
These pathnames are the locations used in this example.
The figure also provides key statements and commands used during the kernel
modification process:
</para>
<para>
<imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in"
<imagedata fileref="figures/kernel-example-repos-edison.png" width="7in" depth="5in"
align="center" scale="100" />
</para>
@ -74,13 +75,13 @@
<listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis>
This area contains all the metadata that supports building images in the
Yocto Project build environment - the local Yocto Project files.
The Local Yocto Project files Git repository also contains the build directory
and a configuration directory that let you control the build.
Note also that in this example the repository also contains the
In this example, the local Yocto Project files Git repository also
contains the build directory, which contains the configuration directory
that lets you control the build.
In this example, the repository also contains the
<filename>poky-extras</filename> Git repository.</para>
<para>See the bulleted item
<link linkend='local-yp-release'>Yocto Project Release</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='local-yp-release'>Yocto Project Release</link>"
for information on how to get these files.</para></listitem>
<listitem><para><emphasis><filename>poky-extras</filename> Git Repository:</emphasis>
This area contains the <filename>meta-kernel-dev</filename> layer,
@ -91,9 +92,8 @@
(or really any) kernel recipes that faciliate the creation and development
of kernel features, BSPs or configurations.</para>
<para>See the bulleted item
<link linkend='poky-extras-repo'>The
<filename>poky-extras</filename> Git Repository</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='poky-extras-repo'>The
<filename>poky-extras</filename> Git Repository</link>"
for information on how to get these files.</para></listitem>
<listitem><para><emphasis>Bare Clone of the Linux Yocto kernel:</emphasis>
This bare Git repository tracks the upstream Git repository of the Linux
@ -105,8 +105,7 @@
<filename>poky-extras</filename> repository points to the bare clone
so that the build process can locate the locally changed source files.</para>
<para>See the bulleted item
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
for information on how to set up the bare clone.
</para></listitem>
<listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
@ -114,9 +113,14 @@
Any changes you make to files in this location need to ultimately be pushed
to the bare clone using the <filename>git push</filename> command.</para>
<para>See the bulleted item
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
for information on how to set up the bare clone.
<note>Typically, Git workflows follow a scheme where changes made to a local area
are pulled into a Git repository.
However, because the <filename>git pull</filename> command does not work
with bare clones, this workflow pushes changes to the
repository even though you could use other more complicated methods to
get changes into the bare clone.</note>
</para></listitem>
</itemizedlist>
</para>
@ -131,8 +135,7 @@
This example uses <filename>poky</filename> as the root directory of the
local Yocto Project files Git repository.
See the bulleted item
<link linkend='local-yp-release'>Yocto Project Release</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='local-yp-release'>Yocto Project Release</link>"
for information on how to get these files.
</para>
@ -146,14 +149,14 @@
$ git branch -a
$ git tag -l
</literallayout>
This example uses the Yocto Project 1.1_M3 Release,
which maps to the <filename>1.1_M3</filename> branch in the repository.
The following commands create and checkout the local <filename>1.1_M3</filename>
This example uses the Yocto Project 1.1.1 Release code named "edison",
which maps to the <filename>edison</filename> branch in the repository.
The following commands create and checkout the local <filename>edison</filename>
branch:
<literallayout class='monospaced'>
$ git checkout -b 1.1_M3 origin/1.1_M3
Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin.
Switched to a new branch '1.1_M3'
$ git checkout -b edison origin/edison
Branch edison set up to track remote branch edison from origin.
Switched to a new branch 'edison'
</literallayout>
</para>
</section>
@ -165,23 +168,42 @@
This example places the <filename>poky-extras</filename> Git repository inside
of <filename>poky</filename>.
See the bulleted item
<link linkend='poky-extras-repo'>The
<filename>poky-extras</filename> Git Repository</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='poky-extras-repo'>The
<filename>poky-extras</filename> Git Repository</link>"
for information on how to get the <filename>poky-extras</filename> repository.
</para>
<para>
Once you have the repository set up,
you have many development branches from which you can work.
From inside the repository you can see the branch names and the tag names used
in the Git repository using either of the following two commands:
<literallayout class='monospaced'>
$ cd poky
$ git branch -a
$ git tag -l
</literallayout>
This example uses the Yocto Project 1.1.1 Release code named "edison",
which maps to the <filename>edison</filename> branch in the repository.
The following commands create and checkout the local <filename>edison</filename>
branch:
<literallayout class='monospaced'>
$ git checkout -b edison origin/edison
Branch edison set up to track remote branch edison from origin.
Switched to a new branch 'edison'
</literallayout>
</para>
</section>
<section id='setting-up-the-bare-clone-and-its-copy'>
<title>Setting Up the Bare Clone and its Copy</title>
<para>
This example modifies the <filename>linux-yocto-3.0</filename> kernel.
This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
Thus, you need to create a bare clone of that kernel and then make a copy of the
bare clone.
See the bulleted item
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
for information on how to do that.
</para>
@ -189,14 +211,16 @@
The bare clone exists for the kernel build tools and simply as the receiving end
of <filename>git push</filename>
commands after you make edits and commits inside the copy of the clone.
The copy (<filename>linux-yocto-3.0</filename> in this example) has to have
The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have
a local branch created and checked out for your work.
This example uses <filename>common-pc-base</filename> as the local branch.
The following commands create and checkout the branch:
<literallayout class='monospaced'>
$ cd ~/linux-yocto-3.0
$ cd ~/my-linux-yocto-3.0-1.1.x-work
$ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
Branch common-pc-base set up to track remote branch yocto/standard/common-pc/base from origin.
Checking out files: 100% (7289/7289), done.
Branch common-pc-base set up to track remote branch
yocto/standard/common-pc/base from origin.
Switched to a new branch 'common-pc-base'
</literallayout>
</para>
@ -224,7 +248,9 @@
of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
a half times the number of cores your machine supports.
</note>
The following commands build the default <filename>qemux86</filename> image:
The following two commands <filename>source</filename> the build environment setup script
and build the default <filename>qemux86</filename> image.
If necessary, the script creates the build directory:
<literallayout class='monospaced'>
$ cd ~/poky
$ source oe-init-build-env
@ -242,15 +268,14 @@
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
$ bitbake -k core-image-minimal
</literallayout>
</para>
<para>
The <filename>source</filename> command sets up the build environment and,
if necessary, creates the build directory.
The following <filename>bitbake</filename> command starts the build.
The following <filename>bitbake</filename> command starts the build:
<literallayout class='monospaced'>
$ bitbake -k core-image-minimal
</literallayout>
<note>Be sure to check the settings in the <filename>local.conf</filename>
before starting the build.</note>
</para>
@ -287,7 +312,7 @@
<para>
The file you change in this example is named <filename>calibrate.c</filename>
and is located in the <filename>linux-yocto-3.0</filename> Git repository
and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
(the copy of the bare clone) in <filename>init</filename>.
This example simply inserts several <filename>printk</filename> statements
at the beginning of the <filename>calibrate_delay</filename> function.
@ -298,8 +323,7 @@
<literallayout class='monospaced'>
void __cpuinit calibrate_delay(void)
{
unsigned long ticks, loopbit;
int lps_precision = LPS_PREC;
unsigned long lpj;
static bool printed;
if (preset_lpj) {
@ -315,8 +339,7 @@
<literallayout class='monospaced'>
void __cpuinit calibrate_delay(void)
{
unsigned long ticks, loopbit;
int lps_precision = LPS_PREC;
unsigned long lpj;
static bool printed;
printk("*************************************\n");
printk("* *\n");
@ -374,15 +397,16 @@
change the target architecture of the machine you are building or you move
the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
<itemizedlist>
<listitem><para><emphasis>Build for the Correct Target Architecture</emphasis> - The
<listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> The
<filename>local.conf</filename> file in the build directory defines the build's
target architecture.
By default, <filename>MACHINE</filename> is set to
<filename>qemux86</filename>, which specifies a 32-bit Intel Architecture
<filename>qemux86</filename>, which specifies a 32-bit
<trademark class='registered'>Intel</trademark> Architecture
target machine suitable for the QEMU emulator.
In this example, <filename>MACHINE</filename> is correctly configured.
</para></listitem>
<listitem><para><emphasis>Optimize Build Time</emphasis> - Also in the
<listitem><para><emphasis>Optimize Build Time:</emphasis> Also in the
<filename>local.conf</filename> file are two variables that can speed your
build time if your host supports multi-core and multi-thread capabilities:
<filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
@ -391,7 +415,7 @@
cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the
number of cores.</para></listitem>
<listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
Layer</emphasis> - The <filename>BBLAYERS</filename> variable in the
Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the
<filename>bblayers.conf</filename> file found in the
<filename>poky/build/conf</filename> directory needs to have the path to your local
<filename>meta-kernel-dev</filename> layer.
@ -408,20 +432,20 @@
/home/scottrif/poky/poky-extras/meta-kernel-dev \
"
</literallayout></para></listitem>
<listitem><para><emphasis>Identify Your Source Files</emphasis> - In the
<listitem><para><emphasis>Identify Your Source Files:</emphasis> In the
<filename>linux-yocto_3.0.bbappend</filename> file located in the
<filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
directory, you need to identify the location of the
local source code, which in this example is the bare clone named
<filename>linux-yocto-3.0.git</filename>.
<filename>linux-yocto-3.0-1.1.x.git</filename>.
To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
local <filename>linux-yocto-3.0.git</filename> Git repository by adding the
local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the
following statement.
Be sure to substitute your user information in the statement:
<literallayout class='monospaced'>
KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0.git
KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
</literallayout></para></listitem>
<listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the
<listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the
<filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
the kernel machine with the following statement:
<literallayout class='monospaced'>
@ -436,7 +460,8 @@
Because all the kernel <filename>.bbappend</filename> files are parsed during the
build process regardless of whether you are using them or not, you should either
comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all
<filename>.bbappend</filename> files, or you should simply remove all the files
unused <filename>.bbappend</filename> files.
Alternatively, you can simply remove all the files
except the one your are using for the build
(i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
</note>
@ -451,14 +476,15 @@
<orderedlist>
<listitem><para>Your environment should be set up since you previously sourced
the <filename>oe-init-build-env</filename> script.
If it isn't, source the script again from <filename>poky</filename>
If it isn't, source the script again from <filename>poky</filename>.
</para></listitem>
<listitem><para>Be sure old images are cleaned out by running the
<filename>cleanall</filename> BitBake task as follows:
<literallayout class='monospaced'>
$ cd ~/poky
$ bitbake -c cleanall linux-yocto
</literallayout></para>
<para><note>Never remove by hand any files from the <filename>tmp/deploy</filename>
<para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
directory insided the local Yocto Project files build directory.
Always use the BitBake <filename>cleanall</filename> task to clear
out previous builds.</note></para></listitem>
@ -466,14 +492,12 @@
<literallayout class='monospaced'>
$ bitbake -k core-image-minimal
</literallayout></para></listitem>
</orderedlist>
</para>
<para>
Finally, boot the modified image in the QEMU emulator using this command:
<literallayout class='monospaced'>
<listitem><para>Finally, boot the modified image in the QEMU emulator
using this command:
<literallayout class='monospaced'>
$ runqemu qemux86
</literallayout>
</literallayout></para></listitem>
</orderedlist>
</para>
<para>
@ -495,8 +519,8 @@
<title>Changing the Kernel Configuration</title>
<para>
This example changes the default behavior (off) of the Symmetric Multi-processing Support
(<filename>CONFIG_SMP</filename>) to on.
This example changes the default behavior, which is "off", of the Symmetric
Multi-processing Support (<filename>CONFIG_SMP</filename>) to "on".
It is a simple example that demonstrates how to reconfigure the kernel.
</para>
@ -505,33 +529,96 @@
<para>
If you took the time to work through the example that modifies the kernel source code
in <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
Code</xref> you are set up to quickly work through this example.
If not, then work through the following list to prepare:
<itemizedlist>
<listitem><para><emphasis>Understand the development environment:</emphasis>
See <xref linkend='understanding-the-files-you-need'>
Understanding the Files You Need</xref> for information.</para></listitem>
<listitem><para><emphasis>Set up the local Yocto Project files Git
repository:</emphasis>
See <xref linkend='setting-up-the-local-yocto-project-files-git-repository'>
Setting Up the Local Yocto Project Files Git Repository</xref> for
information.</para></listitem>
<listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git
repository:</emphasis>
See <xref linkend='setting-up-the-poky-extras-git-repository'>
Setting Up <filename>poky-extras</filename> Git repository</xref> for
information.</para></listitem>
<listitem><para><emphasis>Set up the the bare clone and its copy:</emphasis>
See <xref linkend='setting-up-the-bare-clone-and-its-copy'>
Setting Up the Bare Clone and its Copy</xref> for information.
</para></listitem>
<listitem><para><emphasis>Build the default QEMU kernel image:</emphasis>
See <xref linkend='building-and-booting-the-default-qemu-kernel-image'>
Building and Booting the Default QEMU Kernel image</xref>
for information.
Do not boot the image in the QEMU emulator at this point.</para></listitem>
</itemizedlist>
in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
Code</link>" you should already have the Yocto Project files set up on your
host machine.
If this is the case, go to then next section titled
"<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
<filename>CONFIG_SMP</filename> Behavior</link>" and continue with the
example.
</para>
<para>
If you don't have the Yocto Project files established on your system,
you can get them through tarball extraction or by
cloning the <filename>poky</filename> Git repository.
This example uses <filename>poky</filename> as the root directory of the
local Yocto Project files Git repository.
See the bulleted item
"<link linkend='local-yp-release'>Yocto Project Release</link>"
for information on how to get these files.
</para>
<para>
Once you have the repository set up,
you have many development branches from which you can work.
From inside the repository you can see the branch names and the tag names used
in the Git repository using either of the following two commands:
<literallayout class='monospaced'>
$ cd poky
$ git branch -a
$ git tag -l
</literallayout>
This example uses the Yocto Project 1.1.1 Release code named "edison",
which maps to the <filename>edison</filename> branch in the repository.
The following commands create and checkout the local <filename>edison</filename>
branch:
<literallayout class='monospaced'>
$ git checkout -b edison origin/edison
Branch edison set up to track remote branch edison from origin.
Switched to a new branch 'edison'
</literallayout>
</para>
<para>
Next, you need to build the default <filename>qemux86</filename> image that you
can boot using QEMU.
<note>
Because a full build can take hours, you should check two variables in the
<filename>build</filename> directory that is created after you source the
<filename>oe-init-build-env</filename> script.
You can find these variables
<filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
in the <filename>build/conf</filename> directory in the
<filename>local.conf</filename> configuration file.
By default, these variables are commented out.
If your host development system supports multi-core and multi-thread capabilities,
you can uncomment these statements and set the variables to significantly shorten
the full build time.
As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number
of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
a half times the number of cores your machine supports.
</note>
The following two commands <filename>source</filename> the build environment setup script
and build the default <filename>qemux86</filename> image.
If necessary, the script creates the build directory:
<literallayout class='monospaced'>
$ cd ~/poky
$ source oe-init-build-env
### Shell environment set up for builds. ###
You can now run 'bitbake &lt;target&gt;'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-toolchain-sdk
adt-installer
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86'
</literallayout>
</para>
<para>
The following <filename>bitbake</filename> command starts the build:
<literallayout class='monospaced'>
$ bitbake -k core-image-minimal
</literallayout>
<note>Be sure to check the settings in the <filename>local.conf</filename>
before starting the build.</note>
</para>
</section>
@ -540,10 +627,10 @@
<para>
By default, <filename>CONFIG_SMP</filename> supports single processor machines.
To see this default setting from within the QEMU emulator boot your image using
To see this default setting from within the QEMU emulator, boot your image using
the emulator as follows:
<literallayout class='monospaced'>
$ runqemu qemux86
$ runqemu qemux86 qemuparams="-smp 2"
</literallayout>
</para>
@ -557,6 +644,8 @@
processor : 0
#
</literallayout>
Logout of the emulator using the <filename>exit</filename> command and
then close it down.
</para>
</section>
@ -566,7 +655,7 @@
<para>
The <filename>menuconfig</filename> tool provides an interactive method with which
to set kernel configurations.
You need to run <filename>menuconfig</filename> inside the BitBake environment.
You need to run <filename>menuconfig</filename> inside the Yocto BitBake environment.
Thus, the environment must be set up using the <filename>oe-init-build-env</filename>
script found in the Yocto Project files Git repository build directory.
If you have not sourced this script do so with the following commands:
@ -579,7 +668,7 @@
<para>
After setting up the environment to run <filename>menuconfig</filename>, you are ready
to use the tool to interactively change the kernel configuration.
In this example we are basing our changes on the <filename>linux-yocto-3.0</filename>
In this example, we are basing our changes on the <filename>linux-yocto-3.0-1.1.x</filename>
kernel.
The Yocto Project build environment recognizes this kernel as
<filename>linux-yocto</filename>.
@ -596,23 +685,29 @@
You can find it at <filename>Processor Type and Features</filename>.
The configuration selection is
<filename>Symmetric Multi-processing Support</filename>.
After using the arrow keys to highlight this selection, press "y" to select it.
Then, exit out and save your selections.
</para>
<para>
Once you save the selection the <filename>.config</filename> configuration file
Once you save the selection, the <filename>.config</filename> configuration file
is updated.
This is the file that the build system uses to configure the Linux Yocto kernel
when it is built.
You can find and examine this file in the Yocto Project files Git repository in
the build directory.
This example uses the following:
This example uses the following.
Note that this example directory is artificially split and many of the characters
in the actually filename are omitted in order to make it more
readable:
<literallayout class='monospaced'>
~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...r20/linux-qemux86-standard-build
~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.10+git1+d38...
...3a9ac596f7a-r3/linux-qemux86-standard-build
</literallayout>
</para>
<para>
Within the <filename>.config</filename> you can see the following setting:
Within the <filename>.config</filename> file, you can see the following setting:
<literallayout class='monospaced'>
CONFIG_SMP=y
</literallayout>
@ -621,13 +716,19 @@
<para>
A good method to isolate changed configurations is to use a combination of the
<filename>menuconfig</filename> tool and simple shell commands.
Before changing configurations with <filename>menuconfig</filename> simply rename
the default <filename>.config</filename>, use <filename>menuconfig</filename> to make
Before changing configurations with <filename>menuconfig</filename>, copy the
existing <filename>.config</filename> and rename it to something else,
use <filename>menuconfig</filename> to make
as many changes an you want and save them, then compare the renamed configuration
file against the newly created file.
You can use the resulting differences as your base to create configuration fragments
to permanently save in your kernel layer.
For an example of this procedure, see [WRITER'S NOTE: need forwarding link to section].
<note>
Be sure to make a copy of the <filename>.config</filename> and don't just
rename it.
The Yocto Project build system needs an existing <filename>.config</filename>
from which to work.
</note>
</para>
</section>
@ -635,7 +736,7 @@
<title>Recompiling the Kernel and Testing the New Configuration</title>
<para>
At this point you are ready to recompile your kernel image with
At this point, you are ready to recompile your kernel image with
the new setting in effect using the BitBake commands below:
<literallayout class='monospaced'>
$ bitbake linux-yocto -c compile -f
@ -646,7 +747,7 @@
<para>
Now run the QEMU emulator:
<literallayout class='monospaced'>
$ runqemu qemux86
$ runqemu qemux86 qemuparams="-smp 2"
</literallayout>
</para>
@ -662,7 +763,7 @@
</para>
<para>
From the output you can see that you have successfully reconfigured the kernel.
From the output, you can see that you have successfully reconfigured the kernel.
</para>
</section>
</section>
@ -671,13 +772,14 @@
<title>Adding Kernel Recipes</title>
<para>
This section presents an example that adds kernel recipes, which provide
A future release of this manual will present an example that adds kernel recipes, which provide
new functionality to the kernel.
</para>
<para>
[Example to be supplied]
</para>
<imagedata fileref="figures/wip.png"
width="2in" depth="3in" align="center" scalefit="1" />
</para>
</section>

View File

@ -9,16 +9,23 @@
Many development models exist for which you can use the Yocto Project.
However, for the purposes of this manual we are going to focus on two common ones:
System Development and User Application Development.
System Development covers Board Support Package (BSP) development and kernel modification.
System Development covers Board Support Package (BSP) development and kernel modification
or configuration.
User Application Development covers development of applications that you intend to run on some
target hardware.
</para>
<para>
This chapter presents overviews of both system and application models.
If you want to reference specific examples of these development models,
see <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref> and
<xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>.
If you want to examine specific examples of the system development models,
see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
appendix and the
"<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
For a user-space application development example that uses the
<trademark class='trade'>Eclipse</trademark> IDE,
see the
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
</para>
<section id='system-development-model'>
@ -27,7 +34,7 @@
<para>
System development involves modification or creation of an image that you want to run on
a specific hardware target.
Usually when you want to create an image that runs on embedded hardware the image does
Usually, when you want to create an image that runs on embedded hardware, the image does
not require the same amount of features that a full-fledged Linux distribution provides.
Thus, you can create a much smaller image that is designed to just use the hardware
features for your particular hardware.
@ -35,33 +42,33 @@
<para>
To help you understand how system development works in the Yocto Project, this section
covers two types of image development: BSP creation and kernel modification
(see <xref linkend='kernel-spot'></xref>).
covers two types of image development: BSP creation and kernel modification or
configuration.
</para>
<section id='developing-a-board-support-package-bsp'>
<title>Developing a Board Support Package (BSP)</title>
<para>
A BSP is a package of recipes that when applied during a build results in
A BSP is a package of recipes that, when applied, during a build results in
an image you can run on a particular board.
Thus, the package, when compiled into the new image, supports the operation of the board.
</para>
<note>
For a brief list of terms used when describing the development process in the Yocto Project,
see <xref linkend='yocto-project-terms'>Yocto Project Terms</xref> in this manual.
see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section.
</note>
<para>
The remainder of this section presents the basic steps to create a BSP basing it on an
existing BSP that ships with the Yocto Project.
You can reference <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref>
for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
</para>
<para>
This illustration and the following list summarizes the BSP creation general workflow.
The following illustration and list summarize the BSP creation general workflow.
</para>
<para>
@ -71,37 +78,38 @@
<para>
<orderedlist>
<listitem><para><emphasis>Set up your host development system to support
development using the Yocto Project</emphasis>: See
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
The Linux Distributions</ulink> section and
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
The Packages</ulink> section both
development using the Yocto Project</emphasis>: See the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
in the Yocto Project Quick Start for requirements.</para></listitem>
<listitem><para><emphasis>Establish a local copy of the Yocto Project files on your
system</emphasis>: You need to have the Yocto Project files available on your host system.
Having the Yocto Project files on your system gives you access to the build
process and tools you need.
For information on how to get these files, see the
<xref linkend='getting-setup'>Getting Setup</xref> section in this manual.</para></listitem>
"<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
<listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>: Having
the BSP files on your system gives you access to the build
process and tools you need.
For information on how to get these files, see
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.</para></listitem>
process and tools you need for creating a BSP.
For information on how to get these files, see the
"<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
<listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:
The Yocto Project ships with several BSPs that support various hardware.
It is best to base your new BSP on an existing BSP rather than create all the
recipes and configuration files from scratch.
While it is possible to create everything from scratch, basing your new BSP
on something that is close is much easier.
Or, at a minimum, it gives you some structure with which to start.</para>
Or, at a minimum, leveraging off an existing BSP
gives you some structure with which to start.</para>
<para>At this point you need to understand your target hardware well enough to determine which
existing BSP it most closely matches.
Things to consider are your hardwares on-board features such as CPU type and graphics support.
Things to consider are your hardwares on-board features, such as CPU type and graphics support.
You should look at the README files for supported BSPs to get an idea of which one
you could use.
A generic Atom-based BSP to consider is the Crown Bay that does not support
the Intel® Embedded Media Graphics Driver (EMGD).
A generic <trademark class='registered'>Intel</trademark>
<trademark class='trade'>Atom</trademark>-based BSP to consider is the
Crown Bay that does not support the <trademark class='registered'>Intel</trademark>
Embedded Media Graphics Driver (EMGD).
The remainder of this example uses that base BSP.</para>
<para>To see the supported BSPs, go to the Yocto Project
<ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click
@ -110,35 +118,34 @@
isolating and storing work for a given piece of hardware.
A layer is really just a location or area in which you place the recipes for your BSP.
In fact, a BSP is, in itself, a special type of layer.
Consider an application as another example that illustrates a layer.
Another example that illustrates a layer is an application.
Suppose you are creating an application that has library or other dependencies in
order for it to compile and run.
The layer, in this case, would be where all the recipes that define those dependencies
are kept. The key point for a layer is that it is an isolated area that contains
are kept.
The key point for a layer is that it is an isolated area that contains
all the relevant information for the project that the Yocto Project build
system knows about.</para>
<note>The Yocto Project supports four BSPs that are part of the
Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
<filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
The recipes and configurations for these four BSPs are located and dispersed
within local Yocto Project files.
within the local Yocto Project files.
Consequently, they are not totally isolated in the spirit of layers unless you think
of <filename>meta-yocto</filename> as a layer itself.
On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest,
N450, and Sugar Bay are isolated.</note>
<para>When you set up a layer for a new BSP you should follow a standard layout.
This layout is described in the
<ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development
Guide.
In the standard layout you will notice a suggested structure for recipes and
<para>When you set up a layer for a new BSP, you should follow a standard layout.
This layout is described in the section
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>Example Filesystem Layout</ulink>" section of the Board Support Package (BSP) Development Guide.
In the standard layout, you will notice a suggested structure for recipes and
configuration information.
You can see the standard layout for the Crown Bay BSP in this example by examining the
directory structure of the <filename>meta-crownbay</filename> layer inside the
local Yocto Project files.</para></listitem>
<listitem><para><emphasis>Make configuration changes to your new BSP
layer</emphasis>: The standard BSP layer structure organizes the files you need to edit in
<filename>conf</filename> and several <filename>recipes-*</filename> within the
<filename>conf</filename> and several <filename>recipes-*</filename> directories within the
BSP layer.
Configuration changes identify where your new layer is on the local system
and identify which kernel you are going to use.
@ -148,24 +155,22 @@
recipes you don't use, and adding new recipes that you need to support your hardware.
</para></listitem>
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
changes to your BSP layer there remains a few things
changes to your BSP layer, there remains a few things
you need to do for the Yocto Project build system in order for it to create your image.
You need to get the build environment ready by sourcing an environment setup script
and you need to be sure two key configuration files are configured appropriately.</para>
<para>The entire process for building an image is overviewed in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
Building an Image</ulink> section of the Yocto Project Quick Start.
<para>The entire process for building an image is overviewed in the section
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.
You might want to reference this information.</para></listitem>
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project uses the BitBake
tool to build images based on the type of image you want to create.
You can find more information on BitBake
<ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
<para>The build process supports several types of images to satisfy different needs.
See
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
Reference: Images</ulink> in the
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink>for information on supported images.</para></listitem>
See the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
appendix in The Yocto Project Reference Manual for information on
supported images.</para></listitem>
</orderedlist>
</para>
@ -173,11 +178,11 @@
You can view a video presentation on "Building Custom Embedded Images with Yocto"
at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
You can also find supplemental information in
<ulink url='http://yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
<ulink url='http://yoctoproject.org/docs/1.1.1/bsp-guide/bsp-guide.html'>
The Board Support Package (BSP) Development Guide</ulink>.
Finally, there is wiki page write up of the example located
Finally, there is wiki page write up of the example also located
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
here</ulink> you might find helpful.
here</ulink> that you might find helpful.
</para>
</section>
@ -196,9 +201,10 @@
The remainder of this section presents a high-level overview of the Linux Yocto
kernel architecture and the steps to modify the Linux Yocto kernel.
For a complete discussion of the kernel, see
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink>.
You can reference <xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>
You can reference the appendix
"<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
for a detailed example that changes the configuration of a kernel.
</para>
@ -210,6 +216,7 @@
of files that contain kernel patches.
The Yocto Project, however, employs mechanisims, that in a sense, result in a kernel source
generator.
By the end of this section, this analogy will become clearer.
</para>
<para>
@ -224,8 +231,12 @@
stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
<listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
<listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The current
Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
<listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The
stable Linux Yocto kernel to use with the Yocto Project current (master) development.
This kernel is based on the Linux 3.0 release.</para></listitem>
<listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The
stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x.
This kernel is based on the Linux 3.0 release.</para></listitem>
<listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
kernel based on the latest upstream release candidate available.</para></listitem>
</itemizedlist>
@ -304,7 +315,7 @@
</para>
<para>
<imagedata fileref="figures/kernel-overview-3.png"
<imagedata fileref="figures/kernel-overview-3-edison.png"
width="6in" depth="4in" align="center" scale="100" />
</para>
@ -342,7 +353,7 @@
<para>
Again, for a complete discussion of the Yocto Project kernel's architcture and its
branching strategy,
see the <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink>.
Also, you can reference
<xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
@ -358,24 +369,22 @@
</para>
<para>
<imagedata fileref="figures/kernel-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" />
<imagedata fileref="figures/kernel-dev-flow.png"
width="6in" depth="7.5in" align="center" scalefit="1" />
</para>
<para>
<orderedlist>
<listitem><para><emphasis>Set up your host development system to support
development using the Yocto Project</emphasis>: See
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
The Linux Distributions</ulink> section and
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
The Packages</ulink> section both
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
in the Yocto Project Quick Start for requirements.</para></listitem>
<listitem><para><emphasis>Establish a local copy of the Yocto Project files on your
system</emphasis>: Having the Yocto Project files on your system gives you access to
the build process and tools you need.
For information on how to get these files, see the bulleted item
<link linkend='local-yp-release'>Yocto Project Release</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
"<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
</para></listitem>
<listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git
repository</emphasis>: This repository is the area for your configuration
@ -384,85 +393,85 @@
It is good practice to set this repository up inside the local Yocto
Project files Git repository.
For information on how to get these files, see the bulleted item
<link linkend='poky-extras-repo'>The
<filename>poky-extras</filename> Git Repository</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
</para></listitem>
"<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
earlier in this manual.</para></listitem>
<listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your
system</emphasis>: In order to make modifications to the kernel you need two things:
a bare clone of the Linux Yocto kernel you are modifying and a copy of that
bare clone.
a bare clone of the Linux Yocto kernel you are modifying and
a copy of that bare clone.
The bare clone is required by the build process and is the area to which you
push your kernel source changes.
push your kernel source changes (pulling does not work with bare clones).
The copy of the bare clone is a local Git repository that contains all the kernel's
source files.
You make your changes to the files in this copy of the bare clone.
For information on how to set these two items up, see the bulleted item
<link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
<xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
</para></listitem>
"<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
earlier in this manual.</para></listitem>
<listitem><para><emphasis>Make changes to the kernel source code if
applicable</emphasis>: Modifying the kernel does not always mean directly
changing source files.
However, if you have to do this then you make the changes in the local
However, if you have to do this, you make the changes in the local
Git repository you set up to hold the source files (i.e. the copy of the
bare clone).
Once the changes are made you need to use Git commands to commit the changes
Once the changes are made, you need to use Git commands to commit the changes
and then push them to the bare clone.</para></listitem>
<listitem><para><emphasis>Make kernel configuration changes
to your local kernel layer if applicable</emphasis>:
If your situation calls for changing the kernel's configuration you can
If your situation calls for changing the kernel's configuration, you can
use <filename>menuconfig</filename>
to enable and disable kernel configurations.
Using <filename>menuconfig</filename> allows you to develop and test the
configuration changes you are making to the kernel.</para></listitem>
Using <filename>menuconfig</filename> allows you to interactively develop and test the
configuration changes you are making to the kernel.
When saved, changes using <filename>menuconfig</filename> update the kernel's
<filename>.config</filename>.
As an alternative method to changing the kernel's configuration, you can simply
edit the <filename>.config</filename> found in the Yocto Project build
directory at <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>
directly.</para></listitem>
<listitem><para><emphasis>Add new kernel recipes if applicable</emphasis>: The standard
layer structure organizes recipe files inside the
<filename>meta-kernel-dev</filename> layer that is within the
<filename>poky-extras</filename> Git repository.
If you need to add new kernel recipes you add them within this layer.
Also within this area you will find the <filename>.bbappend</filename>
If you need to add new kernel recipes, you add them within this layer.
Also within this area, you will find the <filename>.bbappend</filename>
file that appends information to the kernel's recipe file used during the
build.
</para></listitem>
<listitem><para><emphasis>Prepare for the build</emphasis>: Once you have made all the
changes to your kernel (configurations, source code changes, recipe additions,
or recipe changes) there remains a few things
you need to do for the Yocto Project build system in order for it to create your image.
If you have not done so you need to get the build environment ready by sourcing
or recipe changes), there remains a few things
you need to do in order for the Yocto Project build system to create your image.
If you have not done so, you need to get the build environment ready by sourcing
the environment setup script described earlier.
You also need to be sure two key configuration files
(<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
are configured appropriately.</para>
<para>The entire process for building an image is overviewed in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
Building an Image</ulink> section of the Yocto Project Quick Start.
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.
You might want to reference this information.
Also, you should look at the detailed examples found in the appendices at
end of this manual.</para></listitem>
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project uses the BitBake
at the end of this manual.</para></listitem>
<listitem><para><emphasis>Build the image</emphasis>: The Yocto Project
build system Poky uses the BitBake
tool to build images based on the type of image you want to create.
You can find more information on BitBake
<ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
<para>The build process supports several types of images to satisfy different needs.
See
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
Reference: Images</ulink> in the
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink> for information on supported
images.</para></listitem>
See the appendix
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
in The Yocto Project Reference Manual for information on supported images.</para></listitem>
<listitem><para><emphasis>Make your configuration changes available
in the kernel layer</emphasis>: Up to this point all the configuration changes to the
in the kernel layer</emphasis>: Up to this point, all the configuration changes to the
kernel have been done and tested iteratively.
Once they are tested and ready to go you can move them into the kernel layer,
which allows you to distribute the layer.
[WRITER'S NOTE: Not sure if the layer is meta-kernel-dev or if it would be
a new layer copied from the work done there.]</para></listitem>
<listitem><para><emphasis>Push your configuration and recipe changes upstream to the
linux Yocto Git repository (in-tree changes)</emphasis>: If the changes you made
are suited for all Linux Yocto users you might want to push the changes up into
the Linux Yocto Git repository so that they become part of the kernel tree
and available to everyone using the kernel.</para></listitem>
Once they are tested and ready to go, you can move them into the kernel layer,
which allows you to distribute the layer.</para></listitem>
<listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>:
If the changes you made
are suited for all Linux Yocto users, you might want to push the changes to a
contribution area for the Linux Yocto Git repository.
Once the changes are pushed, you can request that they
be pulled into the master branch of the kernel tree.
Doing so makes them available to everyone using the kernel.</para></listitem>
</orderedlist>
</para>
</section>
@ -470,11 +479,194 @@
</section>
<section id='place-holder-section-two'>
<title>Place-Holder Section For Application Development</title>
<title>Application Development Workflow</title>
<para>
Text needed here.
Application development involves creation of an application that you want to be able
to run on your target hardware, which is running a Linux Yocto image.
The Yocto Project provides an Application Development Toolkit (ADT) that
facilitates quick development and integration of your application into its run-time environment.
Using the ADT you can employ cross-development toolchains designed for your target hardware
to compile and link your application.
You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
If you are familiar with the popular Eclipse IDE, you can use an Eclipse Yocto Plug-in to
allow you to develop, deploy, and test your application all from within Eclipse.
</para>
<para>
While we strongly suggest using the Yocto Project ADT to develop your application, you might
not want to.
If this is the case, you can still use pieces of the Yocto Project for your development process.
However, because the process can vary greatly, this manual does not provide detail on the process.
</para>
<section id='workflow-using-the-adt-and-eclipse'>
<title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
<para>
To help you understand how application development works in the Yocto Project ADT
environment, this section
provides an overview of the general development process.
If you want to see a detailed example of the process as it is used from within the Eclipse
IDE, see
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
The Application Development Toolkit (ADT) User's Manual</ulink>.
</para>
<para>
This illustration and the following list summarizes the application development general workflow.
</para>
<para>
<imagedata fileref="figures/app-dev-flow.png"
width="7in" depth="8in" align="center" scale="100" />
</para>
<para>
<orderedlist>
<listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
See
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
in the Yocto Project Quick Start for requirements.</para></listitem>
<!--
WRITER NOTE: The areas to get the kernel and root filesystem are located in the Index of
downloads. There are many forms of each. The files that have "rootfs" are just the
target root filesystems. The file that is very small and starts with bzImage is just
the kernel image isolated so that it can be written to a special on-board area of
flash memory. Some systems require this. In the machines directory there are
files that combine the kernel image and the root filesystem. These files are the ISO
and HDDIMG files. ISO images are designed to be deployed on a DVD or CD. The ISO
images are designed to be deployed on a USB stick. There might be some relics in
the machine directory. For example, there is the "emenlow-bernard-5.0.0.tar.bz2"
file. Nobody seems to know what this is. If a developer needs the image and the
root filesystem I think that they want the small kernel image and a matching root
filesystem. Although, Paul Eggleton says that the HDDIMG types could be used to
develop on. I am not sure that we can use one of those in the ADT though as they
want you to point to the kernel image and the target root filesystem. Maybe you
could just point to the same spot. I am not sure.
-->
<listitem><para><emphasis>Secure the Linux Yocto Kernel Target Image</emphasis>:
You must have a target kernel image that has been built using the Yocto Project.</para>
<para>Depending on whether the Yocto Project has a pre-built image that matches your target
architecture and where you are going to run the image while you develop your application
(QEMU or real hardware), the area you get the image from differs.
<itemizedlist>
<listitem><para>Download the image from
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>
<filename>machines</filename></ulink> if your target architecture is supported
and you are going to develop and test your application on actual hardware.
</para></listitem>
<listitem><para>Download the image from the
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>
<filename>machines/qemu</filename></ulink> if your target architecture is supported
and you are going to develop and test your application using the QEMU
emulator.</para></listitem>
<listitem><para>Build your image if you cannot find a pre-built image that matches
your target architecture.
If your target architecture is similar to a supported architecture, you can
modify the kernel image before you build it.
See the
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
section earlier in this manual for information on how to create a modified
Linux Yocto kernel.</para></listitem>
</itemizedlist></para>
<para>For information on pre-built kernel image naming schemes for images
that can run on the QEMU emulator, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>.</para></listitem>
<listitem><para><emphasis>Install the ADT</emphasis>:
The ADT provides a target-specific cross-development toolchain, the root filesystem,
the QEMU emulator, and other tools that can help you develop your application.
While it is possible to get these pieces separately, the Yocto Project provides an
easy method.
You can get these pieces by running an ADT installer script, which is configurable.
For information on how to install the ADT, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
Application Development (ADT) User's Manual</ulink>.</para></listitem>
<listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</emphasis>:
If you choose not to install the ADT using the ADT Installer,
you need to find and download the
appropriate root filesystems.
You can find these tarballs in the same areas used for the kernel images.
Depending on the type of image you are running, the root filesystem you need differs.
For example, if you are developing an application that runs on an image that
supports Sato, you need to get root filesystem that supports Sato.
</para></listitem>
<listitem><para><emphasis>Create and Build your Application</emphasis>:
At this point, you need to have source files for your application.
Once you have the files, you can use the Eclipse IDE to import them and build the
project.
If you are not using Eclipse, you need to use the cross-development tools you have
installed to create the image.</para></listitem>
<listitem><para><emphasis>Deploy the Image with the Application</emphasis>:
If you are using the Eclipse IDE, you can deploy your image to the hardware or to
QEMU through the project's preferences.
If you are not using the Eclipse IDE, then you need to deploy the application using
other methods to the hardware.
Or, if you are using QEMU, you need to use that tool and load your image in for testing.
</para></listitem>
<listitem><para><emphasis>Test and Debug the Application</emphasis>:
Once your application is deployed, you need to test it.
Within the Eclipse IDE, you can use the debubbing environment along with the
set of user-space tools installed along with the ADT to debug your application.
Of course, the same user-space tools are available separately to use if you choose
not to use the Eclipse IDE.</para></listitem>
</orderedlist>
</para>
</section>
<section id='workflow-without-adt'>
<title>Workflow Without ADT</title>
<para>
If you want to develop an application outside of the Yocto Project ADT environment, you
can still employ the cross-development toolchain, the QEMU emulator, and a number of supported
target image files.
You just need to follow these general steps:
<orderedlist>
<listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis>
For information on how to install the toolchain, see the
"<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
<ulink url='http://www.yoctoproject/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
Application Development (ADT) User's Manual</ulink>.</para></listitem>
<listitem><para><emphasis>Download the Target Image:</emphasis> The Yocto Project supports
several target architectures and has many pre-built kernel images and root filesystem
images.</para>
<para>If you are going to develop your application on hardware, go to the
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/'>
<filename>machines</filename></ulink> download area and choose a target machine area
from which to download the kernel image and root filesystem.
This download area could have several files in it that support development using
actual hardware.
For example, the area might contain <filename>.hddimg</filename> files that combine the
kernel image with the filesystem, boot loaders, etc.
Be sure to get the files you need for your particular development process.</para>
<para>If you are going to develop your application and then run and test it using the QEMU
emulator, go to the
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu/'>
<filename>machines/qemu</filename></ulink> download area.
From this area, go down into the directory for your target architecture
(e.g. <filename>qemux86_64</filename> for an
<trademark class='registered'>Intel</trademark>-based 64-bit architecture).
Download kernel, root filesystem, and any other files you need for your process.
<note>In order to use the root filesystem in QEMU, you need to extract it.
See the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the
root filesystem.</note></para></listitem>
<listitem><para><emphasis>Develop and Test your Application:</emphasis> At this point,
you have the tools to develop your application.
If you need to separately install and use the QEMU emulator, you can go to
<ulink url='http://www.qemu.org'>QEMU Home Page</ulink> to download and learn about the
emulator.</para></listitem>
</orderedlist>
</para>
</section>
</section>
</chapter>

View File

@ -7,12 +7,12 @@
<para>
This chapter helps you understand the Yocto Project as an open source development project.
In general, working in an open-source environment is very different than working in a
In general, working in an open source environment is very different as compared to working in a
proprietary environment.
Additionally, the Yocto Project uses specific tools and constructs as part of its development
environment.
The chapter specifically addresses open source philosophy, licensing issues, code repositories,
the open source distributed version control system Git, and best practices using Yocto Project.
the open source distributed version control system Git, and best practices using the Yocto Project.
</para>
<section id='open-source-philosophy'>
@ -33,23 +33,21 @@
stake in the software project.
The open source environment contains new copyright, licensing, domain, and consumer issues
that differ from the more traditional development environment.
In an open source environment the end-product, source material, and documentation are
In an open source environment, the end-product, source material, and documentation are
all available to the public at no cost.
</para>
<para>
A benchmark example of an open source project is the Linux Kernel, which was initially conceived
and created by Finnish computer science student Linus Torvalds in 1991.
Conversely, a good example of a non-open source project is the Windows family of operating
systems developed by Microsoft Corporation.
Conversely, a good example of a non-open source project is the
<trademark class='registered'>Windows</trademark> family of operating
systems developed by <trademark class='registered'>Microsoft</trademark> Corporation.
</para>
<para>
Wikipedia has a good historical description of the Open Source Philosophy
<ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>.
</para>
<para>
You can also find helpful information on how to participate in the Linux Community
<ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>.
</para>
@ -66,21 +64,21 @@
From the interface, you can click on any particular item in the "Name" column and
see the URL at the bottom of the page that you need to set up a Git repository for
that particular item.
The ability to create Git repositories of the Yocto Project source allows you to
Having a local Git repository of the Yocto Project files allows you to
make changes, contribute to the history, and ultimately enhance the Yocto Project's
tools, Board Support Packages, and so forth.
</para>
<para>
Conversely, if you are a developer that is not interested in contributing back to the
Yocto Project you have the ability to simply download and extract release tarballs
Yocto Project, you have the ability to simply download and extract release tarballs
and use them within the Yocto Project environment.
All that is required is a particular release of Yocto Project, a kernel, and
your application source code.
</para>
<para>
For any supported release of Yocto Project you can go to the Yocto Project websites
For any supported release of Yocto Project, you can go to the Yocto Project websites
<ulink url='http://www.yoctoproject.org/download'>download page</ulink> and get a
tarball of the release.
You can also go to this site to download any supported BSP tarballs.
@ -103,12 +101,13 @@
<para>
<imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
</para></listitem>
<listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink></emphasis>
This area contains an index of the Eclipse-plugin, miscellaneous support, poky, pseudo, and
all released versions of Yocto Project in the form of images or tarballs.
<listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
This area contains an index releases such as
the <trademark class='trade'>Eclipse</trademark>
Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
and all released versions of Yocto Project in the form of images or tarballs.
Downloading and extracting these files does not produce a Git repository but rather
a snapshot of a particular release or image.
[WRITER NOTE: link will be http://downloads.yoctoproject.org.]</para>
a snapshot of a particular release or image.</para>
<para>
<imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
</para></listitem>
@ -116,7 +115,7 @@
This page on the Yocto Project website allows you to download any Yocto Project
release or Board Support Package (BSP) in tarball form.
The tarballs are similar to those found in the
<ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink> area.</para>
<ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
<para>
<imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
</para></listitem>
@ -130,77 +129,119 @@
<para>
Following is a list of terms and definitions users new to the Yocto Project development
environment might find helpful.
Some terms are universal but are included here just in case:
While some of these terms are universal, the list includes them just in case:
<itemizedlist>
<listitem><para><emphasis>Image</emphasis> - An image is the result produced when
<listitem><para><emphasis>Append Files:</emphasis> Files that append build information to
a recipe file.
Information in append files override the information in the similarly-named recipe file.
Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
<listitem><para><emphasis>BitBake:</emphasis> The task executor and scheduler used by
the Yocto Project to build images.
For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
BitBake documentation</ulink>.</para></listitem>
<listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
and inheritance allowing commonly used patterns to be defined once and easily used
in multiple recipes.
Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Configuration File:</emphasis> Configuration information in the
<filename>.conf</filename> files provides global definitions of variables.
The <filename>conf/local.conf</filename> configuration file in the Yocto Project
build directory defines user-defined variables that affect each build.
The <filename>distro/poky.conf</filename> configuration file also in the
build directory defines Yocto distro configuration
variables used only when building with this policy.
Machine configuration files, which
are located throughout the Yocto Project file structure, define
variables for specific hardware and are only used when building for that target
(e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines
variables for the Texas Instruments ARM Cortex-A8 development board).
Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Cross-Development Toolchain:</emphasis> A collection of software development
tools and utilities that allow you to develop software for targeted architectures.
This toolchain contains cross-compilers, linkers, and debuggers that are specific to
an architecure.
You can use the Yocto Project to build cross-development toolchains in tarball form that when
unpacked contain the development tools you need to cross-compile and test your software.
The Yocto Project ships with images that contain toolchains for supported architectures
as well.
Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
<listitem><para><emphasis>Image:</emphasis> An image is the result produced when
BitBake processes a given collection of recipes and related metadata.
Images are the binary output that runs on specific hardware and for specific
use cases.
For a list of the supported image types that the Yocto Project provides, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
Reference: Images</ulink> appendix in
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
appendix in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.</para></listitem>
<listitem><para><emphasis>Recipe</emphasis> - A set of instructions for building packages.
A recipe describes where you get source code and which patches to apply.
Recipes describe dependencies for libraries or for other recipes and they
also contain configuration and compilation options.
Recipes contain the logical unit of execution, the software/images to build, and
use the <filename>.bb</filename> file extension.</para></listitem>
<listitem><para><emphasis>BitBake</emphasis> - The task executor and scheduler used by Yocto Project
to build images.
For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
BitBake documentation</ulink>.</para></listitem>
<listitem><para><emphasis>Package</emphasis> - The packaged output from a baked recipe.
A package is generally the compiled binaries produced from the recipe's sources.
You bake something by running it through BitBake.</para></listitem>
<listitem><para><emphasis>Layer</emphasis> - A collection of recipes representing the core,
<listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core,
a BSP, or an application stack.</para></listitem>
<listitem><para><emphasis>Metadata</emphasis> - A term used throughout the Yocto Project
documentation that refers to the files that BitBake parses when building an image.
<listitem><para><emphasis>Metadata:</emphasis> The files that BitBake parses when building an image.
Metadata includes recipes, classes, and configuration files.</para></listitem>
<listitem><para><emphasis>Meta-Toolchain</emphasis> - A collection of software development
tools and utilities that allow you to develop software for targeted architectures.
These toolchains contain cross-compilers, linkers, and debuggers that are specific to
an architecure.
You can use the Yocto Project to build meta-toolchains in tarball form that when
unpacked contain the development tools you need to cross-compile and test your software.
The Yocto Project ships with images that contain toolchains for supported architectures
as well.</para></listitem>
<listitem><para><emphasis>Configuration File</emphasis>: Configuration information in the
<filename>.conf</filename> files provides global definitions of variables.
The <filename>build/conf/local.conf</filename> configuration file defines user-defined variables
that effect each build.
The <filename>distro/poky.conf</filename> configuration file defines Yocto distro configuration
variables used only when building with this policy.
The <filename>machine/beagleboard.conf</filename> configuration file defines variables
for the Beagleboard and are only used when building for that target
(i.e. Texas Instruments ARM Cortex-A8 development board).
Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
and inheritance allowing commonly used patterns to be defined once and easily used
in multiple recipes.
Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
<listitem><para><emphasis>Append Files</emphasis> - Files that append build information to
a recipe file.
Information in append files override the information in the similarly-named recipe file.
Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
<listitem><para><emphasis>Tasks</emphasis> - Arbitrary groups of software Recipes.
You simply use Tasks to hold recipes that when built usually accomplish a single task.
For example, a task could contain the recipes for a companys proprietary or value-add software.
Or the task could contain the recipes that enable graphics.
A task is really just another recipe.
Because task files are recipes, they end with the <filename>.bb</filename> filename
extension.</para></listitem>
<listitem><para><emphasis>OE-Core</emphasis> - A core set of metadata originating
<listitem><para><emphasis>OE-Core:</emphasis> A core set of metadata originating
with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
This metadata is found in the <filename>meta</filename> directory of the Yocto Project
files.</para></listitem>
<listitem><para><emphasis>Upstream</emphasis> - A reference to source code or repositories
<listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
A package is generally the compiled binaries produced from the recipe's sources.
You bake something by running it through BitBake.</para></listitem>
<listitem><para><emphasis>Poky:</emphasis> The build tool that the Yocto Project
uses to create images.</para></listitem>
<listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.
A recipe describes where you get source code and which patches to apply.
Recipes describe dependencies for libraries or for other recipes, and they
also contain configuration and compilation options.
Recipes contain the logical unit of execution, the software/images to build, and
use the <filename>.bb</filename> file extension.</para></listitem>
<listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.
You simply use Tasks to hold recipes that, when built, usually accomplish a single task.
For example, a task could contain the recipes for a companys proprietary or value-add software.
Or, the task could contain the recipes that enable graphics.
A task is really just another recipe.
Because task files are recipes, they end with the <filename>.bb</filename> filename
extension.</para></listitem>
<listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
that are not local to the development system but located in a master area that is controlled
by the maintainer of the source code.
For example, in order for a developer to work on a particular piece of code they need to
For example, in order for a developer to work on a particular piece of code, they need to
first get a copy of it from an "upstream" source.</para></listitem>
<listitem><para><emphasis>Yocto Project Files:</emphasis>
This term refers to the directory structure created as a result of downloading
and unpacking a Yocto Project release tarball or setting up a Git repository
by cloning <filename>git://git.yoctoproject.org/poky</filename>.
Sometimes the term "the Yocto Project Files structure" is used as well.</para>
<para>The Yocto Project files contain BitBake, Documentation, metadata and
other files that all support the development environment.
Consequently, you must have the Yocto Project files in place on your development
system in order to do any development using the Yocto Project.</para>
<para>The name of the top-level directory of the Yocto Project file structure
is derived from the Yocto Project release tarball.
For example, downloading and unpacking <filename>poky-edison-6.0.1.tar.bz2</filename>
results in a Yocto Project file structure whose Yocto Project source directory is named
<filename>poky-edison-6.0.1</filename>.
If you create a Git repository, then you can name the repository anything you like.</para>
<para>You can find instruction on how to set up the Yocto Project files on your
host development system by reading
the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>Getting
Setup</ulink>" section.</para></listitem>
<listitem><para><emphasis>Yocto Project Build Directory:</emphasis>
This term refers to the area used by the Yocto Project for builds.
The area is created when you <filename>source</filename> the Yocto Project setup
environment script that is found in the Yocto Project files area.
(e.g. <filename>oe-init-build-env</filename>).
You can create the Yocto Project build directory anywhere you want on your
development system.
Here is an example that creates the directory in <filename>mybuilds</filename>
and names the Yocto Project build directory <filename>YP-6.0.1</filename>:
<literallayout class='monospaced'>
$ source poky-edison-6.0.1/oe-init-build-env $HOME/mybuilds/YP-6.0.1
</literallayout>
If you don't specifically name the directory, BitBake creates it
in the current directory and uses the name <filename>build</filename>.
Also, if you supply an existing directory, then BitBake uses that
directory as the Yocto Project build directory and populates the build hierarchy
beneath it.</para></listitem>
</itemizedlist>
</para>
</section>
@ -209,9 +250,9 @@
<title>Licensing</title>
<para>
Because open source projects are open to the public they have different licensing structures in place.
Because open source projects are open to the public, they have different licensing structures in place.
License evolution for both Open Source and Free Software has an interesting history.
If you are interested in the history you can find basic information here:
If you are interested in this history, you can find basic information here:
<itemizedlist>
<listitem><para><ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink>
</para></listitem>
@ -235,15 +276,20 @@
<para>
When you build an image using Yocto Project, the build process uses a known list of licenses to
ensure compliance.
Once the build completes, the list of all licenses found and used during the build are
kept in the resulting build directory at
<filename>&lt;build_directory&gt;/tmp/deploy/images/licenses</filename>.
ensure compliance.
You can find this list in the Yocto Project files directory at
<filename>meta/files/common-licenses</filename>.
Once the build completes, the list of all licenses found and used during that build are
kept in the Yocto Project build directory at
<filename>tmp/deploy/images/licenses</filename>.
</para>
<para>
If a module requires a license that is not in the base list, the build process
generates a warning during the build.
These tools make it easier for a developer to be certain of the licenses with which
their shipped products must comply.
However, it is still up to the developer to resolve potential licensing issues.
However, even with these tools it is still up to the developer to resolve potential licensing issues.
</para>
<para>
@ -254,14 +300,13 @@
for a standard format for communicating the components, licenses, and copyrights
associated with a software package.
<ulink url='http://opensource.org'>OSI</ulink> is a corporation dedicated to the Open Source
Definition and the effort for reviewing
and approving licenses that are OSD-conformant.
Definition and the effort for reviewing and approving licenses that are OSD-conformant.
</para>
<para>
You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
The wiki page discusses the license infrastructure used by the Yocto Project.
This wiki page discusses the license infrastructure used by the Yocto Project.
</para>
</section>
@ -282,7 +327,7 @@
You do not have to be an expert in Git to be functional.
A good place to look for instruction on a minimal set of Git commands is
<ulink url='http://git-scm.com/documentation'>here</ulink>.
If you need to download Git you can do so
If you need to download Git, you can do so
<ulink url='http://git-scm.com/download'>here</ulink>.
</para>
@ -294,7 +339,7 @@
This methodology also allows for an environment in which you can do lots of
experimentation on your project as you develop changes or new features.
For example, you can create a “branch”, experiment with some feature, and then
if you like the feature you incorporate the branch into the tree.
if you like the feature, you incorporate the branch into the tree.
If you dont, you cut the branch off by deleting it.
</para>
@ -309,55 +354,63 @@
omits the many arguments they support.
See the Git documentation for complete descriptions and strategies on how to use these commands:
<itemizedlist>
<listitem><para><emphasis><filename>git init</filename></emphasis> Initializes an empty Git repository.
<listitem><para><emphasis><filename>git init</filename>:</emphasis> Initializes an empty Git repository.
You cannot use Git commands unless you have a <filename>.git</filename> repository.</para></listitem>
<listitem><para><emphasis><filename>git clone</filename></emphasis> Creates a clone of a repository.
During collaboration this command allows you to create a local repository that is on
<listitem><para><emphasis><filename>git clone</filename>:</emphasis> Creates a clone of a repository.
During collaboration, this command allows you to create a local repository that is on
equal footing with a fellow developers repository.</para></listitem>
<listitem><para><emphasis><filename>git add</filename></emphasis> Adds updated file contents to the index that
<listitem><para><emphasis><filename>git add</filename>:</emphasis> Adds updated file contents
to the index that
Git uses to track changes.
All files that have changed must be added before they can be committed.</para></listitem>
<listitem><para><emphasis><filename>git commit</filename></emphasis> Creates a “commit” that documents
You must add all files that have changed before you can commit them.</para></listitem>
<listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a “commit” that documents
the changes you made.
Commits are used for historical purposes, for determining if a maintainer of a project
will allow the change, and for ultimately pushing the change from your local Git repository
into the projects upstream (or master) repository.</para></listitem>
<listitem><para><emphasis><filename>git status</filename></emphasis> Reports any modified files that
<listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
possibly need added and committed.</para></listitem>
<listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename></emphasis> - Changes
your working branch. This command is analogous to “cd”.</para></listitem>
<listitem><para><emphasis><filename>git checkout b &lt;working-branch&gt;</filename></emphasis> - Creates
<listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
your working branch.
This command is analogous to “cd”.</para></listitem>
<listitem><para><emphasis><filename>git checkout b &lt;working-branch&gt;</filename>:</emphasis> Creates
a working branch on your local machine where you can isolate work.
It is a good idea to use local branches when adding specific features or changes.
This way if you dont like what you have done you can easily get rid of the work.</para></listitem>
<listitem><para><emphasis><filename>git branch</filename></emphasis> Reports existing branches and
<listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports existing branches and
tells you which branch in which you are currently working.</para></listitem>
<listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename></emphasis>
Deletes an existing branch. You need to be in a branch other than the one you are deleting
<listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename>:</emphasis>
Deletes an existing branch.
You need to be in a branch other than the one you are deleting
in order to delete &lt;branch-name&gt;.</para></listitem>
<listitem><para><emphasis><filename>git pull</filename></emphasis> Retrieves information from an upstream Git
<listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information
from an upstream Git
repository and places it in your local Git repository.
You use this command to make sure you are synchronized with the upstream repository
from which the projects maintainer uses to pull changes into the master repository.</para></listitem>
<listitem><para><emphasis><filename>git push</filename></emphasis> Sends all your local changes you
have committed to an upstream Git repository.
You use this command to make sure you are synchronized with the repository
from which you are basing changes (.e.g. the master repository).</para></listitem>
<listitem><para><emphasis><filename>git push</filename>:</emphasis> Sends all your local changes you
have committed to an upstream Git repository (e.g. a contribution repository).
The maintainer of the project draws from these repositories when adding your changes to the
projects master repository.</para></listitem>
<listitem><para><emphasis><filename>git merge</filename></emphasis> Combines or adds changes from one
<listitem><para><emphasis><filename>git merge</filename>:</emphasis> Combines or adds changes from one
local branch of your repository with another branch.
When you create a local Git repository the default branch is named “master”.
When you create a local Git repository, the default branch is named “master”.
A typical workflow is to create a temporary branch for isolated work, make and commit your
changes, switch to the master branch, merge the changes from the temporary branch into the
master branch, and then delete the temporary branch</para></listitem>
<listitem><para><emphasis><filename>git cherry-pick</filename></emphasis> Choose and apply specific
changes, switch to your local master branch, merge the changes from the temporary branch into the
local master branch, and then delete the temporary branch.</para></listitem>
<listitem><para><emphasis><filename>git cherry-pick</filename>:</emphasis> Choose and apply specific
commits from one branch into another branch.
There are times when you might not be able to merge all the changes in one branch with
another but need to pick out certain ones.</para></listitem>
<listitem><para><emphasis><filename>gitk</filename></emphasis> Provides a GUI view of the branches
<listitem><para><emphasis><filename>gitk</filename>:</emphasis> Provides a GUI view of the branches
and changes in your local Git repository.
This command is a good way to see where things have diverged in your local repository.</para></listitem>
<listitem><para><emphasis><filename>git log</filename></emphasis> Reports a history of your changes to the
This command is a good way to graphically see where things have diverged in your
local repository.</para></listitem>
<listitem><para><emphasis><filename>git log</filename>:</emphasis> Reports a history of your changes to the
repository.</para></listitem>
<listitem><para><emphasis><filename>git diff</filename>:</emphasis> Displays line-by-line differences
between your local working files and the same files in the upstream Git repository that your
branch currently tracks.</para></listitem>
</itemizedlist>
</para>
</section>
@ -369,17 +422,22 @@
This section provides some overview on workflows using Git.
In particular, the information covers basic practices that describe roles and actions in a
collaborative development environment.
Again, if you are familiar with this type of development environment you might want to just skip the section.
Again, if you are familiar with this type of development environment, you might want to just
skip the section.
</para>
<para>
The Yocto Project files are maintained using Git in a "master" branch whose Git history
tracks every change and whose structure provides branches for all diverging functionality.
Although there is no need to use Git, This practice is typical for open-source projects.
For the Yocto Project a key individual called the "maintainer" is responsible for "master".
Although there is no need to use Git, many open source projects do so.
For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
branch of the Git repository.
The "master" branch is the “upstream” repository where the final builds of the project occur.
The maintainer is responsible for allowing changes in from other developers and for
organizing the underlying branch structure to reflect release strategies and so forth.
<note>You can see who is the maintainer for Yocto Project files by examining the
<filename>distro_tracking_fields</filename> file in the Yocto Project
<filename>meta/conf/distro/include</filename> directory.</note>
</para>
<para>
@ -394,7 +452,7 @@
Developers (including contributing community members) create and maintain cloned repositories
of the upstream "master" branch.
These repositories are local to their development platforms and are used to develop changes.
When a developer is satisfied with a particular feature or change they “push” the changes
When a developer is satisfied with a particular feature or change, they “push” the changes
to the appropriate "contrib" repository.
</para>
@ -428,55 +486,55 @@
While each development environment is unique, there are some best practices or methods
that help development run smoothly.
The following list describes some of these practices.
For more detailed information about these strategies see
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>.
<itemizedlist>
<listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit
small as compared to bundling many disparate changes into a single commit.
This practice not only keeps things manageable but also allows the maintainer
to more easily include or refuse changes.</para>
<para>It is also good practice to leave the repository in a state that allows you to
still successfully build your project.</para></listitem>
<listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and
delete local branches in your working Git repository.
You can name these branches anything you like.
It is helpful to give them names associated with the particular feature or change
on which you are working.
Once you are done with a feature or change you simply discard the branch.</para></listitem>
<listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
command allows you to take the
changes from one branch and fold them into another branch.
This process is especially helpful when more than a single developer might be working
on different parts of the same feature.
Merging changes also automatically identifies any collisions or “conflicts”
that might happen resulting from the same lines of code being altered by two different
developers.</para></listitem>
<listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should
use a system where branches indicate varying levels of code readiness.
For example, you can have a “work” branch to develop in, a “test” branch where the code or
change is tested, a “stage” branch where changes are ready to be committed, and so forth.
As your project develops, you can merge code across the branches to reflect ever-increasing
stable states of the development.</para></listitem>
<listitem><para><emphasis>Use Push and Pull</emphasis> - The push-pull workflow is based on the
concept of developers “pushing” local commits to a remote repository, which is
usually a contribution repository.
It is also based on the developers “pulling” known states of the project down into their
local development repositories.
This workflow easily allows you to pull changes submitted by other developers from the
upstream repository into your work area ensuring that you have the most recent software
on which to develop.
The Yocto Project has two scripts named <filename>create-pull-request</filename> and
<filename>send-pull-request</filename> that ship with the release to facilitate this
workflow.
You can find these scripts in the local Yocto Project files Git repository in
<filename>scripts</filename>.</para></listitem>
<listitem><para><emphasis>Patch Workflow</emphasis> - This workflow allows you to notify the
maintainer through an email that you have a change (or patch) you would like considered
for the "master" branch of the Git repository.
To send this type of change you format the patch and then send the email using the Git commands
<filename>git format-patch</filename> and <filename>git send-email</filename>.
You can find information on how to submit later in this chapter.</para></listitem>
</itemizedlist>
For more information about Git workflows, see the workflow topics in the
<ulink url='http://book.git-scm.com'>Git Community Book</ulink>.
<itemizedlist>
<listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep your changes you commit
small as compared to bundling many disparate changes into a single commit.
This practice not only keeps things manageable but also allows the maintainer
to more easily include or refuse changes.</para>
<para>It is also good practice to leave the repository in a state that allows you to
still successfully build your project.</para></listitem>
<listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and
delete local branches in your working Git repository.
You can name these branches anything you like.
It is helpful to give them names associated with the particular feature or change
on which you are working.
Once you are done with a feature or change, simply discard the branch.</para></listitem>
<listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
command allows you to take the
changes from one branch and fold them into another branch.
This process is especially helpful when more than a single developer might be working
on different parts of the same feature.
Merging changes also automatically identifies any collisions or “conflicts”
that might happen as a result of the same lines of code being altered by two different
developers.</para></listitem>
<listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should
use a system where branches indicate varying levels of code readiness.
For example, you can have a “work” branch to develop in, a “test” branch where the code or
change is tested, a “stage” branch where changes are ready to be committed, and so forth.
As your project develops, you can merge code across the branches to reflect ever-increasing
stable states of the development.</para></listitem>
<listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the
concept of developers “pushing” local commits to a remote repository, which is
usually a contribution repository.
This workflow is also based on developers “pulling” known states of the project down into their
local development repositories.
The workflow easily allows you to pull changes submitted by other developers from the
upstream repository into your work area ensuring that you have the most recent software
on which to develop.
The Yocto Project has two scripts named <filename>create-pull-request</filename> and
<filename>send-pull-request</filename> that ship with the release to facilitate this
workflow.
You can find these scripts in the local Yocto Project files Git repository in
<filename>scripts</filename>.</para></listitem>
<listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
maintainer through an email that you have a change (or patch) you would like considered
for the "master" branch of the Git repository.
To send this type of change you format the patch and then send the email using the Git commands
<filename>git format-patch</filename> and <filename>git send-email</filename>.
You can find information on how to submit later in this chapter.</para></listitem>
</itemizedlist>
</para>
</section>
@ -484,44 +542,59 @@
<title>Tracking Bugs</title>
<para>
The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
This bug-tracking application works well for group development because it tracks bugs and code
The Yocto Project uses its own implementation of
<ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
Implementations of Bugzilla work well for group development because they track bugs and code
changes, can be used to communicate changes and problems with developers, can be used to
submit and review patches, and can be used to manage quality assurance.
You can find a good overview of Bugzilla <ulink url='http://www.bugzilla.org/about/'>here</ulink>.
submit and review patches, and can be used to manage quality assurance.
The home page for the Yocto Project implementation of Bugzilla is
<ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
</para>
<para>
Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
such as when discovering an issue with some component of the build system that acts contrary
to the documentation or expectations.
You can find information
for Bugzilla configuration and bug tracking procedures specific to the Yocto Project
to the documentation or your expectations.
Following is the general procedure for submitting a new bug using the Yocto Project
Bugzilla.
You can find more information on defect management, bug tracking, and feature request
processes all accomplished through the Yocto Project Bugzilla on the wiki page
<ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.
<orderedlist>
<listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
a bug.</para></listitem>
<listitem><para>When submitting a new bug, be sure to choose the appropriate
Classification, Product, and Component for which the issue was found.
Defects for Yocto Project fall into one of four classifications: Yocto Projects,
Infrastructure, Poky, and Yocto Metadata Layers.
Each of these Classifications break down into multiple Products and, in some
cases, multiple Components.</para></listitem>
<listitem><para>Use the bug form to choose the correct Hardware and Architecture
for which the bug applies.</para></listitem>
<listitem><para>Indicate the Yocto Project version you were using when the issue
occurred.</para></listitem>
<listitem><para>Be sure to indicate the Severity of the bug.
Severity communicates how the bug impacted your work.</para></listitem>
<listitem><para>Provide a brief summary of the issue.
Try to limit your summary to just a line or two and be sure to capture the
essence of the issue.</para></listitem>
<listitem><para>Provide a detailed description of the issue.
You should provide as much detail as you can about the context, behavior, output,
and so forth that surround the issue.
You can even attach supporting files for output or log by using the "Add an attachment"
button.</para></listitem>
<listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
</orderedlist>
</para>
<para>
The Yocto Project uses its own version of the Bugzilla application.
You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.
You need to use this implementation of Bugzilla when logging a defect against anything released
by the Yocto Project team.
</para>
<para>
Here are some things to remember when dealing with bugs against the Yocto Project:
<itemizedlist>
<listitem><para>The Yocto Project follows a naming bug-naming convention:
<filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the
assigned defect ID used in Bugzilla.
So, for example, a valid way to refer to a defect when creating a commit comment
would be <filename>[YOCTO 1011]</filename>.
This convention becomes important if you are submitting patches against the Yocto Project
code itself.
See the following section for more information.</para></listitem>
<listitem><para>Defects for Yocto Project fall into one of four classifications: Yocto Projects,
Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
</itemizedlist>
</para>
<note>
Bugs in the Yocto Project Bugzilla follow naming convention:
<filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the
assigned defect ID used in Bugzilla.
So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.
This convention becomes important if you are submitting patches against the Yocto Project
code itself.
</note>
</section>
<section id='how-to-submit-a-change'>
@ -529,9 +602,35 @@
<para>
Contributions to the Yocto Project are very welcome.
You should send patches to the Yocto Project mailing list to get it in front of the
Yocto Project Maintainer.
When you send your patch, be sure to include a "signed-off-by:"
You should send patches to the appropriate Yocto Project mailing list to get them
in front of the Yocto Project Maintainer.
For a list of the Yocto Project mailing lists, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'> The
Yocto Project Reference Manual</ulink>.
</para>
<para>
Following is some guidance on which mailing list to use for what type of defect:
<itemizedlist>
<listitem><para>For defects against the Yocto Project build system Poky, send
your patch to the
<ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> mailing list.
This mailing list corresponds to issues that are not specific to the Yocto Project but
are part of the OE-core.
For example, a defect against anything in the <filename>meta</filename> layer
or the BitBake Manual could be sent to this mailing list.</para></listitem>
<listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project
documentation use the
<ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list.
This mailing list corresponds to Yocto-specific areas such as
<filename>meta-yocto</filename>, <filename>meta-intel</filename>,
<filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
</itemizedlist>
</para>
<para>
When you send a patch, be sure to include a "signed-off-by:"
line in the same style as required by the Linux kernel.
Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
as follows:
@ -573,66 +672,144 @@
<para>
In a collaborative environment, it is necessary to have some sort of standard
or method through which you submit changes.
Otherwise, things would get quite chaotic.
Otherwise, things could get quite chaotic.
</para>
<para>
When you submit a change or patch to the Yocto Project, you must follow certain procedures.
In particular, the headers in patches and the commit messages must follow a certain standard.
The general process is the same as described earlier in this chapter.
For complete details on how to create proper commit messages and patch headers see
[WRITER NOTE: I need the link to Mark's wiki page here that describes the process.]
When you form a commit, you must follow certain standards established by the
Yocto Project development team.
For each commit, you must provide a single-line summary of the change and you
almost always provide a more detailed description of what you did (i.e. the body
of the commit).
The only exceptions for not providing a detailed description would be if your
change is a simple, self-explanatory change that needs no description.
Here are the Yocto Project commit message guidelines:
<itemizedlist>
<listitem><para>Provide a single-line, short summary of the change.
This summary is typically viewable by source control systems.
Thus, providing something short and descriptive that gives the reader
a summary of the change is useful when viewing a list of many commits.
</para></listitem>
<listitem><para>For the body of the commit message, provide detailed information
that describes what you changed, why you made the change, and the approach
you used.
Provide as much detail as you can in the body of the commit message.
</para></listitem>
<listitem><para>If the change addresses a specific bug or issue that is
associated with a bug-tracking ID, prefix your detailed description
with the bug or issue ID.
For example, the Yocto Project tracks bugs using a bug-naming convention.
Any commits that address a bug must start with the bug ID in the description
as follows:
<literallayout class='monospaced'>
YOCTO #&lt;bug-id&gt;: &lt;Detailed description of commit&gt;
</literallayout></para></listitem>
</itemizedlist>
</para>
<para>
You can find more guidance on creating well-formed commit messages at this OpenEmbedded
wiki page:
<ulink url='http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines'></ulink>.
</para>
<para>
Following are general instructions for both pushing changes upstream and for submitting changes as patches.
</para>
</para>
<section id='pushing-a-change-upstream'>
<title>Pushing a Change Upstream</title>
<title>Pushing a Change Upstream and Requesting a Pull</title>
<para>
The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
<itemizedlist>
<listitem><para>Make your changes in your local Git repository.</para></listitem>
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
command.</para></listitem>
<listitem><para>Commit the change by using the <filename>git commit</filename>
command and push it to the upstream "contrib" repository.
Be sure to provide a commit message that follows the projects commit standards.</para></listitem>
<listitem><para>Notify the maintainer that you have pushed a change.</para></listitem>
</itemizedlist>
You can find general Git information on how to push a change upstream
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#Developing-With-git'>
here</ulink>.
<itemizedlist>
<listitem><para>Make your changes in your local Git repository.</para></listitem>
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
command.</para></listitem>
<listitem><para>Commit the change by using the <filename>git commit</filename>
command and push it to the "contrib" repository.
Be sure to provide a commit message that follows the projects commit standards
as described earlier.</para></listitem>
<listitem><para>Notify the maintainer that you have pushed a change by making a pull
request.
The Yocto Project provides two scripts that conveniently let you generate and send
pull requests to the Yocto Project.
These scripts are <filename>create-pull-request</filename> and
<filename>send-pull-request</filename>.
You can find these scripts in the <filename>scripts</filename> directory of the
Yocto Project file structure.</para>
<para>For help on using these scripts, simply provide the
<filename>--help</filename> argument as follows:
<literallayout class='monospaced'>
$ ~/poky/scripts/create-pull-request --help
$ ~/poky/scripts/send-pull-request --help
</literallayout></para></listitem>
</itemizedlist>
</para>
<para>
You can find general Git information on how to push a change upstream in the
<ulink url='http://book.git-scm.com/3_distributed_workflows.html'>Git Community Book</ulink>.
</para>
</section>
<section id='submitting-a-patch'>
<title>Submitting a Patch</title>
<title>Submitting a Patch Through Email</title>
<para>
If you have a just a few changes you can commit them and then submit them as an email to the maintainer.
If you have a just a few changes, you can commit them and then submit them as an
email to the maintainer.
Here is a general procedure:
<itemizedlist>
<listitem><para>Make your changes in your local Git repository.</para></listitem>
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
command.</para></listitem>
<listitem><para>Commit the change by using the <filename>git commit</filename> command.
Be sure to provide a commit message that follows the projects commit standards.</para></listitem>
<listitem><para>Format the commit by using the <filename>git format-patch</filename>
command.
This step produces a numbered series of files in the current directory one for
each commit.</para></listitem>
<listitem><para>Import the files into your mail client by using the
<filename>git-send-email</filename> command.</para></listitem>
<listitem><para>Send the email by hand to the maintainer.</para></listitem>
</itemizedlist>
Be aware that there could be protocols and standards that you need to follow for your particular
project.
You can find general Git information for submitting a patch
<ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development'>
here</ulink>.
<itemizedlist>
<listitem><para>Make your changes in your local Git repository.</para></listitem>
<listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
command.</para></listitem>
<listitem><para>Commit the change by using the
<filename>git commit --signoff</filename> command.
Using the <filename>--signoff</filename> option identifies you as the person
making the change and also satisfies the Developer's Certificate of
Origin (DCO) shown earlier.</para>
<para>When you form a commit you must follow certain standards established by the
Yocto Project development team.
See the earlier section
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
for Yocto Project commit message standards.</para></listitem>
<listitem><para>Format the commit into an email messsage.
To format commits, use the <filename>git format-patch</filename> command.
When you provide the command, you must include a revision list or a number of patches
as part of the command.
For example, these two commands each take the most recent single commit and
format it as an email message in the current directory:
<literallayout class='monospaced'>
$ git format-patch -1
$ git format-patch HEAD~
</literallayout></para>
<para>After the command is run, the current directory contains a
numbered <filename>.patch</filename> file for the commit.</para>
<para>If you provide several commits as part of the command,
the <filename>git format-patch</filename> command produces a numbered
series of files in the current directory one for each commit.
For information on the <filename>git format-patch</filename> command,
see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the
<filename>man git-format-patch</filename> command.</para></listitem>
<listitem><para>Import the files into your mail client by using the
<filename>git send-email</filename> command.
<note>In order to use <filename>git send-email</filename>, you must have the
the proper Git packages installed.
For Ubuntu and Fedora the package is <filename>git-email</filename>.</note></para>
<para>The <filename>git send-email</filename> command sends email by using a local
or remote Mail Transport Agent (MTA) such as
<filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
<filename>smtp</filename> configuration in your Git <filename>config</filename>
file.</para>
<para>The <filename>git send-email</filename> command is the preferred method
for sending your patches since there is no risk of compromising whitespace
in the body of the message, which can occur when you use your own mail client.
The command also has several options that let you
specify recipients and perform further editing of the email message.
For information on how to use the <filename>git send-email</filename> command,
use the <filename>man git-send-email</filename> command.</para></listitem>
</itemizedlist>
</para>
</section>
</section>

View File

@ -7,16 +7,15 @@
<para>
This chapter introduces the Yocto Project and gives you an idea of what you need to get started.
You can find enough information to set your development host up and build or use images for
hardware supported by the Yocto Project by reading the
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'>
Yocto Project Quick Start</ulink> located on the <ulink url='http://www.yoctoproject.org'>
Yocto Project website</ulink>.
You can find enough information to set up your development host and build or use images for
hardware supported by the Yocto Project by reading
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
The Yocto Project Quick Start</ulink>.
</para>
<para>
The remainder of this chapter summarizes what is in the Yocto Project Quick Start and provides
some higher level concepts you might want to consider.
some higher-level concepts you might want to consider.
</para>
<section id='introducing-the-yocto-project'>
@ -24,8 +23,8 @@
<para>
The Yocto Project is an open-source collaboration project focused on embedded Linux development.
The project currently provides a build system and various ancillary tools suitable for the
embedded developer.
The project currently provides a build system, which is sometimes referred to as "Poky",
and provides various ancillary tools suitable for the embedded developer.
The Yocto Project also features the Sato reference User Interface, which is optimized for
stylus driven, low-resolution screens.
</para>
@ -37,7 +36,8 @@
While the Yocto Project does not provide a strict testing framework,
it does provide or generate for you artifacts that let you perform target-level and
emulated testing and debugging.
And, if you are an Eclipse user, you can install an Eclipse Yocto Plug-in to allow you to
And, if you are an <trademark class='trade'>Eclipse</trademark>
IDE user, you can install an Eclipse Yocto Plug-in to allow you to
develop within that familiar environment.
</para>
</section>
@ -51,103 +51,102 @@
<listitem><para><emphasis>Host System:</emphasis> You should have a reasonably current
Linux-based host system.
You will have the best results with a recent release of Fedora,
OpenSUSE, or Ubuntu as these releases are frequently tested and officially supported
host systems.
OpenSUSE, or Ubuntu as these releases are frequently tested against the Yocto Project
and officially supported.
You should also have about 100 gigabytes of free disk space for building images.
</para></listitem>
<listitem><para><emphasis>Packages:</emphasis> The Yocto Project requires certain packages
exist on your development system (e.g. Python 2.6 or 2.7).
See <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#packages'>
The Packages</ulink> section in the Yocto Project Quick start for the exact package
requirements and the installation commands for the supported distributions.</para></listitem>
See "<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>"
section in the Yocto Project Quick start for the exact package
requirements and the installation commands to install them
for the supported distributions.</para></listitem>
<listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
You need a release of the Yocto Project.
You can get set up with local Yocto Project files one of two ways depending on whether you
are going to be contributing back into the Yocto Project source repository or not.
<note>
Regardless of the method you use, this manual will refer to the resulting
hierarchical set of files as "the local Yocto Project files."
Regardless of the method you use, this manual refers to the resulting
hierarchical set of files as "the Yocto Project files" or "the Yocto Project file
structure."
</note>
<itemizedlist>
<listitem><para><emphasis>Tarball Extraction:</emphasis> If you are not going to contribute
back into the Yocto Project you can simply download the Yocto Project release you want
back into the Yocto Project, you can simply download the Yocto Project release you want
from the websites <ulink url='http://yoctoproject.org/download'>download page</ulink>.
Once you have the tarball, just extract it into a directory of your choice.</para>
<para>For example, the following command extracts the Yocto Project 1.1 release tarball
into the current working directory and sets up a file structure whose top-level
directory is named <filename>poky-1.1</filename>:
<literallayout class='monospaced'>
$ tar xfj poky-1.1.tar.bz2
</literallayout></para>
<para>This method does not produce a <filename>poky</filename> Git repository.
You end up simply with a local snapshot of Yocto Project files that are based on the
particular release in the tarball.</para></listitem>
<para>For example, the following command extracts the Yocto Project 1.1.1 release tarball
into the current working directory and sets up the Yocto Project file structure
with a top-level directory named <filename>poky-edison-6.0.1</filename>:
<literallayout class='monospaced'>
$ tar xfj poky-edison-6.0.1.tar.bz2
</literallayout></para>
<para>This method does not produce a Git repository.
Instead, you simply end up with a local snapshot of the
Yocto Project files that are based on the particular release in the
tarball.</para></listitem>
<listitem><para><emphasis>Git Repository Method:</emphasis> If you are going to be contributing
back into the Yocto Project you should use Git commands to set up a local
<filename>poky</filename> Git repository of the Yocto Project.
back into the Yocto Project, you should use Git commands to set up a local
Git repository of the Yocto Project files.
Doing so creates a Git repository with a complete history of changes and allows
you to easily submit your changes upstream to the project.</para>
<para>The following transcript shows how to clone the <filename>poky</filename>
<para>The following transcript shows how to clone the Yocto Project files'
Git repository into the current working directory.
The command creates the repository in a directory named <filename>poky</filename>.
For information on the Yocto Project and Git, see
<xref linkend='git'>Git</xref> in
<xref linkend='dev-manual-newbie'>Working with Open Source Code</xref>.
For information on the Yocto Project and Git, see the
"<link linkend='git'>Git</link>" section.
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/poky
Initialized empty Git repository in /home/scottrif/poky/.git/
remote: Counting objects: 107624, done.
remote: Compressing objects: 100% (37128/37128), done.
remote: Total 107624 (delta 73393), reused 99851 (delta 67287)
Receiving objects: 100% (107624/107624), 69.74 MiB | 483 KiB/s, done.
Resolving deltas: 100% (73393/73393), done.
</literallayout></para>
<para>For another example of how to set up your own local Git repositories see this
remote: Counting objects: 116882, done.
remote: Compressing objects: 100% (35987/35987), done.
remote: Total 116882 (delta 80651), reused 113045 (delta 77578)
Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
Resolving deltas: 100% (80651/80651), done. </literallayout></para>
<para>For another example of how to set up your own local Git repositories, see this
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
wiki page</ulink>, which describes how to create both <filename>poky</filename>
and <filename>meta-intel</filename> Git repositories.</para></listitem>
</itemizedlist></para></listitem>
<listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>
If you are going to be making modifications to a supported Linux Yocto kernel you
need to get set up so that you can edit local copies of the source.
If you are going to be making modifications to a supported Linux Yocto kernel, you
need to establish local copies of the source.
This setup involves creating a bare clone of the Linux Yocto kernel and then cloning
that repository.
You can create the bare clone and the copy of the bare clone anywhere you like.
For simplicity, it is recommended that you create these structures outside of the
Yocto Project files Git repository.</para>
Yocto Project files' Git repository.</para>
<para>As an example, the following transcript shows how to create the bare clone
of the <filename>linux-yocto-3.0</filename> kernel and then create a copy of
of the <filename>linux-yocto-3.0-1.1.x</filename> kernel and then create a copy of
that clone.
<note>If you currently have a local Linux Yocto kernel Git repository, you can
reference this local repository rather than the upstream Git repository as
<note>When you have a local Linux Yocto kernel Git repository, you can
reference that repository rather than the upstream Git repository as
part of the <filename>clone</filename> command.
Doing so can speed up the process.</note>
The bare clone is named <filename>linux-yocto-3.0.git</filename>, while the
copy is named <filename>linux-yocto-3.0</filename>:
In the following example, the bare clone is named
<filename>linux-yocto-3.0-1.1.x.git</filename>, while the
copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>:
<literallayout class='monospaced'>
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0 linux-yocto-3.0.git
Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0.git/
remote: Counting objects: 1886034, done.
remote: Compressing objects: 100% (314326/314326), done.
remote: Total 1886034 (delta 1570200), reused 1870337 (delta 1554798)
Receiving objects: 100% (1886034/1886034), 401.51 MiB | 3.27 MiB/s, done.
Resolving deltas: 100% (1570200/1570200), done.
$ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
remote: Counting objects: 2259181, done.
remote: Compressing objects: 100% (373259/373259), done.
remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
Resolving deltas: 100% (1892638/1892638), done.
</literallayout></para>
<para>Now create a clone of the bare clone just created:
<literallayout class='monospaced'>
$ git clone linux-yocto-3.0.git linux-yocto-3.0
Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0/.git/
Checking out files: 100% (35188/35188), done.
$ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
Checking out files: 100% (36898/36898), done.
</literallayout></para></listitem>
<listitem id='poky-extras-repo'><para><emphasis>
The <filename>poky-extras</filename> Git Repository</emphasis>:
The <filename>poky-extras</filename> Git repository contains metadata needed to
build the kernel image.
In particular, it contains the kernel <filename>.bbappend</filename> files that you
edit to point to your locally modified kernel source files and to build kernel
edit to point to your locally modified kernel source files and to build the kernel
image.
Pointing to these local files is much more efficient than requiring a download of the
source files from upstream each time you make changes to the kernel.</para>
@ -160,14 +159,14 @@
$ cd ~/poky
$ git clone git://git.yoctoproject.org/poky-extras poky-extras
Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
remote: Counting objects: 531, done.
remote: Compressing objects: 100% (471/471), done.
remote: Total 531 (delta 138), reused 307 (delta 39)
Receiving objects: 100% (531/531), 517.86 KiB, done.
Resolving deltas: 100% (138/138), done.
remote: Counting objects: 561, done.
remote: Compressing objects: 100% (501/501), done.
remote: Total 561 (delta 159), reused 306 (delta 39)
Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
Resolving deltas: 100% (159/159), done.
</literallayout></para></listitem>
<listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis> The same considerations
exist for BSPs.
<listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis>
Similar considerations exist for BSPs.
You can get set up for BSP development one of two ways: tarball extraction or
with a local Git repository.
Regardless of the method you use, the Yocto Project uses the following BSP layer
@ -185,16 +184,16 @@
<itemizedlist>
<listitem><para><emphasis>Tarball Extraction:</emphasis> You can download any released
BSP tarball from the same
<ulink url='http://yoctoproject.org/download'>download site</ulink>.
Once you have the tarball just extract it into a directory of your choice.
<ulink url='http://yoctoproject.org/download'>download site</ulink> used
to get the Yocto Project release.
Once you have the tarball, just extract it into a directory of your choice.
Again, this method just produces a snapshot of the BSP layer in the form
of a hierarchical directory structure.</para></listitem>
<listitem><para><emphasis>Git Repository Method:</emphasis> If you are working
with a <filename>poky</filename> Git repository you should also set up a
with a Yocto Project files Git repository, you should also set up a
<filename>meta-intel</filename> Git repository.
Typically, you set up the <filename>meta-intel</filename> Git repository inside
the <filename>poky</filename> Git repository.</para>
the Yocto Project files Git repository.</para>
<para>For example, the following transcript shows the steps to clone the
<filename>meta-intel</filename>
Git repository inside the <filename>poky</filename> Git repository.
@ -202,24 +201,23 @@
$cd poky
$ git clone git://git.yoctoproject.org/meta-intel.git
Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
remote: Counting objects: 1325, done.
remote: Compressing objects: 100% (1078/1078), done.
remote: Total 1325 (delta 546), reused 85 (delta 27)
Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
Resolving deltas: 100% (546/546), done.
remote: Counting objects: 3279, done.
remote: Compressing objects: 100% (2708/2708), done.
remote: Total 3279 (delta 1761), reused 194 (delta 105)
Receiving objects: 100% (3279/3279), 1.75 MiB | 377 KiB/s, done.
Resolving deltas: 100% (1761/1761), done.
</literallayout></para>
<para>The same
<ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
wiki page</ulink> referenced earlier covers how to
set up the <filename>meta-intel</filename> Git repository.</para></listitem>
</itemizedlist></para></listitem>
<listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis> If you are developing
applications using the
Eclipse Integrated Development Environment (IDE) you will need this plug-in.
applications using the Eclipse Integrated Development Environment (IDE),
you will need this plug-in.
See the
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>
Setting up the Eclipse IDE</ulink> section in the Yocto Application Development Toolkit (ADT)
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
section in the Yocto Application Development Toolkit (ADT)
Users Guide for more information.</para></listitem>
</itemizedlist>
</para>
@ -231,8 +229,8 @@
<para>
The build process creates an entire Linux distribution, including the toolchain, from source.
For more information on this topic, see the
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#building-image'>
Building an Image</ulink> section in the Yocto Project Quick Start.
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
section in the Yocto Project Quick Start.
</para>
<para>
@ -244,7 +242,7 @@
script.</para></listitem>
<listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set
up how you want it.
This file defines the target machine architecture and and other build options.</para></listitem>
This file defines the target machine architecture and other build options.</para></listitem>
<listitem><para>Build the image using the BitBake command.
If you want information on Bitbake, see the user manual at
<ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem>
@ -260,16 +258,17 @@
<para>
Another option you have to get started is to use pre-built binaries.
This scenario is ideal for developing software applications to run on your target hardware.
To do this you need to install the stand-alone Yocto toolchain tarball and then download the
pre-built kernel that you will boot using the QEMU emulator.
Next, you must download the filesystem for your target machines architecture.
Finally, you set up the environment to emulate the hardware then start the emulator.
To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and
then download the pre-built kernel that you will boot in the QEMU emulator.
Next, you must download and extract the target root filesystem for your target
machines architecture.
Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
</para>
<para>
You can find details on all these steps in the
<ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
Using Pre-Built Binaries and QEMU</ulink> section in the Yocto Project Quick Start.
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
section of the Yocto Project Quick Start.
</para>
</section>
</chapter>

View File

@ -30,14 +30,18 @@
<revhistory>
<revision>
<revnumber>1.1</revnumber>
<date>TBD 2011</date>
<revremark>This revision is the initial document draft and corresponds with
the Yocto Project 1.1 Release.</revremark>
<date>6 October 2011</date>
<revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1.1</revnumber>
<date>15 March 2012</date>
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>2010-2011</year>
<year>2010-2012</year>
<holder>Linux Foundation</holder>
</copyright>
@ -52,7 +56,7 @@
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 96 KiB

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 61 KiB

After

Width:  |  Height:  |  Size: 60 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 25 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

View File

@ -46,12 +46,14 @@
the baseline kernel is the most stable official release.</para></listitem>
<listitem><para>Include major technological features as part of Yocto Project's up-rev
strategy.</para></listitem>
<listitem><para>Present a Git tree, that just like the upstream kernel.org tree, has a
clear and continuous history.</para></listitem>
<listitem><para>Present a kernel Git repository that, similar to the upstream
<filename>kernel.org</filename> tree,
has a clear and continuous history.</para></listitem>
<listitem><para>Deliver a key set of supported kernel types, where each type is tailored
to a specific use case (i.e. networking, consumer, devices, and so forth).</para></listitem>
<listitem><para>Employ a Git branching strategy that from a customer's point of view
results in a linear path from the baseline kernel.org, through a select group of features and
to a specific use case (e.g. networking, consumer, devices, and so forth).</para></listitem>
<listitem><para>Employ a Git branching strategy that, from a developer's point of view,
results in a linear path from the baseline <filename>kernel.org</filename>,
through a select group of features and
ends with their BSP-specific commits.</para></listitem>
</itemizedlist>
</para>
@ -60,27 +62,29 @@
<section id='kernel-big-picture'>
<title>Yocto Project Kernel Development and Maintenance Overview</title>
<para>
Yocto Project kernel, like other kernels, is based off the Linux kernel release
The Yocto Project kernel, like other kernels, is based off the Linux kernel release
from <ulink url='http://www.kernel.org'></ulink>.
At the beginning of our major development cycle, we choose our Yocto Project kernel
based on factors like release timing, the anticipated release timing of "final" (i.e. non "rc")
upstream kernel.org versions, and Yocto Project feature requirements.
Typically this will be a kernel that is in the
final stages of development by the community (i.e. still in the release
candidate or "rc" phase) and not yet a final release.
But by being in the final stages of external development, we know that the
kernel.org final release will clearly land within the early stages of
At the beginning of a major development cycle, the Yocto Project team
chooses its Yocto Project kernel
based on factors like release timing, the anticipated release timing of final
upstream <filename>kernel.org</filename> versions, and Yocto Project feature requirements.
Typically, the kernel chosen is in the
final stages of development by the community.
In other words, the kernel is in the release
candidate or "rc" phase and not yet a final release.
But, by being in the final stages of external development, the team knows that the
<filename>kernel.org</filename> final release will clearly be within the early stages of
the Yocto Project development window.
</para>
<para>
This balance allows us to deliver the most up-to-date kernel
as possible, while still ensuring that we have a stable official release as
our baseline kernel version.
This balance allows the team to deliver the most up-to-date kernel
as possible, while still ensuring that the team has a stable official release as
the baseline kernel version.
</para>
<para>
The ultimate source for the Yocto Project kernel is a released kernel
from kernel.org.
In addition to a foundational kernel from kernel.org the released
from <filename>kernel.org</filename>.
In addition to a foundational kernel from <filename>kernel.org</filename>, the released
Yocto Project kernel contains a mix of important new mainline
developments, non-mainline developments (when there is no alternative),
Board Support Package (BSP) developments,
@ -88,37 +92,21 @@
These additions result in a commercially released Yocto Project kernel that caters
to specific embedded designer needs for targeted hardware.
</para>
<!-- <para>
The following figure represents the overall place the Yocto Project kernel fills.
</para>
<para>
<imagedata fileref="figures/kernel-big-picture.png" width="6in" depth="6in" align="center" scale="100" />
</para>
<para>
In the figure the ultimate source for the Yocto Project kernel is a released kernel
from kernel.org.
In addition to a foundational kernel from kernel.org the commercially released
Yocto Project kernel contains a mix of important new mainline
developments, non-mainline developments, Board Support Package (BSP) developments,
and custom features.
These additions result in a commercially released Yocto Project kernel that caters
to specific embedded designer needs for targeted hardware.
</para> -->
<para>
Once a Yocto Project kernel is officially released the Yocto Project team goes into
their next development cycle, or "uprev" cycle while continuing maintenance on the
Once a Yocto Project kernel is officially released, the Yocto Project team goes into
their next development cycle, or "uprev" cycle, while still continuing maintenance on the
released kernel.
It is important to note that the most sustainable and stable way
to include feature development upstream is through a kernel uprev process.
Back-porting of hundreds of individual fixes and minor features from various
kernel versions is not sustainable and can easily compromise quality.
Back-porting hundreds of individual fixes and minor features from various
kernel versions is not sustainable and can easily compromise quality.
</para>
<para>
During the uprev cycle, the Yocto Project team uses an ongoing analysis of
kernel development, BSP support, and release timing to select the best
possible kernel.org version.
possible <filename>kernel.org</filename> version.
The team continually monitors community kernel
development to look for significant features of interest.
<!-- The illustration depicts this by showing the team looking back to kernel.org for new features,
BSP features, and significant bug fixes. -->
The team does consider back-porting large features if they have a significant advantage.
User or community demand can also trigger a back-port or creation of new
functionality in the Yocto Project baseline kernel during the uprev cycle.
@ -130,7 +118,7 @@
It is the Yocto Project team's policy to not back-port minor features to the released kernel.
They only consider back-porting significant technological jumps - and, that is done
after a complete gap analysis.
The reason for this policy is that simply back-porting any small to medium sized change
The reason for this policy is that back-porting any small to medium sized change
from an evolving kernel can easily create mismatches, incompatibilities and very
subtle errors.
</para>
@ -163,18 +151,23 @@
As mentioned earlier, a key goal of Yocto Project is to present the developer with
a kernel that has a clear and continuous history that is visible to the user.
The architecture and mechanisms used achieve that goal in a manner similar to the
upstream kernel.org.
upstream <filename>kernel.org</filename>.
</para>
<para>
You can think of the Yocto Project kernel as consisting of a baseline kernel with
added features logically structured on top of the baseline.
The features are tagged and organized by way of a branching strategy implemented by the
source code manager (SCM) Git.
source code manager (SCM) Git.
For information on Git as applied to the Yocto Project, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
Yocto Project Development Manual</ulink>.
</para>
<para>
The result is that the user has the ability to see the added features and
the commits that make up those features.
In addition to being able to see added features, the user can also view the history of what
made up the baseline kernel as well.
made up the baseline kernel.
</para>
<para>
The following illustration shows the conceptual Yocto Project kernel.
@ -183,18 +176,20 @@
<imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
</para>
<para>
In the illustration, the "kernel.org Branch Point" marks the specific spot (or release) from
which the Yocto Project kernel is created. From this point "up" in the tree features and
differences are organized and tagged.
In the illustration, the "<filename>kernel.org</filename> Branch Point"
marks the specific spot (or release) from
which the Yocto Project kernel is created.
From this point "up" in the tree, features and differences are organized and tagged.
</para>
<para>
The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
type and BSP that is organized further up the tree. Placing these common features in the
type and BSP that is organized further up the tree.
Placing these common features in the
tree this way means features don't have to be duplicated along individual branches of the
structure.
</para>
<para>
From the Yocto Project Baseline Kernel branch points represent specific functionality
From the Yocto Project Baseline Kernel, branch points represent specific functionality
for individual BSPs as well as real-time kernels.
The illustration represents this through three BSP-specific branches and a real-time
kernel branch.
@ -209,8 +204,9 @@
kernel as they apply to a given BSP.
</para>
<para>
The resulting tree structure presents a clear path of markers (or branches) to the user
that for all practical purposes is the kernel needed for any given set of requirements.
The resulting tree structure presents a clear path of markers (or branches) to the
developer that, for all practical purposes, is the kernel needed for any given set
of requirements.
</para>
</section>
@ -221,50 +217,52 @@
no longer shared and thus, needs to be isolated.
For example, board-specific incompatibilities would require different functionality
and would require a branch to separate the features.
Likewise, for specific kernel features the same branching strategy is used.
Likewise, for specific kernel features, the same branching strategy is used.
</para>
<para>
This branching strategy results in a tree that has features organized to be specific
for particular functionality, single kernel types, or a subset of kernel types.
This strategy results in not having to store the same feature twice internally in the
tree.
Rather we store the unique differences required to apply the feature onto the kernel type
in question.
This strategy also results in not having to store the same feature twice
internally in the tree.
Rather, the kernel team stores the unique differences required to apply the
feature onto the kernel type in question.
<note>
The Yocto Project team strives to place features in the tree such that they can be
shared by all boards and kernel types where possible.
However, during development cycles or when large features are merged,
the team cannot always follow this practice.
In those cases, the team uses isolated branches to merge features.
</note>
</para>
<note><para>
The Yocto Project team strives to place features in the tree such that they can be
shared by all boards and kernel types where possible.
However, during development cycles or when large features are merged this practice
cannot always be followed.
In those cases isolated branches are used for feature merging.
</para></note>
<para>
BSP-specific code additions are handled in a similar manner to kernel-specific additions.
Some BSPs only make sense given certain kernel types.
So, for these types, we create branches off the end of that kernel type for all
So, for these types, the team creates branches off the end of that kernel type for all
of the BSPs that are supported on that kernel type.
From the perspective of the tools that create the BSP branch, the BSP is really no
different than a feature.
Consequently, the same branching strategy applies to BSPs as it does to features.
So again, rather than store the BSP twice, only the unique differences for the BSP across
the supported multiple kernels are uniquely stored.
So again, rather than store the BSP twice, the team only stores the unique
differences for the BSP across the supported multiple kernels.
</para>
<para>
While this strategy can result in a tree with a significant number of branches, it is
important to realize that from the user's point of view, there is a linear
path that travels from the baseline kernel.org, through a select group of features and
ends with their BSP-specific commits.
important to realize that from the developer's point of view, there is a linear
path that travels from the baseline <filename>kernel.org</filename>, through a select
group of features and ends with their BSP-specific commits.
In other words, the divisions of the kernel are transparent and are not relevant
to the developer on a day-to-day basis.
From the user's perspective, this is the "master" branch.
They do not need not be aware of the existence of any other branches at all.
Of course there is value in the existence of these branches
From the developer's perspective, this path is the "master" branch.
The developer does not need not be aware of the existence of any other branches at all.
Of course, there is value in the existence of these branches
in the tree, should a person decide to explore them.
For example, a comparison between two BSPs at either the commit level or at the line-by-line
code diff level is now a trivial operation.
code <filename>diff</filename> level is now a trivial operation.
</para>
<para>
Working with the kernel as a structured tree follows recognized community best practices.
In particular, the kernel as shipped with the product should be
considered an 'upstream source' and viewed as a series of
In particular, the kernel as shipped with the product, should be
considered an "upstream source" and viewed as a series of
historical and documented modifications (commits).
These modifications represent the development and stabilization done
by the Yocto Project kernel development team.
@ -273,7 +271,7 @@
Because commits only change at significant release points in the product life cycle,
developers can work on a branch created
from the last relevant commit in the shipped Yocto Project kernel.
As mentioned previously, the structure is transparent to the user
As mentioned previously, the structure is transparent to the developer
because the kernel tree is left in this state after cloning and building the kernel.
</para>
</section>
@ -281,20 +279,26 @@
<section id='source-code-manager-git'>
<title>Source Code Manager - Git</title>
<para>
The Source Code Manager (SCM) is Git and it is the obvious mechanism for meeting the
previously mentioned goals.
Not only is it the SCM for kernel.org but Git continues to grow in popularity and
supports many different work flows, front-ends and management techniques.
The Source Code Manager (SCM) is Git.
This SCM is the obvious mechanism for meeting the previously mentioned goals.
Not only is it the SCM for <filename>kernel.org</filename> but,
Git continues to grow in popularity and supports many different work flows,
front-ends and management techniques.
</para>
<para>
You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
Also, the Yocto Project Development manual has an introduction to Git and describes a
minimal set of commands that allow you to be functional with Git.
You can also get an introduction to Git as it applies to the Yocto Project in the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#git'>Git</ulink>"
section in <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
Yocto Project Development Manual</ulink>.
This section overviews Git and describes a minimal set of commands that allow you to be
functional using Git.
<note>
You can use as much, or as little, of what Git has to offer to accomplish what
you need for your project.
You do not have to be a "Git Master" in order to use it with the Yocto Project.
</note>
</para>
<note><para>
It should be noted that you can use as much, or as little, of what Git has to offer
as is appropriate to your project.
</para></note>
</section>
</section>
@ -307,17 +311,19 @@
present a simplified view of the kernel for ease of use.
</para>
<para>
The fundamental properties of the tools that manage and construct the
Yocto Project kernel are:
Fundamentally, the kernel tools that manage and construct the
Yocto Project kernel accomplish the following:
<itemizedlist>
<listitem><para>Group patches into named, reusable features.</para></listitem>
<listitem><para>Allow top down control of included features.</para></listitem>
<listitem><para>Bind kernel configuration to kernel patches and features.</para></listitem>
<listitem><para>Allow top-down control of included features.</para></listitem>
<listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem>
<listitem><para>Present a seamless Git repository that blends Yocto Project value
with the kernel.org history and development.</para></listitem>
with the <filename>kernel.org</filename> history and development.</para></listitem>
</itemizedlist>
</para>
<!--<para>
WRITER NOTE: Put this in for post 1.1 if possible:
The tools that construct a kernel tree will be discussed later in this
document. The following tools form the foundation of the Yocto Project
kernel toolkit:

View File

@ -20,17 +20,20 @@
on its history, organization, benefits, and use.
The manual consists of two sections:
<itemizedlist>
<listitem><para>Concepts - Describes concepts behind the kernel.
<listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind the kernel.
You will understand how the kernel is organized and why it is organized in
the way it is. You will understand the benefits of the kernel's organization
and the mechanisms used to work with the kernel and how to apply it in your
design process.</para></listitem>
<listitem><para>Using the Kernel - Describes best practices and "how-to" information
that lets you put the kernel to practical use. Some examples are "How to Build a
Project Specific Tree", "How to Examine Changes in a Branch", and "Saving Kernel
Modifications."</para></listitem>
<listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices
and "how-to" information
that lets you put the kernel to practical use.
Some examples are "How to Build a
Project Specific Tree", "How to Examine Changes in a Branch", and "How to
Save Kernel Modifications."</para></listitem>
</itemizedlist>
</para>
<para>
For more information on the kernel, see the following links:
<itemizedlist>
@ -38,10 +41,19 @@
<listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
<listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem>
</itemizedlist>
<para>
You can find more information on Yocto Project by visiting the website at
</para>
<para>
For more discussion on the Yocto Project kernel, you can also see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>",
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>", and
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>" sections all in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
</para>
<para>
For general information on the Yocto Project, visit the website at
<ulink url='http://www.yoctoproject.org'></ulink>.
</para>
</para>
</section>

File diff suppressed because it is too large Load Diff

View File

@ -31,23 +31,32 @@
<revision>
<revnumber>0.9</revnumber>
<date>24 November 2010</date>
<revremark>This revision is the initial document draft and corresponds with
the Yocto Project 0.9 Release.</revremark>
<revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>6 April 2011</date>
<revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.0.1</revnumber>
<date>23 May 2011</date>
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>6 October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1.1</revnumber>
<date>15 March 2012</date>
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>2010-2011</year>
<year>2010-2012</year>
<holder>Linux Foundation</holder>
</copyright>
@ -59,7 +68,7 @@
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and
<ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/kernel-manual/kernel-manual.html'>
The Yocto Project Kernel Architecture and Use Manual</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.

View File

@ -91,9 +91,9 @@
with other plug-ins installed into the Eclipse IDE.
Once you have your environment setup you need to configure the Eclipse plug-in.
For information on how to install and configure the Eclipse plug-in, see the
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#adt-eclipse'>
"Working Within Eclipse"</ulink> chapter in the
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>
"Application Development Toolkit (ADT) User's Guide."</ulink>
</para>
</section>
@ -102,7 +102,7 @@
<title>External Development Using the QEMU Emulator</title>
<para>
Running Poky QEMU images is covered in the
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
<ulink url="http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html">
Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
</para>
<para>

View File

@ -3,13 +3,14 @@
<chapter id='extendpoky'>
<title>Extending the Yocto Project</title>
<title>Common Tasks</title>
<para>
This chapter provides information about how to extend the functionality
already present in the Yocto Project.
The chapter also documents standard tasks such as adding new
This chapter describes standard tasks such as adding new
software packages, extending or customizing images or porting the Yocto Project to
new hardware (adding a new machine).
The chapter also describes ways to modify package source code, combine multiple
versions of library files into a single image, track license changes, and handle
a package name alias.
Finally, the chapter contains advice about how to make changes to the
Yocto Project to achieve the best results.
</para>
@ -79,7 +80,8 @@
By default, the <filename>helloworld</filename>, <filename>helloworld-dbg</filename>,
and <filename>helloworld-dev</filename> packages are built.
For information on how to customize the packaging process, see the
<link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link> section.
"<link linkend='splitting-an-application-into-multiple-packages'>Splitting an Application
into Multiple Packages</link>" section.
</para>
</section>
@ -174,8 +176,8 @@
</para>
</section>
<section id='usingpoky-extend-addpkg-files'>
<title>Controlling Package Content</title>
<section id='splitting-an-application-into-multiple-packages'>
<title>Splitting an Application into Multiple Packages</title>
<para>
You can use the variables <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> and
@ -222,6 +224,59 @@
</para>
</section>
<section id='including-static-library-files'>
<title>Including Static Library Files</title>
<para>
If you are building a library and the library offers static linking, you can control
which static library files (<filename>*.a</filename> files) get included in the
built library.
</para>
<para>
The <filename>PACKAGES</filename> and <filename>FILES_*</filename> variables in the
<filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
by the <filename>do_install</filename> task are packaged.
By default, the <filename>PACKAGES</filename> variable contains
<filename>${PN}-staticdev</filename>, which includes all static library files.
<note>
Previously released versions of the Yocto Project defined the static library files
through <filename>${PN}-dev</filename>.
</note>
Following, is part of the BitBake configuration file.
You can see where the static library files are defined:
<literallayout class='monospaced'>
PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
PACKAGES_DYNAMIC = "${PN}-locale-*"
FILES = ""
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
${base_bindir}/* ${base_sbindir}/* \
${base_libdir}/*${SOLIBS} \
${datadir}/${BPN} ${libdir}/${BPN}/* \
${datadir}/pixmaps ${datadir}/applications \
${datadir}/idl ${datadir}/omf ${datadir}/sounds \
${libdir}/bonobo/servers"
FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
${datadir}/gnome/help"
SECTION_${PN}-doc = "doc"
FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
${datadir}/aclocal ${base_libdir}/*.o"
SECTION_${PN}-dev = "devel"
ALLOW_EMPTY_${PN}-dev = "1"
RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
</literallayout>
</para>
</section>
<section id='usingpoky-extend-addpkg-postinstalls'>
<title>Post Install Scripts</title>
@ -303,7 +358,7 @@
It is important to use the correct names of packages in the
<filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename> variable.
You must use the OpenEmbedded notation and not the Debian notation for the names
(e.g. <filename>glibc-dev</filename> instead of <filename>libc6-dev</filename>).
(e.g. <filename>eglibc-dev</filename> instead of <filename>libc6-dev</filename>).
</para>
<para>
@ -470,16 +525,16 @@
The information covers adding machines similar to those the Yocto Project already supports.
Although well within the capabilities of the Yocto Project, adding a totally new architecture
might require
changes to <filename>gcc/glibc</filename> and to the site information, which is
changes to <filename>gcc/eglibc</filename> and to the site information, which is
beyond the scope of this manual.
</para>
<para>
For a complete example that shows how to add a new machine to the Yocto Project,
see the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
BSP Development Example</ulink> in Appendix A of
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
@ -604,6 +659,412 @@
</section>
</section>
<section id="usingpoky-modifing-packages">
<title>Modifying Package Source Code</title>
<para>
Although the Yocto Project is usually used to build software, you can use it to modify software.
</para>
<para>
During a build, source is available in the
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
The actual location depends on the type of package and the architecture of the target device.
For a standard recipe not related to
<filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
<filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
For target device-dependent packages, you should use the <filename>MACHINE</filename>
variable instead of
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>
in the directory name.
</para>
<tip>
Be sure the package recipe sets the
<filename><link linkend='var-S'>S</link></filename> variable to something
other than the standard <filename>WORKDIR/PN-PV/</filename> value.
</tip>
<para>
After building a package, you can modify the package source code without problems.
The easiest way to test your changes is by calling the
<filename>compile</filename> task as shown in the following example:
<literallayout class='monospaced'>
$ bitbake -c compile -f NAME_OF_PACKAGE
</literallayout>
</para>
<para>
The <filename>-f</filename> or <filename>--force</filename>
option forces re-execution of the specified task.
You can call other tasks this way as well.
But note that all the modifications in
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
are gone once you execute <filename>-c clean</filename> for a package.
</para>
</section>
<section id="usingpoky-modifying-packages-quilt">
<title>Modifying Package Source Code with Quilt</title>
<para>
By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
to manage patches in the <filename>do_patch</filename> task.
This is a powerful tool that you can use to track all modifications to package sources.
</para>
<para>
Before modifying source code, it is important to notify Quilt so it can track the changes
into the new patch file:
<literallayout class='monospaced'>
$ quilt new NAME-OF-PATCH.patch
</literallayout>
</para>
<para>
After notifying Quilt, add all modified files into that patch:
<literallayout class='monospaced'>
$ quilt add file1 file2 file3
</literallayout>
</para>
<para>
You can now start editing.
Once you are done editing, you need to use Quilt to generate the final patch that
will contain all your modifications.
<literallayout class='monospaced'>
$ quilt refresh
</literallayout>
</para>
<para>
You can find the resulting patch file in the
<filename>patches/</filename> subdirectory of the source
(<filename><link linkend='var-S'>S</link></filename>) directory.
For future builds, you should copy the patch into the Yocto Project metadata and add it into the
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.
Here is an example:
<literallayout class='monospaced'>
SRC_URI += "file://NAME-OF-PATCH.patch"
</literallayout>
</para>
<para>
Finally, don't forget to 'bump' the
<filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since
the resulting packages have changed.
</para>
</section>
<section id="building-multiple-architecture-libraries-into-one-image">
<title>Combining Multiple Versions of Library Files into One Image</title>
<para>
The build system offers the ability to build libraries with different
target optimizations or architecture formats and combine these together
into one system image.
You can link different binaries in the image
against the different libraries as needed for specific use cases.
This feature is called "Multilib."
</para>
<para>
An example would be where you have most of a system compiled in 32-bit
mode using 32-bit libraries, but you have something large, like a database
engine, that needs to be a 64-bit application and use 64-bit libraries.
Multilib allows you to get the best of both 32-bit and 64-bit libraries.
</para>
<para>
While the Multilib feature is most commonly used for 32 and 64-bit differences,
the approach the build system uses facilitates different target optimizations.
You could compile some binaries to use one set of libraries and other binaries
to use other different sets of libraries.
The libraries could differ in architecture, compiler options, or other
optimizations.
</para>
<para>
This section overviews the Multilib process only.
For more details on how to implement Multilib, see the
<ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki
page.
</para>
<section id='preparing-to-use-multilib'>
<title>Preparing to use Multilib</title>
<para>
User-specific requirements drive the Multilib feature,
Consequently, there is no one "out-of-the-box" configuration that likely
exists to meet your needs.
</para>
<para>
In order to enable Multilib, you first need to ensure your recipe is
extended to support multiple libraries.
Many standard recipes are already extended and support multiple libraries.
You can check in the <filename>meta/conf/multilib.conf</filename>
configuration file in the Yocto Project files directory to see how this is
done using the <filename>BBCLASSEXTEND</filename> variable.
Eventually, all recipes will be covered and this list will be unneeded.
</para>
<para>
For the most part, the Multilib class extension works automatically to
extend the package name from <filename>${PN}</filename> to
<filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
is the particular multilib (e.g. "lib32-" or "lib64-").
Standard variables such as <filename>DEPENDS</filename>,
<filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>,
<filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and
<filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
If you are extending any manual code in the recipe, you can use the
<filename>${MLPREFIX}</filename> variable to ensure those names are extended
correctly.
This automatic extension code resides in <filename>multilib.bbclass</filename>.
</para>
</section>
<section id='using-multilib'>
<title>Using Multilib</title>
<para>
After you have set up the recipes, you need to define the actual
combination of multiple libraries you want to build.
You accomplish this through your <filename>local.conf</filename>
configuration file in the Yocto Project build directory.
An example configuration would be as follows:
<literallayout class='monospaced'>
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
MULTILIB_IMAGE_INSTALL = "lib32-connman"
</literallayout>
This example enables an
additional library named <filename>lib32</filename> alongside the
normal target packages.
When combining these "lib32" alternatives, the example uses "x86" for tuning.
For information on this particular tuning, see
<filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
</para>
<para>
The example then includes <filename>lib32-connman</filename>
in all the images, which illustrates one method of including a
multiple library dependency.
You can use a normal image build to include this dependency,
for example:
<literallayout class='monospaced'>
$ bitbake core-image-sato
</literallayout>
You can also build Multilib packages specifically with a command like this:
<literallayout class='monospaced'>
$ bitbake lib32-connman
</literallayout>
</para>
</section>
<section id='additional-implementation-details'>
<title>Additional Implementation Details</title>
<para>
Different packaging systems have different levels of native Multilib
support.
For the RPM Package Management System, the following implementation details
exist:
<itemizedlist>
<listitem><para>A unique architecture is defined for the Multilib packages,
along with creating a unique deploy folder under
<filename>tmp/deploy/rpm</filename> in the Yocto
Project build directory.
For example, consider <filename>lib32</filename> in a
<filename>qemux86-64</filename> image.
The possible architectures in the system are "all", "qemux86_64",
"lib32_qemux86_64", and "lib32_x86".</para></listitem>
<listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from
<filename>${PN}</filename> during RPM packaging.
The naming for a normal RPM package and a Multilib RPM package in a
<filename>qemux86-64</filename> system resolves to something similar to
<filename>bash-4.1-r2.x86_64.rpm</filename> and
<filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
</para></listitem>
<listitem><para>When installing a Multilib image, the RPM backend first
installs the base image and then installs the Multilib libraries.
</para></listitem>
<listitem><para>The build system relies on RPM to resolve the identical files in the
two (or more) Multilib packages.</para></listitem>
</itemizedlist>
</para>
<para>
For the IPK Package Management System, the following implementation details exist:
<itemizedlist>
<listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from
<filename>${PN}</filename> during IPK packaging.
The naming for a normal RPM package and a Multilib IPK package in a
<filename>qemux86-64</filename> system resolves to something like
<filename>bash_4.1-r2.x86_64.ipk</filename> and
<filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
</para></listitem>
<listitem><para>The IPK deploy folder is not modified with
<filename>${MLPREFIX}</filename> because packages with and without
the Multilib feature can exist in the same folder due to the
<filename>${PN}</filename> differences.</para></listitem>
<listitem><para>IPK defines a sanity check for Multilib installation
using certain rules for file comparison, overridden, etc.
</para></listitem>
</itemizedlist>
</para>
</section>
</section>
<section id="usingpoky-configuring-LIC_FILES_CHKSUM">
<title>Tracking License Changes</title>
<para>
The license of an upstream project might change in the future. In order to prevent these changes
going unnoticed, the Yocto Project provides a
<filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
variable to track changes to the license text. The checksums are validated at the end of the
configure step, and if the checksums do not match, the build will fail.
</para>
<section id="usingpoky-specifying-LIC_FILES_CHKSUM">
<title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
<para>
The <filename>LIC_FILES_CHKSUM</filename>
variable contains checksums of the license text in the source code for the recipe.
Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
<literallayout class='monospaced'>
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
file://licfile2.txt;endline=50;md5=zzzz \
..."
</literallayout>
</para>
<para>
The Yocto Project uses the
<filename><link linkend='var-S'>S</link></filename> variable as the
default directory used when searching files listed in
<filename>LIC_FILES_CHKSUM</filename>.
The previous example employs the default directory.
</para>
<para>
You can also use relative paths as shown in the following example:
<literallayout class='monospaced'>
LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
md5=bb14ed3c4cda583abc85401304b5cd4e"
LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
</literallayout>
</para>
<para>
In this example, the first line locates a file in
<filename><link linkend='var-S'>S</link>/src/ls.c</filename>.
The second line refers to a file in
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
of <filename>S</filename>.
</para>
<para>
Note that this variable is mandatory for all recipes, unless the
<filename>LICENSE</filename> variable is set to "CLOSED".
</para>
</section>
<section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
<title>Explanation of Syntax</title>
<para>
As mentioned in the previous section, the
<filename>LIC_FILES_CHKSUM</filename> variable lists all the
important files that contain the license text for the source code.
It is possible to specify a checksum for an entire file, or a specific section of a
file (specified by beginning and ending line numbers with the "beginline" and "endline"
parameters, respectively).
The latter is useful for source files with a license notice header,
README documents, and so forth.
If you do not use the "beginline" parameter, then it is assumed that the text begins on the
first line of the file.
Similarly, if you do not use the "endline" parameter, it is assumed that the license text
ends with the last line of the file.
</para>
<para>
The "md5" parameter stores the md5 checksum of the license text.
If the license text changes in any way as compared to this parameter
then a mismatch occurs.
This mismatch triggers a build failure and notifies the developer.
Notification allows the developer to review and address the license text changes.
Also note that if a mismatch occurs during the build, the correct md5
checksum is placed in the build log and can be easily copied to the recipe.
</para>
<para>
There is no limit to how many files you can specify using the
<filename>LIC_FILES_CHKSUM</filename> variable.
Generally, however, every project requires a few specifications for license tracking.
Many projects have a "COPYING" file that stores the license information for all the source
code files.
This practice allows you to just track the "COPYING" file as long as it is kept up to date.
</para>
<tip>
If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
error and displays the correct "md5" parameter value during the build.
The correct parameter is also captured in the build log.
</tip>
<tip>
If the whole file contains only license text, you do not need to use the "beginline" and
"endline" parameters.
</tip>
</section>
</section>
<section id="usingpoky-configuring-DISTRO_PN_ALIAS">
<title>Handling a Package Name Alias</title>
<para>
Sometimes a package name you are using might exist under an alias or as a similarly named
package in a different distribution.
The Yocto Project implements a <filename>distro_check</filename>
task that automatically connects to major distributions
and checks for these situations.
If the package exists under a different name in a different distribution, you get a
<filename>distro_check</filename> mismatch.
You can resolve this problem by defining a per-distro recipe name alias using the
<filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
</para>
<para>
Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
variable:
<literallayout class='monospaced'>
DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
distro2=package_name_alias2 \
distro3=package_name_alias3 \
..."
</literallayout>
</para>
<para>
If you have more than one distribution alias, separate them with a space.
Note that the Yocto Project currently automatically checks the
Fedora, OpenSuSE, Debian, Ubuntu,
and Mandriva distributions for source package recipes without having to specify them
using the <filename>DISTRO_PN_ALIAS</filename> variable.
For example, the following command generates a report that lists the Linux distributions
that include the sources for each of the Yocto Project recipes.
<literallayout class='monospaced'>
$ bitbake world -f -c distro_check
</literallayout>
The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
file found in the Yocto Project files area.
</para>
</section>
<section id="usingpoky-changes">
<title>Making and Maintaining Changes</title>
<para>
@ -860,7 +1321,7 @@
Experience shows that buildbot is a good fit for this role.
What works well is to configure buildbot to make two types of builds:
incremental and full (from scratch).
See <ulink url='http://autobuilder.yoctoproject.org:8010'>the buildbot for the
See <ulink url='http://www.yoctoproject.org:8010'>the buildbot for the
Yocto Project</ulink> for an example implementation that uses buildbot.
</para>
@ -922,247 +1383,6 @@
</section>
</section>
<section id="usingpoky-modifing-packages">
<title>Modifying Package Source Code</title>
<para>
Although the Yocto Project is usually used to build software, you can use it to modify software.
</para>
<para>
During a build, source is available in the
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
The actual location depends on the type of package and the architecture of the target device.
For a standard recipe not related to
<filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
<filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
For target device-dependent packages, you should use the <filename>MACHINE</filename>
variable instead of
<filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>
in the directory name.
</para>
<tip>
Be sure the package recipe sets the
<filename><link linkend='var-S'>S</link></filename> variable to something
other than the standard <filename>WORKDIR/PN-PV/</filename> value.
</tip>
<para>
After building a package, you can modify the package source code without problems.
The easiest way to test your changes is by calling the
<filename>compile</filename> task as shown in the following example:
<literallayout class='monospaced'>
$ bitbake -c compile -f NAME_OF_PACKAGE
</literallayout>
</para>
<para>
The <filename>-f</filename> or <filename>--force</filename>
option forces re-execution of the specified task.
You can call other tasks this way as well.
But note that all the modifications in
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
are gone once you execute <filename>-c clean</filename> for a package.
</para>
</section>
<section id="usingpoky-modifying-packages-quilt">
<title>Modifying Package Source Code with Quilt</title>
<para>
By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
to manage patches in the <filename>do_patch</filename> task.
This is a powerful tool that you can use to track all modifications to package sources.
</para>
<para>
Before modifying source code, it is important to notify Quilt so it can track the changes
into the new patch file:
<literallayout class='monospaced'>
$ quilt new NAME-OF-PATCH.patch
</literallayout>
</para>
<para>
After notifying Quilt, add all modified files into that patch:
<literallayout class='monospaced'>
$ quilt add file1 file2 file3
</literallayout>
</para>
<para>
You can now start editing.
Once you are done editing, you need to use Quilt to generate the final patch that
will contain all your modifications.
<literallayout class='monospaced'>
$ quilt refresh
</literallayout>
</para>
<para>
You can find the resulting patch file in the
<filename>patches/</filename> subdirectory of the source
(<filename><link linkend='var-S'>S</link></filename>) directory.
For future builds, you should copy the patch into the Yocto Project metadata and add it into the
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.
Here is an example:
<literallayout class='monospaced'>
SRC_URI += "file://NAME-OF-PATCH.patch"
</literallayout>
</para>
<para>
Finally, don't forget to 'bump' the
<filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since
the resulting packages have changed.
</para>
</section>
<section id="usingpoky-configuring-LIC_FILES_CHKSUM">
<title>Tracking License Changes</title>
<para>
The license of an upstream project might change in the future. In order to prevent these changes
going unnoticed, the Yocto Project provides a
<filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
variable to track changes to the license text. The checksums are validated at the end of the
configure step, and if the checksums do not match, the build will fail.
</para>
<section id="usingpoky-specifying-LIC_FILES_CHKSUM">
<title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
<para>
The <filename>LIC_FILES_CHKSUM</filename>
variable contains checksums of the license text in the source code for the recipe.
Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
<literallayout class='monospaced'>
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
file://licfile2.txt;endline=50;md5=zzzz \
..."
</literallayout>
</para>
<para>
The Yocto Project uses the
<filename><link linkend='var-S'>S</link></filename> variable as the
default directory used when searching files listed in
<filename>LIC_FILES_CHKSUM</filename>.
The previous example employs the default directory.
</para>
<para>
You can also use relative paths as shown in the following example:
<literallayout class='monospaced'>
LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
md5=bb14ed3c4cda583abc85401304b5cd4e"
LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
</literallayout>
</para>
<para>
In this example, the first line locates a file in
<filename><link linkend='var-S'>S</link>/src/ls.c</filename>.
The second line refers to a file in
<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
of <filename>S</filename>.
</para>
<para>
Note that this variable is mandatory for all recipes, unless the
<filename>LICENSE</filename> variable is set to "CLOSED".
</para>
</section>
<section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
<title>Explanation of Syntax</title>
<para>
As mentioned in the previous section, the
<filename>LIC_FILES_CHKSUM</filename> variable lists all the
important files that contain the license text for the source code.
It is possible to specify a checksum for an entire file, or a specific section of a
file (specified by beginning and ending line numbers with the "beginline" and "endline"
parameters respectively).
The latter is useful for source files with a license notice header,
README documents, and so forth.
If you do not use the "beginline" parameter, then it is assumed that the text begins on the
first line of the file.
Similarly, if you do not use the "endline" parameter, it is assumed that the license text
ends with the last line of the file.
</para>
<para>
The "md5" parameter stores the md5 checksum of the license text.
If the license text changes in any way as compared to this parameter
then a mismatch occurs.
This mismatch triggers a build failure and notifies the developer.
Notification allows the developer to review and address the license text changes.
Also note that if a mismatch occurs during the build, the correct md5
checksum is placed in the build log and can be easily copied to the recipe.
</para>
<para>
There is no limit to how many files you can specify using the
<filename>LIC_FILES_CHKSUM</filename> variable.
Generally, however, every project requires a few specifications for license tracking.
Many projects have a "COPYING" file that stores the license information for all the source
code files.
This practice allows you to just track the "COPYING" file as long as it is kept up to date.
</para>
<tip>
If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
error and displays the correct "md5" parameter value during the build.
The correct parameter is also captured in the build log.
</tip>
<tip>
If the whole file contains only license text, you do not need to use the "beginline" and
"endline" parameters.
</tip>
</section>
</section>
<section id="usingpoky-configuring-DISTRO_PN_ALIAS">
<title>Handling a Package Name Alias</title>
<para>
Sometimes a package name you are using might exist under an alias or as a similarly named
package in a different distribution.
The Yocto Project implements a <filename>distro_check</filename>
task that automatically connects to major distributions
and checks for these situations.
If the package exists under a different name in a different distribution, you get a
<filename>distro_check</filename> mismatch.
You can resolve this problem by defining a per-distro recipe name alias using the
<filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
</para>
<para>
Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
variable:
<literallayout class='monospaced'>
DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
distro2=package_name_alias2 \
distro3=package_name_alias3 \
..."
</literallayout>
</para>
<para>
If you have more than one distribution alias, separate them with a space.
Note that the Yocto Project currently automatically checks the
Fedora, OpenSuSE, Debian, Ubuntu,
and Mandriva distributions for source package recipes without having to specify them
using the <filename>DISTRO_PN_ALIAS</filename> variable.
For example, the following command generates a report that lists the Linux distributions
that include the sources for each of the Yocto Project recipes.
<literallayout class='monospaced'>
$ bitbake world -f -c distro_check
</literallayout>
The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
file found in the Yocto Project files area.
</para>
</section>
</chapter>
<!--

View File

@ -14,7 +14,7 @@
<para>
Poky is the Yocto Project build system that was derived from <ulink
url='http://www.openembedded.org/'>OpenEmbedded</ulink>.
Poky is a stable, smaller subset focused on the GNOME Mobile environment.
Poky is a stable, smaller subset focused on the mobile environment.
Development in the Yocto Project using Poky is closely tied to OpenEmbedded with
features being merged regularly between the two for mutual benefit.
</para>
@ -33,8 +33,8 @@
You can use a stand-alone tarball to provide Python 2.6.
You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
<itemizedlist>
<listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
<listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
<listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
<listitem><para><ulink url='http://downloads.yoctoproject.org/releases/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
</itemizedlist>
</para>
<para>
@ -237,7 +237,7 @@
<question>
<para>
I see lots of 404 responses for files on
<filename>http://autobuilder.yoctoproject.org/sources/*</filename>. Is something wrong?
<filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
</para>
</question>
<answer>
@ -520,10 +520,10 @@
configuration file:
<literallayout class='monospaced'>
PREMIRRORS_prepend = "\
git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
git://.*/.* http://www.yoctoproject.org/sources/ \n \
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
</literallayout>
</para>
<para>
@ -564,9 +564,9 @@
configuration file as long as the PREMIRROR server is up to date:
<literallayout class='monospaced'>
PREMIRRORS_prepend = "\
ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
BB_FETCH_PREMIRRORONLY = "1"
</literallayout>
These changes would cause Poky to successfully fetch source over HTTP and

View File

@ -15,8 +15,11 @@
construct complete Linux images.
You can find complete introductory and getting started information on the Yocto Project
by reading the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink>.
For task-based information using the Yocto Project, see
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
You can also find lots of information on the Yocto Project on the
<ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>.
</para>
@ -36,6 +39,11 @@
<link linkend='extendpoky'>Extending the Yocto Project</link>:</emphasis> This chapter
provides information about how to extend and customize the Yocto Project
along with advice on how to manage these changes.</para></listitem>
<listitem><para><emphasis>
<link linkend='technical-details'>Technical Details</link>:</emphasis>
This chapter describes fundamental Yocto Project components as well as an explanation
behind how the Yocto Project uses shared state (sstate) cache to speed build time.
</para></listitem>
<listitem><para><emphasis>
<link linkend='bsp'>Board Support Packages (BSP) - Developer's Guide</link>:</emphasis>
This chapter describes the example filesystem layout for BSP development and
@ -90,9 +98,9 @@
<title>System Requirements</title>
<para>
For system Yocto Project system requirements, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#resources'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#resources'>
What You Need and How You Get It</ulink> section in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink>.
</para>
</section>
@ -104,9 +112,9 @@
of methods:
<itemizedlist>
<listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through
<ulink url='http://yoctoproject.org/downloads/poky/'/>.</para></listitem>
<ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
<listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
<ulink url='http://autobuilder.yoctoproject.org/'/>.
<ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
These builds include Yocto Project releases, meta-toolchain tarballs, and
experimental builds.</para></listitem>
<listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
@ -125,9 +133,9 @@
You can get these files by downloading a Yocto Project release tarball and unpacking it,
or by establishing a Git repository of the files.
For information on both these methods, see
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-setup'>
Getting Setup</ulink> section in
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
</section>

View File

@ -26,7 +26,7 @@
<email>richard.purdie@linuxfoundation.org</email>
</author>
<author>
<!-- <author>
<firstname>Tomas</firstname> <surname>Frydrych</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
@ -38,29 +38,39 @@
</author>
<author>
<firstname>Dodji</firstname> <surname>Seketeli</surname>
</author>
</author> -->
</authorgroup>
<revhistory>
<revision>
<revnumber>4.0+git</revnumber>
<date>24 November 2010</date>
<revremark>Poky Master Documentation</revremark>
<revremark>Released with the Yocto Project 0.9 Release</revremark>
</revision>
<revision>
<revnumber>5.0+git</revnumber>
<revnumber>1.0</revnumber>
<date>6 April 2011</date>
<revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.0.1</revnumber>
<date>23 May 2011</date>
<revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>6 October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1.1</revnumber>
<date>15 March 2012</date>
<revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>2007-2011</year>
<year>2007-2012</year>
<holder>Linux Foundation</holder>
</copyright>
@ -72,7 +82,7 @@
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.
@ -87,6 +97,8 @@
<xi:include href="extendpoky.xml"/>
<xi:include href="technical-details.xml"/>
<xi:include href="../bsp-guide/bsp.xml"/>
<xi:include href="development.xml"/>

View File

@ -122,7 +122,7 @@
<filename>task-base.bb</filename>,
which in turn leads to packages like <filename>Contacts</filename>,
<filename>Dates</filename> and <filename>BusyBox</filename>.
These packages in turn depend on glibc and the toolchain.
These packages in turn depend on <filename>eglibc</filename> and the toolchain.
</para>
<para>
@ -207,9 +207,9 @@
It is worth noting that you can greatly speed up the build time by properly setting
the <filename>BB_NUMBER_THREADS</filename> variable.
See the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
Building an Image</ulink> section in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink> for more information.
</para>
@ -260,8 +260,50 @@
<para>
Once all the tasks have been completed BitBake exits.
</para>
</section>
<para>
When running a task, BitBake tightly controls the execution environment
of the build tasks to make sure unwanted contamination from the build machine
cannot influence the build.
Consequently, if you do want something to get passed into the build
task's environment, you must take a few steps:
<orderedlist>
<listitem><para>Tell BitBake to load what you want from the environment
into the data store.
You can do so through the <filename>BB_ENV_WHITELIST</filename>
variable.
For example, assume you want to prevent the build system from
accessing your <filename>$HOME/.ccache</filename> directory.
The following command tells BitBake to load
<filename>CCACHE_DIR</filename> from the environment into the data
store:
<literallayout class='monospaced'>
export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
</literallayout></para></listitem>
<listitem><para>Tell BitBake to export what you have loaded into the
environment store to the task environment of every running task.
Loading something from the environment into the data store
(previous step) only makes it available in the datastore.
To export it to the task environment of every running task,
use a command similar to the following in your
<filename>local.conf</filename> or distro configuration file:
<literallayout class='monospaced'>
export CCACHE_DIR
</literallayout></para></listitem>
</orderedlist>
</para>
<note>
A side effect of the previous steps is that BitBake records the variable
as a dependency of the build process in things like the shared state
checksums.
If doing so results in unnecessary rebuilds of tasks, you can whitelist the
variable so that the shared state code ignores the dependency when it creates
checksums.
For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
example in <xref linkend='checksums'>Checksums (Signatures)</xref>.
</note>
</section>
<section id='ref-bitbake-commandline'>
<title>BitBake Command Line</title>

View File

@ -152,8 +152,8 @@
<para>
This class renames packages so that they follow the Debian naming
policy (i.e. <filename>glibc</filename> becomes <filename>libc6</filename>
and <filename>glibc-devel</filename> becomes <filename>libc6-dev</filename>.
policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
</para>
</section>
@ -387,10 +387,91 @@
<para>
This class adds a step to the package generation process that sanity checks the
packages generated by the Yocto Project.
An ever-increasing range of checks are performed that check for
common problems that break builds.
A range of checks are performed that check the build's output
for common problems that show up during runtime.
Distribution policy usually dictates whether to include this class as the Yocto Project does.
</para>
<para>
You can configure the sanity checks so that specific test failures either raise a warning or
an error message.
Typically, failures for new tests generate a warning.
Subsequent failures for the same test would then generate an error message
once the metadata is in a known and good condition.
You use the <filename>WARN_QA</filename> variable to specify tests for which you
want to generate a warning message on failure.
You use the <filename>ERROR_QA</filename> variable to specify tests for which you
want to generate an error message on failure.
</para>
<para>
The following list shows the tests you can list with the <filename>WARN_QA</filename>
and <filename>ERROR_QA</filename> variables:
<itemizedlist>
<listitem><para><emphasis><filename>ldflags:</filename></emphasis>
Ensures that the binaries were linked with the
<filename>LDFLAGS</filename> options provided by the build system.
If this test fails, check that the <filename>LDFLAGS</filename> variable
is being passed to the linker command.</para></listitem>
<listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
Checks for dynamic library load paths (rpaths) in the binaries that
by default on a standard system are searched by the linker (e.g.
<filename>/lib</filename> and <filename>/usr/lib</filename>).
While these paths will not cause any breakage, they do waste space and
are unnecessary.</para></listitem>
<listitem><para><emphasis><filename>rpaths:</filename></emphasis>
Checks for rpaths in the binaries that contain build system paths such
as <filename>TMPDIR</filename>.
If this test fails, bad <filename>-rpath</filename> options are being
passed to the linker commands and your binaries have potential security
issues.</para></listitem>
<listitem><para><emphasis><filename>dev-so:</filename></emphasis>
Checks that the <filename>.so</filename> symbolic links are in the
<filename>-dev</filename> package and not in any of the other packages.
In general, these symlinks are only useful for development purposes.
Thus, the <filename>-dev</filename> package is the correct location for
them.
Some very rare cases do exist for dynamically loaded modules where
these symlinks are needed instead in the main package.
</para></listitem>
<listitem><para><emphasis><filename>debug-files:</filename></emphasis>
Checks for <filename>.debug</filename> directories in anything but the
<filename>-dbg</filename> package.
The debug files should all be in the <filename>-dbg</filename> package.
Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
<listitem><para><emphasis><filename>arch:</filename></emphasis>
Checks the Executable and Linkable Format (ELF) type, bit size and endianness
of any binaries to ensure it matches the target architecture.
This test fails if any binaries don't match the type since there would be an
incompatibility.
Sometimes software, like bootloaders, might need to bypass this check.
</para></listitem>
<listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
Checks that <filename>-dbg</filename> packages only depend on other
<filename>-dbg</filename> packages and not on any other types of packages,
which would cause a packaging bug.</para></listitem>
<listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
Checks that <filename>-dev</filename> packages only depend on other
<filename>-dev</filename> packages and not on any other types of packages,
which would be a packaging bug.</para></listitem>
<listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
Checks <filename>.pc</filename> files for any
<filename>TMPDIR/WORKDIR</filename> paths.
Any <filename>.pc</filename> file containing these paths is incorrect
since <filename>pkg-config</filename> itself adds the correct sysroot prefix
when the files are accessed.</para></listitem>
<listitem><para><emphasis><filename>la:</filename></emphasis>
Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
paths.
Any <filename>.la</filename> file continaing these paths is incorrect since
<filename>libtool</filename> adds the correct sysroot prefix when using the
files automatically itself.</para></listitem>
<listitem><para><emphasis><filename>desktop:</filename></emphasis>
Runs the <filename>desktop-file-validate</filename> program against any
<filename>.desktop</filename> files to validate their contents against
the specification for <filename>.desktop</filename> files.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='ref-classes-siteinfo'>
@ -403,7 +484,7 @@
still make the correct values available.
The <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
contains test results sorted into different categories such as architecture, endianness, and
the libc used.
the <filename>libc</filename> used.
Site information provides a list of files containing data relevant to
the current build in the
<filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable
@ -422,6 +503,21 @@
</para>
</section>
<section id='ref-classes-useradd'>
<title>Adding Users - <filename>useradd.bbclass</filename></title>
<para>
If you have packages that install files that are owned by custom users or groups,
you can use this class to specify those packages and associate the users and groups
with those packages.
The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
recipe in the Yocto Project Files provides a simple exmample that shows how to add three
users and groups to two packages.
See the <filename>useradd-example.bb</filename> for more information on how to
use this class.
</para>
</section>
<section id='ref-classes-others'>
<title>Other Classes</title>
@ -436,44 +532,71 @@
</section>
<!-- Undocumented classes are:
base_srpm.bbclass
allarch.bbclass
binconfig.bbclass
bootimg.bbclass
buildstats.bbclass
ccache.inc
ccdv.bbclass
cmake.bbclass
cml1.bbclass
cross.bbclass
flow-lossage.bbclass
cross-canadian.bbclass
deploy.bbclass
distrodata.bbclass
gconf.bbclass
gettext.bbclass
gnome.bbclass
gtk-doc.bbclass
gtk-icon-cache.bbclass
icecc.bbclass
image-mklibs.bbclass
image-prelink.bbclass
image-swab.bbclass
imagetest-dummy.bbclass
imagetest-qemu.bbclass
insserv.bbclass
lib_package.bbclass
license.bbclass
logging.bbclass
meta.bbclass
metadata_scm.bbclass
mirrors.bbclass
mozilla.bbclass
multimachine.bbclass
multilib*.bbclass
native.bbclass
nativesdk.bbclass
oelint.bbclass
own-mirrors.bbclass
packagedata.bbclass
packagehistory.bbclass
patch.bbclass
patcher.bbclass
perlnative.bbclass
pkg_distribute.bbclass
pkg_metainfo.bbclass
poky.bbclass
populate_sdk*.bbclass
prserv.bbclass
python-dir.bbclass
qemu.bbclass
qmake*.bbclass
qt4*.bbclass
recipe_sanity.bbclass
relocatable.bbclass
rm_work.bbclass
rpm_core.bbclass
scons.bbclass
sdk.bbclass
sdl.bbclass
setuptools.bbclass
sip.bbclass
siteconfig.bbclass
sourcepkg.bbclass
srec.bbclass
sstate.bbclass
staging.bbclass
syslinux.bbclass
task.bbclass
terminal.bbclass
tinderclient.bbclass
tmake.bbclass
toolchain-scripts.bbclass
typecheck.bbclass
utility-tasks.bbclass
utils.bbclass
xfce.bbclass
xlibs.bbclass
-->

View File

@ -14,9 +14,9 @@
<para>
For information on how to establish the Yocto Project files on your local development system, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-started'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#getting-started'>
Getting Setup</ulink> section in the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>

View File

@ -16,7 +16,7 @@
<para>
<link linkend='var-AUTHOR'>A</link>
<link linkend='var-BB_NUMBER_THREADS'>B</link>
<link linkend='var-BAD_RECOMMENDATIONS'>B</link>
<link linkend='var-CFLAGS'>C</link>
<link linkend='var-D'>D</link>
<link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link>
@ -25,7 +25,7 @@
<link linkend='var-HOMEPAGE'>H</link>
<link linkend='var-IMAGE_FEATURES'>I</link>
<!-- <link linkend='var-glossary-j'>J</link> -->
<link linkend='var-KERNEL_IMAGETYPE'>K</link>
<link linkend='var-KERNEL_FEATURES'>K</link>
<link linkend='var-LAYERDIR'>L</link>
<link linkend='var-MACHINE'>M</link>
<!-- <link linkend='var-glossary-n'>N</link> -->
@ -64,6 +64,14 @@
<glossdiv id='var-glossary-b'><title>B</title>
<glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
<glossdef>
<para>A list of packages not to install despite being recommended by a recipe.
Support for this variable exists only for images that use the
<filename>ipkg</filename> packaging system.</para>
</glossdef>
</glossentry>
<glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
<glossdef>
<para>The maximum number of tasks BitBake should run in parallel at any one time.
@ -277,6 +285,7 @@
<glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
<glossdef>
<para></para>
<para>The list of packages which extend usability of the image.
Those packages will automatically be installed but can be removed by user.</para>
</glossdef>
@ -320,7 +329,8 @@
<glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
<glossdef>
<para>Variable that controls which locales for <filename>glibc</filename> are
<para></para>
<para>Variable that controls which locales for <filename>eglibc</filename> are
to be generated during the build (useful if the target device has 64Mbytes
of RAM or less).</para>
</glossdef>
@ -337,34 +347,36 @@
You can use this variable to add more features in addition to those.
Here are some examples of features you can add:</para>
<literallayout class='monospaced'>
"dbg-pkgs" - Adds -dbg packages for all installed packages
including symbol information for debugging and
profiling.
"dbg-pkgs" - Adds -dbg packages for all installed packages
including symbol information for debugging and
profiling.
"dev-pkgs" - Adds -dev packages for all installed packages.
This is useful if you want to develop against
the libraries in the image.
"dev-pkgs" - Adds -dev packages for all installed packages.
This is useful if you want to develop against
the libraries in the image.
"tools-sdk" - Adds development tools such as gcc, make,
pkgconfig and so forth.
"tools-sdk" - Adds development tools such as gcc, make,
pkgconfig and so forth.
"tools-debug" - Adds debugging tools such as gdb and
strace.
"tools-debug" - Adds debugging tools such as gdb and
strace.
"tools-profile" - Adds profiling tools such as oprofile,
exmap, lttng and valgrind (x86 only).
"tools-profile" - Adds profiling tools such as oprofile,
exmap, lttng and valgrind (x86 only).
"tools-testapps" - Adds useful testing tools such as
ts_print, aplay, arecord and so
forth.
"tools-testapps" - Adds useful testing tools such as
ts_print, aplay, arecord and so
forth.
"debug-tweaks" - Makes an image suitable for development.
For example, ssh root access has a blank
password. There are other application
targets too, see
meta/classes/poky-image.bbclass
and meta/packages/tasks/task-poky.bb
for more details.
"debug-tweaks" - Makes an image suitable for development.
For example, ssh root access has a blank
password. You should remove this feature
before you produce a production image.
There are other application targets too, see
<filename>meta/classes/poky-image.bbclass</filename>
and <filename>meta/packages/tasks/task-poky.bb</filename>
for more details.
</literallayout>
</glossdef>
</glossentry>
@ -397,6 +409,37 @@
</glossdef>
</glossentry>
<glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
<glossdef>
<para>Allows you to define your own file permissions settings table as part of
your configuration for the packaging process.
For example, suppose you need a consistent set of custom permissions for
a set of groups and users across an entire work project.
It is best to do this in the packages themselves but this is not always
possible.
</para>
<para>
By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which
is located in the <filename>meta/files</filename> directory of the Yocto Project
files directory.
If you create your own file permissions setting table, you should place it in your
layer or the distros layer.
</para>
<para>
You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
<filename>conf/local.conf</filename> file, which is found in the Yocto Project's
build directory, to point to your custom <filename>fs-perms.txt</filename>.
You can specify more than a single file permissions setting table.
The paths you specify to these files must be defined within the
<filename>BBPATH</filename> variable.
</para>
<para>
For guidance on how to create your own file permissions settings table file,
examine the existing <filename>fs-perms.txt</filename>.
</para>
</glossdef>
</glossentry>
<glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
<glossdef>
<para>
@ -539,6 +582,34 @@
<glossdiv id='var-glossary-k'><title>K</title>
<glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
<glossdef>
<para>Includes additional metadata from the Linux Yocto kernel Git repository.
In the Yocto Project build system, the default Board Support Packages (BSPs)
metadata is provided through
the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
You can use the <filename>KERNEL_FEATURES</filename> variable to further
add metadata for all BSPs.</para>
<para>The metadata you add through this variable includes config fragments and
features descriptions,
which usually includes patches as well as config fragments.
You typically override the <filename>KERNEL_FEATURES</filename> variable
for a specific machine.
In this way, you can provide validated, but optional, sets of kernel
configurations and features.</para>
<para>For example, the following adds <filename>netfilter</filename> to all
the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename>
machine:
<literallayout class='monospaced'>
# Add netfilter to all linux-yocto kernels
KERNEL_FEATURES="features/netfilter"
# Add sound support to the qemux86 machine
KERNEL_FEATURES_append_qemux86="cfg/sound"
</literallayout></para>
</glossdef>
</glossentry>
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
<glossdef>
<para>The type of kernel to build for a device, usually set by the
@ -622,29 +693,155 @@
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_ESSENTIAL_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_RDEPENDS</glossterm>
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
<glossdef>
<para>Specifies the list of packages required to boot the device.</para>
<para></para>
<para>
A list of required packages to install as part of the package being
built.
The build process depends on these packages being present.
Furthermore, because this is a "machine essential" variable, the list of
packages are essential for the machine to boot.
The impact of this variable affects images based on <filename>task-core-boot</filename>,
including the <filename>core-image-minimal</filename> image.
</para>
<para>
This variable is similar to the
<link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link>
variable with the exception that the package being built has a build
dependency on the variable's list of packages.
In other words, the image will not build if a file in this list is not found.
</para>
<para>
For example, suppose you are building a runtime package that depends
on a certain disk driver.
In this case, you would use the following:
<literallayout class='monospaced'>
MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "&lt;disk_driver&gt;"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_ESSENTIAL_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_RRECOMMENDS</glossterm>
<glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
<glossdef>
<para>Specifies the list of packages required to boot the device (usually
additional kernel modules).</para>
<para></para>
<para>
A list of recommended packages to install as part of the package being
built.
The build process does not depend on these packages being present.
Furthermore, because this is a "machine essential" variable, the list of
packages are essential for the machine to boot.
The impact of this variable affects images based on <filename>task-core-boot</filename>,
including the <filename>core-image-minimal</filename> image.
</para>
<para>
This variable is similar to the
<link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link>
variable with the exception that the package being built does not have a build
dependency on the variable's list of packages.
In other words, the image will build if a file in this list is not found.
However, because this is one of the "essential" variables, the resulting image
might not boot on the machine.
Or, if the machine does boot using the image, the machine might not be fully
functional.
</para>
<para>
Consider an example where you have a custom kernel with a disk driver
built into the kernel itself, rather than using the driver built as a module.
If you include the package that has the driver module as part of
the variable's list, the
build process will not find that package.
However, because these packages are "recommends" packages, the build will
not fail due to the missing package.
Not accounting for any other problems, the custom kernel would still boot the machine.
</para>
<para>
Some example packages of these machine essentials are flash, screen, keyboard, mouse,
or touchscreen drivers (depending on the machine).
</para>
<para>
For example, suppose you are building a runtime package that depends
on a mouse driver.
In this case, you would use the following:
<literallayout class='monospaced'>
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "&lt;mouse_driver&gt;"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
<glossdef>
<para>Specifies the list of packages required to use the devices</para>
<para>
A list of optional but non-machine essential packages to install as
part of the package being built.
Even though these packages are not essential for the machine to boot,
the build process depends on them being present.
The impact of this variable affects all images based on
<filename>task-base</filename>, which does not include the
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
images.
</para>
<para>
This variable is similar to the
<link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link>
variable with the exception that the package being built has a build
dependency on the variable's list of packages.
In other words, the image will not build if a file in this list is not found.
</para>
<para>
An example is a machine that might or might not have a WiFi card.
The package containing the WiFi support is not essential for the
machine to boot the image.
If it is not there, the machine will boot but not be able to use the
WiFi functionality.
However, if you include the package with the WiFi support as part of the
variable's package list, the build
process depends on finding the package.
In this case, you would use the following:
<literallayout class='monospaced'>
MACHINE_EXTRA_RDEPENDS += "&lt;wifi_driver&gt;"
</literallayout>
</para>
</glossdef>
</glossentry>
<glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
<glossdef>
<para>Specifies the list of packages useful to use the device (e.g.
additional kernel modules)</para>
<para></para>
<para>
A list of optional but non-machine essential packages to install as
part of the package being built.
The package being built has no build dependency on the list of packages
with this variable.
The impact of this variable affects only images based on
<filename>task-base</filename>, which does not include the
<filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
images.
</para>
<para>
This variable is similar to the
<link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link>
variable with the exception that the package being built does not have a build
dependency on the variable's list of packages.
In other words, the image will build if a file in this list is not found.
</para>
<para>
An example is a machine that might or might not have a WiFi card.
The package containing the WiFi support is not essential for the
machine to boot the image.
If it is not there, the machine will boot but not be able to use the
WiFi functionality.
You are free to either include or not include the
the package with the WiFi support as part of the
variable's package list, the build
process does not depend on finding the package.
If you include the package, you would use the following:
<literallayout class='monospaced'>
MACHINE_EXTRA_RRECOMMENDS += "&lt;wifi_driver&gt;"
</literallayout>
</para>
</glossdef>
</glossentry>
@ -781,10 +978,18 @@
<glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
<glossdef>
<para>If multiple recipes provide an item, this variable
<para>
If multiple recipes provide an item, this variable
determines which recipe should be given preference.
The variable should be set to the <filename>$PN</filename> of the recipe
to which you want to give precedence.</para>
The variable must always be suffixed with the name of the
provided item, and should be set to the
<filename>$PN</filename> of the recipe
to which you want to give precedence.
Here is an example:
<literallayout class='monospaced'>
PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
</literallayout>
</para>
</glossdef>
</glossentry>
@ -793,8 +998,18 @@
<para>
If there are multiple versions of recipes available, this
variable determines which recipe should be given preference.
The variable should be set to the <filename>$PV</filename> of the recipe
to whichy you want to give precedence.
The variable must always be suffixed with the <filename>$PN</filename>
for which to select, and should be set to the
<filename>$PV</filename> to which you want to give precedence.
You can use the "<filename>%</filename>" character as a wildcard
to match any number of characters, which can be useful when
specifying versions that contain long revision number that could
potentially change.
Here are two examples:
<literallayout class='monospaced'>
PREFERRED_VERSION_python = "2.6.6"
PREFERRED_VERSION_linux-yocto = "3.0+git%"
</literallayout>
</para>
</glossdef>
</glossentry>
@ -809,19 +1024,19 @@
<glossentry id='var-POKYLIBC'><glossterm>POKYLIBC</glossterm>
<glossdef>
<para>The <filename>libc</filename> implementation selector.
You can select <filename>glibc</filename>, <filename>eglibc</filename>,
or <filename>uclibc</filename>.</para>
<para>
This variable is no longer supported and has been replaced by the
<link linkend='var-TCLIBC'><filename>TCLIBC</filename></link> variable.
</para>
</glossdef>
</glossentry>
<glossentry id='var-POKYMODE'><glossterm>POKYMODE</glossterm>
<glossdef>
<para>The toolchain selector.
This variable has been replaced by <filename>TCMODE</filename>.
The <filename>POKYMODE</filename> would select the external toolchain
built from the Yocto Project or a few supported combinations of
upstream GCC or CodeSourcery Labs toolchain.</para>
<para>
This variable is no longer supported and has been replaced by the
<link linkend='var-TCMODE'><filename>TCMODE</filename></link> variable.
</para>
</glossdef>
</glossentry>
@ -843,18 +1058,48 @@
<glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
<glossdef>
<para>
A list of run-time dependencies for a package.
These packages need to be installed alongside the package to which
they apply.
This enables the package to run correctly.
For example, consider a Perl script, which depends on the Perl package.
Since this variable applies to
output packages, there would usually be an override attached
to this variable such as <filename>RDEPENDS_${PN}-dev</filename>.
Names in this field must appear as they appear in the
A list of packages that must be installed as part of a package being built.
The package being built has a runtime dependency on the packages in the
variable's list.
In other words, in order for the package being built to run correctly,
it depends on these listed packages.
If a package in this list cannot be found during the build, the build
will not complete.
</para>
<para>
Because the <filename>RDEPENDS</filename> variable applies to packages
being built, you should
always attach an override to the variable to specify the particular runtime package
that has the dependency.
For example, suppose you are building a development package that depends
on the <filename>perl</filename> package.
In this case, you would use the following <filename>RDEPENDS</filename>
statement:
<literallayout class='monospaced'>
RDEPENDS_${PN}-dev += "perl"
</literallayout>
In the example, the package name (<filename>${PN}-dev</filename>) must
appear as it would in the
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any
renaming of the output package by classes like <filename>debian.bbclass</filename>.
</para>
<para>
Some automatic handling occurs around the <filename>RDEPENDS</filename>
variable:
<itemizedlist>
<listitem><para><emphasis><filename>shlibdeps</filename></emphasis>: If a runtime
package contains a shared library (<filename>.so</filename>), the build
processes the library in order to determine other libraries to which it
is dynamically linked.
The build process adds these libraries to <filename>RDEPENDS</filename>
to create the runtime package.</para></listitem>
<listitem><para><emphasis><filename>pcdeps</filename></emphasis>: If the package
ships a <filename>pkg-config</filename> information file, the build process
uses this file to add items to the <filename>RDEPENDS</filename>
variable to create the runtime packages.
</para></listitem>
</itemizedlist>
</para>
</glossdef>
</glossentry>
@ -866,8 +1111,37 @@
<glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
<glossdef>
<para>The list of packages that extend usability of the package.
The packages are automatically installed but can be removed by user.</para>
<para>
A list of packages that extend the usability of a package being
built.
The package being built does not depend on this list of packages in
order to successfully build, but needs them for the extended usability.
To specify runtime dependencies for packages, see the
<link linkend='var-RDEPENDS'>RDEPENDS</link> variable.
</para>
<para>
The Yocto Project build process automatically installs the list of packages
as part of the built package.
However, you can remove them later if you want.
If, during the build, a package from the list cannot be found, the build
process continues without an error.
</para>
<para>
Because the <filename>RRECOMMENDS</filename> variable applies to packages
being built, you should
always attach an override to the variable to specify the particular package
whose usability is being extended.
For example, suppose you are building a development package that is extended
to support wireless functionality.
In this case, you would use the following:
<literallayout class='monospaced'>
RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
</literallayout>
In the example, the package name (<filename>${PN}-dev</filename>) must
appear as it would in the
<filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any
renaming of the output package by classes like <filename>debian.bbclass</filename>.
</para>
</glossdef>
</glossentry>
@ -961,6 +1235,7 @@
<glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
<glossdef>
<para></para>
<para>
By default, the Yocto Project automatically detects whether
<filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>
@ -1057,24 +1332,52 @@
<glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
<glossdef>
<para>Specifies the target's operating system.
The variable can be set to "linux" for <filename>glibc</filename>-based systems and
"linux-uclibc" for <filename>uClibc</filename>.
The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
to "linux-uclibc" for <filename>uclibc</filename>.
For ARM/EABI targets, there are also "linux-gnueabi" and
"linux-uclibc-gnueabi" values possible.</para>
</glossdef>
</glossentry>
<glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
<glossdef>
<para>
Specifies which variant of the GNU standard C library (<filename>libc</filename>)
to use during the build process.
This variable replaces <filename>POKYLIBC</filename>, which is no longer
supported.
</para>
<para>
You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
<note>
This release of the Yocto Project does not support the
<filename>glibc</filename> implementation of <filename>libc</filename>.
</note>
</para>
</glossdef>
</glossentry>
<glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
<glossdef>
<para>The toolchain selector.
This variable replaces <filename>POKYMODE</filename>.
<para>
The toolchain selector.
This variable replaces <filename>POKYMODE</filename>, which is no longer
supported.
</para>
<para>
The <filename>TCMODE</filename> variable selects the external toolchain
built from the Yocto Project or a few supported combinations of
the upstream GCC or CodeSourcery Labs toolchain.
The variable determines which of the files in
<filename>meta/conf/distro/include/tcmode-*</filename> is used.
</para>
<para>
By default, <filename>TCMODE</filename> is set to "default", which
chooses <filename>tcmode-default.inc</filename>.</para>
<para>The variable is similar to <filename>TCLIBC</filename>, which controls the
<filename>libc</filename> used: <filename>eglibc</filename> or <filename>uclibc</filename>.
</para>
chooses <filename>tcmode-default.inc</filename>.
The variable is similar to <filename>TCLIBC</filename>, which controls
the variant of the GNU standard C library (<filename>libc</filename>)
used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
</para>
</glossdef>
</glossentry>

View File

@ -71,10 +71,10 @@
</link></filename></para></listitem>
<listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
</link></filename></para></listitem>
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RDEPENDS'>MACHINE_ESSENTIAL_RDEPENDS
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
</link></filename></para></listitem>
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'>
MACHINE_ESSENTIAL_RRECOMMENDS</link></filename></para></listitem>
<listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
</itemizedlist>
</para>
</section>

View File

@ -10,9 +10,9 @@
The Yocto Project team is happy for people to experiment with the Yocto Project.
A number of places exist to find help if you run into difficulties or find bugs.
To find out how to download source code,
see the <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-yp-release'>
see the <ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>
Yocto Project Release</ulink> list item in
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto
Project Development Manual</ulink>.
</para>
</section>
@ -32,13 +32,16 @@
<para>
To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
<itemizedlist>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a
Yocto Discussions mailing list.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a
Yocto Project Discussions mailing list.</para></listitem>
<listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink> for a
mailing list to receive offical Yocto Project announcements for developments and
as well as Yocto Project milestones.</para></listitem>
<listitem><para><emphasis>
<ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>:
Use this list to receive offical Yocto Project announcements for developments and
to learn about Yocto Project milestones.</para></listitem>
<listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>:
Use this list to monitor Yocto Project development discussions, ask questions, and
get help.</para></listitem>
<listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>:
Use this list to monitor discussions about the Yocto Project build system Poky,
ask questions, and get help.</para></listitem>
</itemizedlist>
</para>
</section>
@ -90,44 +93,14 @@
<title>Contributions</title>
<para>
Contributions to the Yocto Project are very welcome.
You should send patches to the Yocto Project mailing list along with a "signed-off-by:"
line in the same style as required by the Linux kernel.
Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
as follows:
<literallayout class='monospaced'>
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
</literallayout>
A Poky contributions tree (<filename>poky-contrib</filename>,
<filename>git://git.yoctoproject.org/poky-contrib.git</filename>)
exists for contributors to stage contributions.
If people desire such access, please ask on the mailing list.
Usually, the Yocto Project team will grant access to anyone with a proven track
record of good patches.
The Yocto Project gladly accepts contributions.
You can submit changes to the project either by creating and sending pull requests,
or by submitting patches through email.
For information on how to do both, see
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#how-to-submit-a-change'>
How to Submit a Change</ulink> in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
</section>

View File

@ -0,0 +1,574 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id='technical-details'>
<title>Technical Details</title>
<para>
This chapter provides technical details for various parts of the Yocto Project.
Currently, topics include Yocto Project components and shared state (sstate) cache.
</para>
<section id='usingpoky-components'>
<title>Yocto Project Components</title>
<para>
The BitBake task executor together with various types of configuration files form the
Yocto Project core.
This section overviews the BitBake task executor and the
configuration files by describing what they are used for and how they interact.
</para>
<para>
BitBake handles the parsing and execution of the data files.
The data itself is of various types:
<itemizedlist>
<listitem><para><emphasis>Recipes:</emphasis> Provides 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> Defines machine-specific settings,
policy decisions, etc.
Configuration data acts as the glue to bind everything together.</para></listitem>
</itemizedlist>
For more information on data, see the
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html#yocto-project-terms'>
Yocto Project Terms</ulink> section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1//dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
<para>
BitBake knows how to combine multiple data sources together and refers to each data source
as a "<link linkend='usingpoky-changes-layers'>layer</link>".
</para>
<para>
Following are some brief details on these core components.
For more detailed information on these components see the
<link linkend='ref-structure'>'Reference: Directory Structure'</link>
appendix.
</para>
<section id='usingpoky-components-bitbake'>
<title>BitBake</title>
<para>
BitBake is the tool at the heart of the Yocto Project and is responsible
for parsing the metadata, generating a list of tasks from it,
and then executing those tasks.
To see a list of the options BitBake supports, use the following help command:
<literallayout class='monospaced'>
$ bitbake --help
</literallayout>
</para>
<para>
The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
<filename>packagename</filename> is the name of the package you want to build
(referred to as the "target" in this manual).
The target often equates to the first part of a <filename>.bb</filename> filename.
So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
might type the following:
<literallayout class='monospaced'>
$ bitbake matchbox-desktop
</literallayout>
Several different versions of <filename>matchbox-desktop</filename> might exist.
BitBake chooses the one selected by the distribution configuration.
You can get more details about how BitBake chooses between different
target versions and providers in the
<link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
</para>
<para>
BitBake also tries to execute any dependent tasks first.
So for example, before building <filename>matchbox-desktop</filename>, BitBake
would build a cross compiler and <filename>eglibc</filename> if they had not already
been built.
<note>This release of the Yocto Project does not support the <filename>glibc</filename>
GNU version of the Unix standard C library. By default, the Yocto Project builds with
<filename>eglibc</filename>.</note>
</para>
<para>
A useful BitBake option to consider is the <filename>-k</filename> or
<filename>--continue</filename> option.
This option instructs BitBake to try and continue processing the job as much
as possible even after encountering an error.
When an error occurs, the target that
failed and those that depend on it cannot be remade.
However, when you use this option other dependencies can still be processed.
</para>
</section>
<section id='usingpoky-components-metadata'>
<title>Metadata (Recipes)</title>
<para>
The <filename>.bb</filename> files are usually referred to as "recipes."
In general, a recipe contains information about a single piece of software.
The information includes the location from which to download the source patches
(if any are needed), which special configuration options to apply,
how to compile the source files, and how to package the compiled output.
</para>
<para>
The term "package" can also be used to describe recipes.
However, since the same word is used for the packaged output from the Yocto
Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
this document avoids using the term "package" when refering to recipes.
</para>
</section>
<section id='usingpoky-components-classes'>
<title>Classes</title>
<para>
Class files (<filename>.bbclass</filename>) contain information that is useful to share
between metadata files.
An example is the Autotools class, which contains
common settings for any application that Autotools uses.
The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
about common classes and how to use them.
</para>
</section>
<section id='usingpoky-components-configuration'>
<title>Configuration</title>
<para>
The configuration files (<filename>.conf</filename>) define various configuration variables
that govern the Yocto Project 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 (<filename>local.conf</filename>, which is found
in the Yocto Project files build directory).
</para>
</section>
</section>
<section id="shared-state-cache">
<title>Shared State Cache</title>
<para>
By design, the Yocto Project build system builds everything from scratch unless
BitBake can determine that parts don't need to be rebuilt.
Fundamentally, building from scratch is attractive as it means all parts are
built fresh and there is no possibility of stale data causing problems.
When developers hit problems, they typically default back to building from scratch
so they know the state of things from the start.
</para>
<para>
Building an image from scratch is both an advantage and a disadvantage to the process.
As mentioned in the previous paragraph, building from scratch ensures that
everything is current and starts from a known state.
However, building from scratch also takes much longer as it generally means
rebuiding things that don't necessarily need rebuilt.
</para>
<para>
The Yocto Project implements shared state code that supports incremental builds.
The implementation of the shared state code answers the following questions that
were fundamental roadblocks within the Yocto Project incremental build support system:
<itemizedlist>
<listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
<listitem>How are changed pieces of software removed and replaced?</listitem>
<listitem>How are pre-built components that don't need to be rebuilt from scratch
used when they are available?</listitem>
</itemizedlist>
</para>
<para>
For the first question, the build system detects changes in the "inputs" to a given task by
creating a checksum (or signature) of the task's inputs.
If the checksum changes, the system assumes the inputs have changed and the task needs to be
rerun.
For the second question, the shared state (sstate) code tracks which tasks add which output
to the build process.
This means the output from a given task can be removed, upgraded or otherwise manipulated.
The third question is partly addressed by the solution for the second question
assuming the build system can fetch the sstate objects from remote locations and
install them if they are deemed to be valid.
</para>
<para>
The rest of this section goes into detail about the overall incremental build
architecture, the checksums (signatures), shared state, and some tips and tricks.
</para>
<section id='overall-architecture'>
<title>Overall Architecture</title>
<para>
When determining what parts of the system need to be built, BitBake
uses a per-task basis and does not use a per-recipe basis.
You might wonder why using a per-task basis is preferred over a per-recipe basis.
To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
In this case, <filename>do_install</filename> and <filename>do_package</filename>
output are still valid.
However, with a per-recipe approach, the build would not include the
<filename>.deb</filename> files.
Consequently, you would have to invalidate the whole build and rerun it.
Rerunning everything is not the best situation.
Also in this case, the core must be "taught" much about specific tasks.
This methodology does not scale well and does not allow users to easily add new tasks
in layers or as external recipes without touching the packaged-staging core.
</para>
</section>
<section id='checksums'>
<title>Checksums (Signatures)</title>
<para>
The shared state code uses a checksum, which is a unique signature of a task's
inputs, to determine if a task needs to be run again.
Because it is a change in a task's inputs that triggers a rerun, the process
needs to detect all the inputs to a given task.
For shell tasks, this turns out to be fairly easy because
the build process 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, there are things that should not be included in
the checksum.
First, there is the actual specific build path of a given task -
the <filename>WORKDIR</filename>.
It does not matter if the working directory changes because it should not
affect the output for target packages.
Also, the build process has the objective of making native/cross packages relocatable.
The checksum therefore needs to exclude <filename>WORKDIR</filename>.
The simplistic approach for excluding the worknig directory is to set
<filename>WORKDIR</filename> to some fixed value and create the checksum
for the "run" script.
</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 <filename>WORKDIR</filename> 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 inline 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.
The Yocto Project team has currently not managed to cover those dependencies
in detail and is aware of the need to fix this situation.
</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>
While figuring out the dependencies and creating these checksums is good,
what does the Yocto Project build system do with the checksum information?
The build system uses a signature handler that is responsible for
processing the checksum information.
By default, there is a dummy "noop" signature handler enabled in BitBake.
This means that behaviour is unchanged from previous versions.
OECore uses the "basic" signature handler through this setting in the
<filename>bitbake.conf</filename> file:
<literallayout class='monospaced'>
BB_SIGNATURE_HANDLER ?= "basic"
</literallayout>
Also within the BitBake configuration file, we can give BitBake
some extra information to help it handle this information.
The following statements effectively result in a list of global
variable dependency excludes - variables never included in
any checksum:
<literallayout class='monospaced'>
BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
BB_HASHTASK_WHITELIST += "(.*-cross$|.*-native$|.*-cross-initial$| \
.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
</literallayout>
This example is actually where <filename>WORKDIR</filename>
is excluded since <filename>WORKDIR</filename> is constructed as a
path within <filename>TMPDIR</filename>, which is on the whitelist.
</para>
<para>
The <filename>BB_HASHTASK_WHITELIST</filename> covers dependent tasks and
excludes certain kinds of tasks from the dependency chains.
The effect of the previous example is to isolate the native, target,
and cross-components.
So, for example, toolchain changes do not force a rebuild of the whole system.
</para>
<para>
The end result of the "basic" handler is to make some dependency and
hash information available to the build.
This includes:
<literallayout class='monospaced'>
BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
BB_TASKHASH - the hash of the currently running task
</literallayout>
There is also a "basichash" <filename>BB_SIGNATURE_HANDLER</filename>,
which is the same as the basic 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 <filename>PR</filename>
values and changes to metadata automatically ripple across the build.
Currently, this behavior is not the default behavior.
However, it is likely that the Yocto Project team will go forward with this
behavior in the future since all the functionality exists.
The reason for the delay is the potential impact to the distribution feed
creation as they need increasing <filename>PR</filename> fields
and the Yocto Project currently lacks a mechanism to automate incrementing
this field.
</para>
</section>
<section id='shared-state'>
<title>Shared State</title>
<para>
Checksums and dependencies, as discussed in the previous section, solve half the
problem.
The other part of the problem is being able to use checksum information during the build
and being able to reuse or rebuild specific components.
</para>
<para>
The shared state class (<filename>sstate.bbclass</filename>)
is a relatively generic implementation of how to "capture" a snapshot of a given task.
The idea is that the build process does not care about the source of a task's output.
Output could be freshly built or it could be downloaded and unpacked from
somewhere - the build process doesn't need to worry about its source.
</para>
<para>
There are two types of output, one is just about creating a directory
in <filename>WORKDIR</filename>.
A good example is the output of either <filename>do_install</filename> or
<filename>do_package</filename>.
The other type of output occurs when a set of data is merged into a shared directory
tree such as the sysroot.
</para>
<para>
The Yocto Project team has tried to keep the details of the implementation hidden in
<filename>sstate.bbclass</filename>.
From a user's perspective, adding shared state wrapping to a task
is as simple as this <filename>do_deploy</filename> example taken from
<filename>do_deploy.bbclass</filename>:
<literallayout class='monospaced'>
DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
SSTATETASKS += "do_deploy"
do_deploy[sstate-name] = "deploy"
do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
python do_deploy_setscene () {
sstate_setscene(d)
}
addtask do_deploy_setscene
</literallayout>
In the example, we add some extra flags to the task, a name field ("deploy"), an
input directory where the task sends data, and the output
directory where the data from the task should eventually be copied.
We also add a <filename>_setscene</filename> variant of the task and add the task
name to the <filename>SSTATETASKS</filename> list.
</para>
<para>
If you have a directory whose contents you need to preserve, you can do this with
a line like the following:
<literallayout class='monospaced'>
do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
</literallayout>
This method, as well as the following example, also works for mutliple directories.
<literallayout class='monospaced'>
do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
do_package[sstate-lockfile] = "${PACKAGELOCK}"
</literallayout>
These methods also include the ability to take a lockfile when manipulating
shared state directory structures since some cases are sensitive to file
additions or removals.
</para>
<para>
Behind the scenes, the shared state code works by looking in
<filename>SSTATE_DIR</filename> and
<filename>SSTATE_MIRRORS</filename> for shared state files.
Here is an example:
<literallayout class='monospaced'>
SSTATE_MIRRORS ?= "\
file://.* http://someserver.tld/share/sstate/ \n \
file://.* file:///some/local/dir/sstate/"
</literallayout>
</para>
<para>
The shared state package validity can be detected just by looking at the
filename since the filename contains the task checksum (or signature) as
described earlier in this section.
If a valid shared state package is found, the build process downloads it
and uses it to accelerate the task.
</para>
<para>
The build processes uses the <filename>*_setscene</filename> tasks
for the task acceleration phase.
BitBake goes through this phase before the main execution code and tries
to accelerate any tasks for which it can find shared state packages.
If a shared state package for a task is available, the shared state
package is used.
This means the task and any tasks on which it is dependent are not
executed.
</para>
<para>
As a real world example, the aim is when building an IPK-based image,
only the <filename>do_package_write_ipk</filename> tasks would have their
shared state packages fetched and extracted.
Since the sysroot is not used, it would never get extracted.
This is another reason why a task-based approach is preferred over a
recipe-based approach, which would have to install the output from every task.
</para>
</section>
<section id='tips-and-tricks'>
<title>Tips and Tricks</title>
<para>
The code in the Yocto Project that supports incremental builds is not
simple code.
This section presents some tips and tricks that help you work around
issues related to shared state code.
</para>
<section id='debugging'>
<title>Debugging</title>
<para>
When things go wrong, debugging needs to be straightforward.
Because of this, the Yocto Project team included strong debugging
tools:
<itemizedlist>
<listitem><para>Whenever a shared state package is written out, so is a
corresponding <filename>.siginfo</filename> file.
This practice results in a pickled python database of all
the metadata that went into creating the hash for a given shared state
package.</para></listitem>
<listitem><para>If BitBake is run with the <filename>--dump-signatures</filename>
(or <filename>-S</filename>) option, BitBake dumps out
<filename>.siginfo</filename> files in
the stamp directory for every task it would have executed instead of
building the specified target package.</para></listitem>
<listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
can process these <filename>.siginfo</filename> files.
If one file is specified, it will dump out the dependency
information in the file.
If two files are specified, it will compare the two files and dump out
the differences between the two.
This allows the question of "What changed between X and Y?" to be
answered easily.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='invalidating-shared-state'>
<title>Invalidating Shared State</title>
<para>
The shared state code uses checksums and shared state memory
cache to avoid unnecessarily rebuilding tasks.
As with all schemes, this one has some drawbacks.
It is possible that you could make implicit changes that are not factored
into the checksum calculation, but do affect a task's output.
A good example is perhaps when a tool changes its output.
Let's say that the output of <filename>rpmdeps</filename> needed to change.
The result of the change should be that all the "package", "package_write_rpm",
and "package_deploy-rpm" shared state cache items would become invalid.
But, because this is a change that is external to the code and therefore implicit,
the associated shared state cache items do not become invalidated.
In this case, the build process would use the cached items rather than running the
task again.
Obviously, these types of implicit changes can cause problems.
</para>
<para>
To avoid these problems during the build, you need to understand the effects of any
change you make.
Note that any changes you make directly to a function automatically are factored into
the checksum calculation and thus, will invalidate the associated area of sstate cache.
You need to be aware of any implicit changes that are not obvious changes to the
code and could affect the output of a given task.
Once you are aware of such a change, you can take steps to invalidate the cache
and force the task to run.
The step to take is as simple as changing a function's comments in the source code.
For example, to invalidate package shared state files, change the comment statments
of <filename>do_package</filename> or the comments of one of the functions it calls.
The change is purely cosmetic, but it causes the checksum to be recalculated and
forces the task to be run again.
</para>
<note>
For an example of a commit that makes a cosmetic change to invalidate
a shared state, see this
<ulink url='http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
</note>
</section>
</section>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -4,210 +4,84 @@
<title>Using the Yocto Project</title>
<para>
This section gives an overview of the components that make up the Yocto Project
followed by information about Yocto Project builds and dealing with any
problems that might arise.
This chapter describes common usage for the Yocto Project.
The information is introductory in nature as other manuals in the Yocto Project
provide more details on how to use the Yocto Project.
</para>
<section id='usingpoky-components'>
<title>Yocto Project Components</title>
<para>
The BitBake task executor together with various types of configuration files form the
Yocto Project core.
This section overviews the BitBake task executor and the
configuration files by describing what they are used for and they they interact.
</para>
<para>
BitBake handles the parsing and execution of the data files.
The data itself is of various types:
<itemizedlist>
<listitem><para><emphasis>Recipes:</emphasis> Provides 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> Defines machine-specific settings,
policy decisions, etc.
Configuration data acts a the glue to bind everything together.</para></listitem>
</itemizedlist>
For more information on data, see the
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#yocto-project-terms'>
Yocto Project Terms</ulink> section in
<ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
The Yocto Project Development Manual</ulink>.
</para>
<para>
BitBake knows how to combine multiple data sources together and refers to each data source
as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
</para>
<para>
Following are some brief details on these core components.
For more detailed information on these components see the
<link linkend='ref-structure'>'Reference: Directory Structure'</link>
appendix.
</para>
<section id='usingpoky-components-bitbake'>
<title>BitBake</title>
<para>
BitBake is the tool at the heart of the Yocto Project and is responsible
for parsing the metadata, generating a list of tasks from it,
and then executing those tasks.
To see a list of the options BitBake supports, use the following help command:
<literallayout class='monospaced'>
$ bitbake --help
</literallayout>
</para>
<para>
The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
<filename>packagename</filename> is the name of the package you want to build
(referred to as the "target" in this manual).
The target often equates to the first part of a <filename>.bb</filename> filename.
So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
might type the following:
<literallayout class='monospaced'>
$ bitbake matchbox-desktop
</literallayout>
Several different versions of <filename>matchbox-desktop</filename> might exist.
BitBake chooses the one selected by the distribution configuration.
You can get more details about how BitBake chooses between different
target versions and providers in the
<link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
</para>
<para>
BitBake also tries to execute any dependent tasks first.
So for example, before building <filename>matchbox-desktop</filename>, BitBake
would build a cross compiler and <filename>glibc</filename> if they had not already
been built.
</para>
<para>
A useful BitBake option to consider is the <filename>-k</filename> or
<filename>--continue</filename> option.
This option instructs BitBake to try and continue processing the job as much
as possible even after encountering an error.
When an error occurs, the target that
failed and those that depend on it cannot be remade.
However, when you use this option other dependencies can still be processed.
</para>
</section>
<section id='usingpoky-components-metadata'>
<title>Metadata (Recipes)</title>
<para>
The <filename>.bb</filename> files are usually referred to as "recipes."
In general, a recipe contains information about a single piece of software.
The information includes the location from which to download the source patches
(if any are needed), which special configuration options to apply,
how to compile the source files, and how to package the compiled output.
</para>
<para>
The term "package" can also be used to describe recipes.
However, since the same word is used for the packaged output from the Yocto
Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
this document avoids using the term "package" to refer to recipes.
</para>
</section>
<section id='usingpoky-components-classes'>
<title>Classes</title>
<para>
Class files (<filename>.bbclass</filename>) contain information that is useful to share
between metadata files.
An example is the Autotools class, which contains
common settings for any application that Autotools uses.
The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
about common classes and how to use them.
</para>
</section>
<section id='usingpoky-components-configuration'>
<title>Configuration</title>
<para>
The configuration files (<filename>.conf</filename>) define various configuration variables
that govern the Yocto Project 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 (<filename>local.conf</filename>, which is found
in the Yocto Project files build directory).
</para>
</section>
</section>
<section id='usingpoky-build'>
<title>Running a Build</title>
<para>
You can find information on how to build an image using the Yocto Project in the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
You can find general information on how to build an image using the
Yocto Project in the
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
Building an Image</ulink> section of the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink>.
This section provides a quick overview.
This section provides a summary of the build process and provides information
for less obvious aspects of the build process.
</para>
<para>
The first thing you need to do is set up the Yocto Project build environment by sourcing
the environment setup script as follows:
<literallayout class='monospaced'>
$ source oe-init-build-env [build_dir];
</literallayout>
</para>
<section id='build-overview'>
<title>Build Overview</title>
<para>
The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
uses for the build.
If you do not specify a build directory it defaults to <filename>build</filename>
in the Yocto Project files directory structure.
A common practice is to use a different build directory for different targets.
For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
See <link linkend="structure-core-script">oe-init-build-env</link>
for more information on this script.
</para>
<para>
The first thing you need to do is set up the Yocto Project build environment by sourcing
the environment setup script as follows:
<literallayout class='monospaced'>
$ source oe-init-build-env [build_dir]
</literallayout>
</para>
<para>
Once the Yocto Project build environment is set up, you can build a target using:
<literallayout class='monospaced'>
<para>
The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
uses for the build.
If you do not specify a build directory it defaults to <filename>build</filename>
in your current working directory.
A common practice is to use a different build directory for different targets.
For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
See <link linkend="structure-core-script">oe-init-build-env</link>
for more information on this script.
</para>
<para>
Once the Yocto Project build environment is set up, you can build a target using:
<literallayout class='monospaced'>
$ bitbake &lt;target&gt;
</literallayout>
</para>
</literallayout>
</para>
<para>
The <filename>target</filename> is the name of the recipe you want to build.
Common targets are the images in <filename>meta/recipes-core/images</filename>,
<filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
files.
Or, the target can be the name of a recipe for a specific piece of software such as
<application>busybox</application>.
For more details about the images Yocto Project supports, see the
<link linkend="ref-images">'Reference: Images'</link> appendix.
</para>
<para>
The <filename>target</filename> is the name of the recipe you want to build.
Common targets are the images in <filename>meta/recipes-core/images</filename>,
<filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
files.
Or, the target can be the name of a recipe for a specific piece of software such as
<application>busybox</application>.
For more details about the images Yocto Project supports, see the
<link linkend="ref-images">'Reference: Images'</link> appendix.
</para>
<note>
Building an image without GNU Public License Version 3 (GPLv3) components is
only supported for minimal and base images.
See <link linkend='ref-images'>'Reference: Images'</link> for more information.
</note>
<note>
Building an image without GNU Public License Version 3 (GPLv3) components is
only supported for minimal and base images.
See <link linkend='ref-images'>'Reference: Images'</link> for more information.
</note>
</section>
<note>
When building an image using GPL components, you need to maintain your original
settings and not switch back and forth applying different versions of the GNU
Public License.
If you rebuild using different versions of GPL, dependency errors might occur
due to some components not being rebuilt.
</note>
<section id='building-an-image-using-gpl-components'>
<title>Building an Image Using GPL Components</title>
<para>
When building an image using GPL components, you need to maintain your original
settings and not switch back and forth applying different versions of the GNU
Public License.
If you rebuild using different versions of GPL, dependency errors might occur
due to some components not being rebuilt.
</para>
</section>
</section>
<section id='usingpoky-install'>
@ -219,9 +93,9 @@
<filename class="directory">tmp/deploy/images</filename>.
For information on how to run pre-built images such as <filename>qemux86</filename>
and <filename>qemuarm</filename>, see the
<ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
Using Pre-Built Binaries and QEMU</ulink> section in the
<ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink>.
For information about how to install these images, see the documentation for your
particular board/machine.

View File

@ -6,7 +6,7 @@
<section id='fake-title'>
<title>Yocto Project Quick Start</title>
<para>Copyright &copy; 2010-2011 Linux Foundation</para>
<para>Copyright &copy; 2010-2012 Linux Foundation</para>
</section>
<section id='welcome'>
@ -21,7 +21,7 @@
<para>
This short document will give you some basic information about the environment as well
as let you experience it in its simplest form.
After reading this document you will have a basic understanding of what the Yocto Project is
After reading this document, you will have a basic understanding of what the Yocto Project is
and how to use some of its core components.
This document steps you through a simple example showing you how to build a small image
and run it using the QEMU emulator.
@ -29,20 +29,21 @@
<para>
For complete information on the Yocto Project, you should check out the
<ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
You can find the latest builds, breaking news, full development documentation, and a
Through the website, you can find the latest builds, breaking news, full development
documentation, and a
rich Yocto Project Development Community into which you can tap.
</para>
<para>
Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and
the FAQ appendix located in the
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink> helpful.
the FAQ appendix located in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink> helpful.
</para>
<note>
Due to production processes, there could be differences between the Yocto Project
documentation bundled in the release tarball and the
<ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
<ulink url='http://www.yoctoproject.org/docs/1.1.1/yocto-project-qs/yocto-project-qs.html'>
Yocto Project Quick Start</ulink> on
the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
For the latest version of this manual, see the manual on the website.
@ -74,7 +75,7 @@
</mediaobject>
<para>
Yocto Project:
Here are some highlights for the Yocto Project:
</para>
<itemizedlist>
@ -85,7 +86,7 @@
<para>Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter,
GuPNP and Qt (among others) so you can create a richer user interface experience on
devices that use displays or have a GUI.
For devices that don't have a GUI or display you simply would not employ these
For devices that don't have a GUI or display, you simply would not employ these
components.</para>
</listitem>
<listitem>
@ -100,9 +101,9 @@
<para>
The Yocto Project can generate images for many kinds of devices.
However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS,
and PPC-based architectures as well as specific hardware such as the Intel Desktop Board
DH55TC.
However, the standard example machines target QEMU full-system emulation for x86, x86-64, ARM, MIPS,
and PPC-based architectures as well as specific hardware such as the
<trademark class='registered'>Intel</trademark> Desktop Board DH55TC.
Because an image developed with the Yocto Project can boot inside a QEMU emulator, the
development environment works nicely as a test platform for developing embedded software.
</para>
@ -113,7 +114,7 @@
restricted screen sizes, sits neatly on top of a device using the
GNOME Mobile Stack and provides a well-defined user experience.
Implemented in its own layer, it makes it clear to developers how they can implement
their own UIs on top of Yocto Linux.
their own user interface on top of Yocto Linux.
</para>
</section>
@ -128,11 +129,10 @@
<listitem>
<para>A host system running a supported Linux distribution (i.e. recent releases of
Fedora, openSUSE, Debian, and Ubuntu).
<note>
For notes about using the Yocto Project on development systems that use
older Linux distributions see
<ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink>
</note></para>
If the host system supports multiple cores and threads, you can configure the
Yocto Project build system to decrease the time needed to build images
significantly.
</para>
</listitem>
<listitem>
<para>The right packages.</para>
@ -146,15 +146,23 @@
<title>The Linux Distribution</title>
<para>
The Yocto Project has been tested and is known to work on the current releases minus one
of the following distributions.
Follow this <ulink url='https://wiki.pokylinux.org/wiki/Distro_Test'>link </ulink> for more
information on distribution testing.
The Yocto Project team is continually verifying more and more Linux
distributions with each release.
In general, if you have the current release minus one of the following
distributions you should have no problems.
<itemizedlist>
<listitem><para>Ubuntu</para></listitem>
<listitem><para>Fedora</para></listitem>
<listitem><para>openSUSE</para></listitem>
</itemizedlist>
For a list of the distributions under validation and their status, see the
<ulink url='https://wiki.yoctoproject.org/wiki/Distribution_Support'>Distribution
Support</ulink> wiki page.
<note>
For notes about using the Yocto Project on a RHEL 4-based host, see the
<ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
wiki page.
</note>
</para>
<para>
The build system should be able to run on any modern distribution with Python 2.6 or 2.7.
@ -168,7 +176,7 @@
Refer to
<ulink url='http://openembedded.net/index.php?title=OEandYourDistro&amp;action=historysubmit&amp;diff=4309&amp;okdid=4225'>OE and Your Distro</ulink> and
<ulink url='http://openembedded.net/index.php?title=Required_software&amp;action=historysubmit&amp;diff=4311&amp;oldid=4251'>Required Software</ulink>
for information for other distributions used with the Open Embedded project, which might be
for information for other distributions used with the OpenEmbedded project, which might be
a starting point for exploration.
If you go down this path, you should expect problems.
When you do, please go to <ulink url='http://bugzilla.yoctoproject.org'>Yocto Project Bugzilla</ulink>
@ -183,56 +191,85 @@
<para>
Packages and package installation vary depending on your development system.
In general, you need to have root access and then install the required packages.
The next few sections show you how to get set up with the right packages for
Ubuntu, Fedora, and openSUSE.
</para>
<section id='ubuntu'>
<title>Ubuntu</title>
<note><para>
If you are using a Fedora version prior to version 15 you will need to take some
extra steps to enable <filename>sudo</filename>.
See <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'></ulink> for details.
</para></note>
<para>
If your distribution is Ubuntu, you need to be running the bash shell.
You can be sure you are running this shell by entering the following command and
selecting "No" at the prompt:
<literallayout class='monospaced'>
$ sudo dpkg-reconfigure dash
</literallayout>
</para>
<para>
The packages you need for a Debian-based host are shown in the following command:
</para>
<para>
The packages you need for a supported Ubuntu distribution are shown in the following command:
</para>
<literallayout class='monospaced'>
<literallayout class='monospaced'>
$ sudo apt-get install sed wget cvs subversion git-core coreutils \
unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
python-pysqlite2 diffstat help2man make gcc build-essential \
g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
mercurial autoconf automake groff libtool xterm
</literallayout>
</literallayout>
</section>
<para>
The packages you need for an RPM-based host like Fedora and openSUSE,
respectively, are as follows:
</para>
<section id='fedora'>
<title>Fedora</title>
<literallayout class='monospaced'>
<para>
The packages you need for a supported Fedora distribution are shown in the following
commands:
</para>
<literallayout class='monospaced'>
$ sudo yum groupinstall "development tools"
$ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
unzip python-psyco perl texinfo texi2html diffstat openjade \
docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
docbook-utils sed bc glibc-devel ccache pcre pcre-devel quilt \
docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
autoconf automake libtool xterm
</literallayout>
</literallayout>
<literallayout class='monospaced'>
<note><para>
If you are using a Fedora version prior to version 15, you will need to take some
extra steps to enable <filename>sudo</filename>, or you will need to run
the commands as root user.
See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink>
wiki page for details.
</para></note>
</section>
<section id='opensuse'>
<title>openSUSE</title>
<para>
The packages you need for a supported openSUSE distribution are shown in the following
command:
</para>
<literallayout class='monospaced'>
$ sudo zypper install python gcc gcc-c++ libtool \
subversion git chrpath automake \
help2man diffstat texinfo mercurial wget
</literallayout>
subversion git chrpath automake make wget help2man \
diffstat texinfo mercurial freeglut-devel libSDL-devel
</literallayout>
</section>
</section>
<section id='releases'>
<title>Yocto Project Release</title>
<para>
You can download the latest release images for the Yocto Project on the
You can download the latest Yocto Project release by going to the
<ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
Just go to the page and click the "Yocto Downloads" link found in the "Download"
navigation pane to the right to view all available Yocto Project releases.
@ -242,6 +279,17 @@
<ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.
However, for this document a released version of Yocto Project is used.
</para>
<para>
You can also get the Yocto Project files by setting up a Git repository on your host
development system.
Doing so allows you to contribute back to the project.
For information on how to get set up using this method, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-yp-release'>Yocto
Project Release</ulink>" item in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The Yocto Project
Development Manual</ulink>.
</para>
</section>
</section>
@ -249,16 +297,16 @@
<title>A Quick Test Run</title>
<para>
Now that you have your system requirements in order you can give Yocto Project a try.
Now that you have your system requirements in order, you can give Yocto Project a try.
This section presents some steps that let you do the following:
</para>
<itemizedlist>
<listitem>
<para>Build an image and run it in the emulator</para>
<para>Build an image and run it in the QEMU emulator</para>
</listitem>
<listitem>
<para>Or, use a pre-built image and run it in the emulator</para>
<para>Use a pre-built image and run it in the QEMU emulator</para>
</listitem>
</itemizedlist>
@ -266,7 +314,8 @@
<title>Building an Image</title>
<para>
In the development environment you will need to build an image whenever you change hardware support, add or change system libraries, or add or change services that have dependencies.
In the development environment you will need to build an image whenever you change hardware
support, add or change system libraries, or add or change services that have dependencies.
</para>
<mediaobject>
@ -295,22 +344,23 @@
through a set of locations.
If you encounter problems with the Yocto Project finding and downloading source code, see
the FAQ entry "How does Poky obtain source code and will it work behind my
firewall or proxy server?" in the
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink>.
firewall or proxy server?" in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.
</para></note>
<para>
<literallayout class='monospaced'>
$ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2
$ tar xjf poky-bernard-5.0.1.tar.bz2
$ source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build
$ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/poky-edison-6.0.1.tar.bz2
$ tar xjf poky-edison-6.0.1.tar.bz2
$ source poky-edison-6.0.1/oe-init-build-env edison-6.0.1-build
</literallayout>
</para>
<tip><para>
To help conserve disk space during builds you can add the following statement
to your <filename>local.conf</filename> file.
To help conserve disk space during builds, you can add the following statement
to your project's configuration file, which for this example
is <filename>edison-6.0.1-build/conf/local.conf</filename>.
Adding this statement deletes the work directory used for building a package
once the package is built.
<literallayout class='monospaced'>
@ -319,25 +369,53 @@
</para></tip>
<itemizedlist>
<listitem><para>The first two commands extract the Yocto Project files from the
release tarball and place them into a subdirectory of your current directory.</para></listitem>
<listitem><para>The <command>source</command> command creates the
<filename>poky-5.0.1-build</filename> directory and executes the <command>cd</command>
command to make <filename>poky-5.0.1-build</filename> the working directory.
The resulting build directory contains all the files created during the build.
By default the target architecture is qemux86.
To change this default, edit the value of the MACHINE variable in the
<filename>conf/local.conf</filename> file.</para></listitem>
<listitem><para>In the previous example, the first command retrieves the Yocto Project
release tarball from the source repositories using the
<filename>wget</filename> command.
Alternatively, you can go to the
<ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink>
Downloads page to retrieve the tarball.</para></listitem>
<listitem><para>The second command extracts the files from the tarball and places
them into a directory named <filename>poky-edison-6.0.1</filename> in the current
directory.</para></listitem>
<listitem><para>The third command runs the Yocto Project environment setup script.
Running this script defines Yocto Project build environment settings needed to
complete the build.
The script also creates the Yocto Project
build directory, which is <filename>edison-6.0.1-build</filename> in this case.
After the script runs, your current working directory is set
to the build directory.
Later, when the build completes, the build directory contains all the files
created during the build.
</para></listitem>
</itemizedlist>
<para>
Take some time to examine your <filename>conf/local.conf</filename> file found in the
Yocto Project file's <filename>conf</filename>.
The defaults should work fine.
However, if you have a multi-core CPU you might want to set the variable
BB_NUMBER_THREADS equal to twice the number of processor cores your system has.
And, set the variable PARALLEL_MAKE equal to the number of processor cores.
Take some time to examine your <filename>local.conf</filename> file
in your project's configuration directory.
The defaults in that file should work fine.
However, there are some variables of interest at which you might look.
</para>
<para>
By default, the target architecture for the build is <filename>qemux86</filename>,
which produces an image that can be used in the QEMU emulator and is targeted at an
<trademark class='registered'>Intel</trademark> 32-bit based architecture.
To change this default, edit the value of the <filename>MACHINE</filename> variable
in the configuration file before launching the build.
</para>
<para>
Another couple of variables of interest are the
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
By default, these variables are commented out.
However, if you have a multi-core CPU you might want to uncomment
the lines and set the variable
<filename>BB_NUMBER_THREADS</filename> equal to twice the number of your
host's processor cores.
Also, you could set the variable <filename>PARALLEL_MAKE</filename> equal to
1.5 times the number of processor cores.
Setting these variables can significantly shorten your build time.
By default, these variables are commented out.
</para>
<para>
@ -345,28 +423,28 @@
the image.
By default, the Yocto Project build system uses the RPM package manager.
You can control this configuration by using the
<filename><ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'>PACKAGE_CLASSES</ulink></filename> variable.
<filename><ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.
For additional package manager selection information, see
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.
</para>
<para>
Continue with the following command to build an OS image for the target, which is
<filename>core-image-sato</filename> in this example.
For information on the <filename>&dash;k</filename> option use the
<filename>bitbake --help</filename> command or see
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>
BitBake</ulink> section in the Yocto Project Reference Manual.
For information on the <filename>-k</filename> option use the
<filename>bitbake --help</filename> command or see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
<literallayout class='monospaced'>
$ bitbake -k core-image-sato
</literallayout>
<note><para>
BitBake requires Python 2.6 or 2.7. For more information on this requirement,
see the FAQ appendix in the
<ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
Yocto Project Reference Manual</ulink>.
see the FAQ appendix in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html'>
The Yocto Project Reference Manual</ulink>.
</para></note>
The final command runs the image:
<literallayout class='monospaced'>
@ -383,16 +461,13 @@
<section id='using-pre-built'>
<title>Using Pre-Built Binaries and QEMU</title>
<para>
If hardware, libraries and services are stable you can get started by using a pre-built binary
of the image, kernel and toolchain and run it using the emulator QEMU.
If hardware, libraries and services are stable, you can get started by using a pre-built binary
of the filesystem image, kernel, and toolchain and run it using the QEMU emulator.
This scenario is useful for developing application software.
</para>
<para></para>
<para></para>
<para></para>
<mediaobject>
<imageobject>
<imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
@ -400,54 +475,39 @@
<caption>
<para>Using a Pre-Built Image</para>
</caption>
</mediaobject>
</mediaobject>
<para>
For this scenario you need to do several things:
</para>
<para>
For this scenario, you need to do several things:
</para>
<itemizedlist>
<listitem>
<para>
Install the stand-alone Yocto toolchain tarball.
</para>
</listitem>
<listitem>
<para>
Download the pre-built kernel that will boot with QEMU.
You need to be sure to get the QEMU image that matches your target machines
architecture (e.g. x86, ARM, etc.).
</para>
</listitem>
<listitem>
<para>
Download the filesystem image for your target machine's architecture.
</para>
</listitem>
<listitem>
<para>
Set up the environment to emulate the hardware and then start the QEMU emulator.
</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem>
<listitem><para>Download the pre-built image that will boot with QEMU.
You need to be sure to get the QEMU image that matches your target machines
architecture (e.g. x86, ARM, etc.).</para></listitem>
<listitem><para>Download the filesystem image for your target machine's architecture.
</para></listitem>
<listitem><para>Set up the environment to emulate the hardware and then start the QEMU emulator.
</para></listitem>
</itemizedlist>
<section id='installing-the-toolchain'>
<title>Installing the Toolchain</title>
<para>
You can download the pre-built toolchain, which includes the <filename>runqemu</filename>
script and support files, from
<ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>.
Toolchains are available for 32-bit and 64-bit development systems from the
<filename>i686</filename> and <filename>x86_64</filename> folders, respectively.
Each type of development system supports five target architectures.
The tarball files are named such that a string representing the host system appears
first in the filename and then is immediately followed by a string representing
the target architecture.
</para>
<title>Installing the Toolchain</title>
<para>
You can download the pre-built toolchain, which includes the <filename>runqemu</filename>
script and support files, from the appropriate directory under
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/'></ulink>.
Toolchains are available for 32-bit and 64-bit development systems from the
<filename>i686</filename> and <filename>x86_64</filename> directories, respectively.
Each type of development system supports five target architectures.
The tarball files are named such that a string representing the host system appears
first in the filename and then is immediately followed by a string representing
the target architecture.
</para>
<literallayout class='monospaced'>
yocto-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
<literallayout class='monospaced'>
poky-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
Where:
&lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
@ -457,101 +517,113 @@
i586, x86_64, powerpc, mips, or arm.
&lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
</literallayout>
</literallayout>
<para>
For example, the following toolchain tarball is for a 64-bit development
host system and a 32-bit target architecture:
</para>
<para>
For example, the following toolchain tarball is for a 64-bit development
host system and a 32-bit target architecture:
</para>
<literallayout class='monospaced'>
yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
</literallayout>
<literallayout class='monospaced'>
poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
</literallayout>
<para>
The toolchain tarballs are self-contained and must be installed into <filename>/opt/poky</filename>.
The following commands show how you install the toolchain tarball given a 64-bit development host system
and a 32-bit target architecture.
The example assumes the toolchain tarball is located in <filename>~/toolchains/</filename>:
</para>
<para>
The toolchain tarballs are self-contained and must be installed into <filename>/opt/poky</filename>.
The following commands show how you install the toolchain tarball given a 64-bit development host system
and a 32-bit target architecture.
The example assumes the toolchain tarball is located in <filename>~/toolchains/</filename>:
</para>
<para>
<literallayout class='monospaced'>
<para>
<literallayout class='monospaced'>
$ cd /
$ sudo tar -xvjf ~/toolchains/yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
</literallayout>
</para>
</section>
$ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.1.tar.bz2
</literallayout>
</para>
<para>
For more information on how to install tarballs, see the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in
<ulink url='http://www.yoctoproject.org/docs/1.1.1/adt-manual/adt-manual.html'>The Yocto Project
Application Development Toolkit (ADT) User's Guide</ulink>.
</para>
</section>
<section id='downloading-the-pre-built-linux-kernel'>
<title>Downloading the Pre-Built Linux Kernel</title>
<para>
You can download the pre-built Linux kernel and the filesystem image suitable for
running in the emulator QEMU from
<ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>.
Be sure to use the kernel and filesystem image that matches the architecture you want
to simulate.
Download areas exist for the five supported machine architectures:
<filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
<filename>qemux86</filename>, and <filename>qemux86_64</filename>.
</para>
<para>
Most kernel files have one of the following forms:
</para>
<literallayout class='monospaced'>
*zImage-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
vmlinux-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
<title>Downloading the Pre-Built Linux Kernel</title>
<para>
You can download the pre-built Linux kernel suitable for running in the QEMU emulator from
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
Be sure to use the kernel that matches the architecture you want to simulate.
Download areas exist for the five supported machine architectures:
<filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
<filename>qemux86</filename>, and <filename>qemux86_64</filename>.
</para>
<para>
Most kernel files have one of the following forms:
<literallayout class='monospaced'>
*zImage-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
vmlinux-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
Where:
&lt;<emphasis>kernel-rev</emphasis>&gt; is the base Linux kernel revision
(e.g. 2.6.37).
&lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
x86, x86-64, ppc, mips, or arm.
</literallayout>
</para>
&lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
</literallayout>
</section>
<para>
You can learn more about downloading a Yocto Project kernel in the
"<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of
<ulink url='http://www.yoctoproject.org/docs/1.1.1/dev-manual/dev-manual.html'>The
Yocto Project Development Manual</ulink>.
</para>
</section>
<section id='downloading-the-filesystem'>
<title>Downloading the Filesystem</title>
<para>
The filesystem image has two tarball forms: <filename>ext3</filename> and
<filename>tar</filename>.
You must use the <filename>ext3</filename> form when booting an image using the
QEMU emulator.
The <filename>tar</filename> form can be flattened out in your host development system
and used for Yocto Project build purposes.
</para>
<title>Downloading the Filesystem</title>
<literallayout class='monospaced'>
yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.ext3.bz2
yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.tar.bz2
<para>
You can also download the filesystem image suitable for your target architecture from
<ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/machines/qemu'></ulink>.
Again, be sure to use the filesystem that matches the architecture you want
to simulate.
</para>
<para>
The filesystem image has two tarball forms: <filename>ext3</filename> and
<filename>tar</filename>.
You must use the <filename>ext3</filename> form when booting an image using the
QEMU emulator.
The <filename>tar</filename> form can be flattened out in your host development system
and used for Yocto Project build purposes.
<literallayout class='monospaced'>
core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
Where:
&lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
For information on these types of image profiles, see
<ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
<ulink url='http://www.yoctoproject.org/docs/1.1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
&lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
x86, x86-64, ppc, mips, or arm.
&lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
</literallayout>
</section>
</literallayout>
</para>
</section>
<section id='setting-up-the-environment-and-starting-the-qemu-emulator'>
<title>Setting Up the Environment and Starting the QEMU Emulator</title>
<para>
Before you start the QEMU emulator you need to set up the emulation environment.
The following command form sets up the emulation environment.
</para>
<literallayout class='monospaced'>
$ source /opt/poky/1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt;
<title>Setting Up the Environment and Starting the QEMU Emulator</title>
<para>
Before you start the QEMU emulator, you need to set up the emulation environment.
The following command form sets up the emulation environment.
<literallayout class='monospaced'>
$ source /opt/poky/1.1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt;
Where:
&lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
@ -559,13 +631,12 @@
&lt;<emphasis>if</emphasis>&gt; is a string representing an embedded application binary interface.
Not all setup scripts include this string.
</literallayout>
</literallayout>
</para>
<para>
Finally, this command form invokes the QEMU emulator
</para>
<literallayout class='monospaced'>
<para>
Finally, this command form invokes the QEMU emulator
<literallayout class='monospaced'>
$ runqemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel-image</emphasis>&gt; &lt;<emphasis>filesystem-image</emphasis>&gt;
Where:
@ -576,33 +647,33 @@
&lt;<emphasis>filesystem-image</emphasis>&gt; is the .ext3 filesystem image.
</literallayout>
</literallayout>
</para>
<para>
Continuing with the example, the following two commands setup the emulation
environment and launch QEMU.
This example assumes the root filesystem tarball has been downloaded and expanded, and
that the kernel and filesystem are for a 32-bit target architecture.
</para>
<para>
Continuing with the example, the following two commands setup the emulation
environment and launch QEMU.
This example assumes the toolchain tarball has been downloaded and expanded
into <filename>/opt/poky</filename> and
that the kernel and filesystem are for a 32-bit target architecture.
<literallayout class='monospaced'>
$ source /opt/poky/1.1.1/environment-setup-i586-poky-linux
$ runqemu qemux86 bzImage-3.0-qemux86-1.1.1.bin \
core-image-sato-qemux86.ext3
</literallayout>
</para>
<literallayout class='monospaced'>
$ source /opt/poky/1.1/environment-setup-i686-poky-linux
$ runqemu qemux86 bzImage-3.0-qemux86-1.1.bin \
yocto-image-sato-qemux86-1.1.rootfs.ext3
</literallayout>
<para>
The environment in which QEMU launches varies depending on the filesystem image and on the
target architecture. For example, if you source the environment for the ARM target
architecture and then boot the minimal QEMU image, the emulator comes up in a new
shell in command-line mode. However, if you boot the SDK image QEMU comes up with
a GUI.
</para>
<note><para>
Booting the PPC image results in QEMU launching in the same shell in command-line mode.
</para></note>
</section>
<para>
The environment in which QEMU launches varies depending on the filesystem image and on the
target architecture.
For example, if you source the environment for the ARM target
architecture and then boot the minimal QEMU image, the emulator comes up in a new
shell in command-line mode.
However, if you boot the SDK image, QEMU comes up with a GUI.
<note>Booting the PPC image results in QEMU launching in the same shell in
command-line mode.</note>
</para>
</section>
</section>
</section>

View File

@ -17,13 +17,12 @@ PACKAGES =+ "${PN}-user3"
inherit useradd
# Specify which package(s) should include the user/group code.
# Make sure that any packages which install files owned by custom
# users/groups are included here. The code which adds users and
# groups is idempotent.
# You must set USERADD_PACKAGES when you inherit useradd. This
# lists which output packages will include the user/group
# creation code.
USERADD_PACKAGES = "${PN} ${PN}-user3"
# You *must* set USERADD_PARAM and/or GROUPADD_PARAM when
# You must also set USERADD_PARAM and/or GROUPADD_PARAM when
# you inherit useradd.
# USERADD_PARAM specifies command line options to pass to the

View File

@ -0,0 +1,14 @@
# This file is for getting archiving packages with configured sources(archive 's' after configure stage),logs(archive 'temp' after package_write_rpm),dump data
# and creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
inherit archiver
# Get archiving package with configured sources including patches
do_configure[postfuncs] += "do_archive_configured_sources "
# Get archiving package with temp(logs) and scripts(.bb and inc files)
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
# Get dump date and create diff file
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "

View File

@ -0,0 +1,14 @@
# This file is for getting archiving packages with original sources(archive 's' after unpack stage),patches,logs(archive 'temp' after package_write_rpm),dump data and
# creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
inherit archiver
# Get original sources archiving package with patches
do_unpack[postfuncs] += "do_archive_original_sources_patches "
# Get archiving package with temp(logs) and scripts(.bb and inc files)
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
# Get dump date and create diff file
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "

View File

@ -0,0 +1,14 @@
# This file is for getting archiving packages with patched sources(archive 's' before do_patch stage),logs(archive 'temp' after package_write_rpm),dump data and
# creating diff file(get all environment variables and functions in building and mapping all content in 's' including patches to xxx.diff.gz.
# All archived packages will be deployed in ${DEPLOY_DIR}/sources
inherit archiver
# Get archiving package with patched sources including patches
do_patch[postfuncs] += "do_archive_patched_sources "
# Get archiving package with logs(temp) and scripts(.bb and .inc files)
do_package_write_rpm[prefuncs] += "do_archive_scripts_logs "
# Get dump date and create diff file
do_package_write_rpm[postfuncs] += "do_dumpdata_create_diff_gz "

View File

@ -0,0 +1,450 @@
# This file is used for archiving sources ,patches,and logs to tarball.
# It also output building environment to xxx.dump.data and create xxx.diff.gz to record
# all content in ${S} to a diff file.
ARCHIVE_EXCLUDE_FROM ?= ".pc autom4te.cache"
ARCHIVE_TYPE ?= "TAR SRPM"
DISTRO ?= "poky"
PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
def get_bb_inc(d):
'''create a directory "script-logs" including .bb and .inc file in ${WORKDIR}'''
import re
import os
import shutil
bbinc = []
pat=re.compile('require\s*([^\s]*\.*)(.*)')
work_dir = d.getVar('WORKDIR', True)
bbfile = d.getVar('FILE', True)
bbdir = os.path.dirname(bbfile)
script_logs = os.path.join(work_dir,'script-logs')
bb_inc = os.path.join(script_logs,'bb_inc')
bb.mkdirhier(script_logs)
bb.mkdirhier(bb_inc)
def find_file(dir,file):
for root, dirs, files in os.walk(dir):
if file in files:
return os.path.join(root,file)
def get_inc (file):
f = open(file,'r')
for line in f.readlines():
if 'require' not in line:
bbinc.append(file)
else:
try:
incfile = pat.match(line).group(1)
incfile = bb.data.expand(os.path.basename(incfile),d)
abs_incfile = find_file(bbdir,incfile)
if abs_incfile:
bbinc.append(abs_incfile)
get_inc(abs_incfile)
except AttributeError:
pass
get_inc(bbfile)
bbinc = list(set(bbinc))
for bbincfile in bbinc:
shutil.copy(bbincfile,bb_inc)
try:
bb.mkdirhier(os.path.join(script_logs,'temp'))
oe.path.copytree(os.path.join(work_dir,'temp'), os.path.join(script_logs,'temp'))
except (IOError,AttributeError):
pass
return script_logs
def get_series(d):
'''copy patches and series file to a pointed directory which will be archived to tarball in ${WORKDIR}'''
import shutil
src_patches=[]
pf = d.getVar('PF', True)
work_dir = d.getVar('WORKDIR', True)
s = d.getVar('S',True)
dest = os.path.join(work_dir, pf + '-series')
shutil.rmtree(dest, ignore_errors=True)
bb.mkdirhier(dest)
src_uri = d.getVar('SRC_URI', True).split()
fetch = bb.fetch2.Fetch(src_uri, d)
locals = (fetch.localpath(url) for url in fetch.urls)
for local in locals:
src_patches.append(local)
if not cmp(work_dir,s):
tmp_list = src_patches
else:
tmp_list = src_patches[1:]
for patch in tmp_list:
try:
shutil.copy(patch,dest)
except IOError:
if os.path.isdir(patch):
bb.mkdirhier(os.path.join(dest,patch))
oe.path.copytree(patch, os.path.join(dest,patch))
return dest
def get_applying_patches(d):
"""only copy applying patches to a pointed directory which will be archived to tarball"""
import os
import shutil
pf = d.getVar('PF', True)
work_dir = d.getVar('WORKDIR', True)
dest = os.path.join(work_dir, pf + '-patches')
shutil.rmtree(dest, ignore_errors=True)
bb.mkdirhier(dest)
patches = src_patches(d)
for patch in patches:
_, _, local, _, _, parm = bb.decodeurl(patch)
if local:
shutil.copy(local,dest)
return dest
def not_tarball(d):
'''packages including key words 'work-shared','native', 'task-' will be passed'''
import os
workdir = d.getVar('WORKDIR',True)
s = d.getVar('S',True)
if 'work-shared' in s or 'task-' in workdir or 'native' in workdir:
return True
else:
return False
def get_source_from_downloads(d,stage_name):
'''copy tarball of $P to $WORKDIR when this tarball exists in $DL_DIR'''
if stage_name in 'patched' 'configured':
return
pf = d.getVar('PF', True)
dl_dir = d.getVar('DL_DIR',True)
try:
source = os.path.join(dl_dir,os.path.basename(d.getVar('SRC_URI', True).split()[0]))
if os.path.exists(source) and not os.path.isdir(source):
return source
except (IndexError, OSError):
pass
return ''
def do_tarball(workdir,srcdir,tarname):
'''tar "srcdir" under "workdir" to "tarname"'''
import tarfile
sav_dir = os.getcwd()
os.chdir(workdir)
if (len(os.listdir(srcdir))) != 0:
tar = tarfile.open(tarname, "w:gz")
tar.add(srcdir)
tar.close()
else:
tarname = ''
os.chdir(sav_dir)
return tarname
def archive_sources_from_directory(d,stage_name):
'''archive sources codes tree to tarball when tarball of $P doesn't exist in $DL_DIR'''
import shutil
s = d.getVar('S',True)
work_dir=d.getVar('WORKDIR', True)
PF = d.getVar('PF',True)
tarname = PF + '-' + stage_name + ".tar.gz"
if os.path.exists(s) and work_dir in s:
try:
source_dir = os.path.join(work_dir,[ i for i in s.replace(work_dir,'').split('/') if i][0])
except IndexError:
if not cmp(s,work_dir):
return ''
else:
return ''
source = os.path.basename(source_dir)
return do_tarball(work_dir,source,tarname)
def archive_sources(d,stage_name):
'''copy tarball from $DL_DIR to $WORKDIR if have tarball, archive source codes tree in $WORKDIR if $P is directory instead of tarball'''
import shutil
work_dir = d.getVar('WORKDIR',True)
file = get_source_from_downloads(d,stage_name)
if file:
shutil.copy(file,work_dir)
file = os.path.basename(file)
else:
file = archive_sources_from_directory(d,stage_name)
return file
def archive_patches(d,patchdir,series):
'''archive patches to tarball and also include series files if 'series' is True'''
import shutil
s = d.getVar('S',True)
work_dir = d.getVar('WORKDIR', True)
patch_dir = os.path.basename(patchdir)
tarname = patch_dir + ".tar.gz"
if series == 'all' and os.path.exists(os.path.join(s,'patches/series')):
shutil.copy(os.path.join(s,'patches/series'),patchdir)
tarname = do_tarball(work_dir,patch_dir,tarname)
shutil.rmtree(patchdir, ignore_errors=True)
return tarname
def select_archive_patches(d,option):
'''select to archive all patches including non-applying and series or applying patches '''
if option == "all":
patchdir = get_series(d)
elif option == "applying":
patchdir = get_applying_patches(d)
try:
os.rmdir(patchdir)
except OSError:
tarpatch = archive_patches(d,patchdir,option)
return tarpatch
return
def archive_logs(d,logdir,bbinc=False):
'''archive logs in temp to tarball and .bb and .inc files if bbinc is True '''
import shutil
pf = d.getVar('PF',True)
work_dir = d.getVar('WORKDIR',True)
log_dir = os.path.basename(logdir)
tarname = pf + '-' + log_dir + ".tar.gz"
tarname = do_tarball(work_dir,log_dir,tarname)
if bbinc:
shutil.rmtree(logdir, ignore_errors=True)
return tarname
def get_licenses(d):
'''get licenses for running .bb file'''
licenses = d.getVar('LICENSE', 1).replace('&', '|')
licenses = licenses.replace('(', '').replace(')', '')
clean_licenses = ""
for x in licenses.split():
if x.strip() == '' or x == 'CLOSED':
continue
if x != "|":
clean_licenses += x
if '|' in clean_licenses:
clean_licenses = clean_licenses.replace('|','')
return clean_licenses
def move_tarball_deploy(d,tarball_list):
'''move tarball in location to ${DEPLOY_DIR}/sources'''
import shutil
if tarball_list is []:
return
target_sys = d.getVar('TARGET_SYS', True)
pf = d.getVar('PF', True)
licenses = get_licenses(d)
work_dir = d.getVar('WORKDIR',True)
tar_sources = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
if not os.path.exists(tar_sources):
bb.mkdirhier(tar_sources)
for source in tarball_list:
if source:
if os.path.exists(os.path.join(tar_sources, source)):
os.remove(os.path.join(tar_sources,source))
shutil.move(os.path.join(work_dir,source),tar_sources)
def check_archiving_type(d):
'''check the type for archiving package('tar' or 'srpm')'''
try:
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in d.getVar('ARCHIVE_TYPE', True).split():
raise AttributeError
except AttributeError:
bb.fatal("\"SOURCE_ARCHIVE_PACKAGE_TYPE\" is \'tar\' or \'srpm\', no other types")
def store_package(d,package_name):
'''store tarbablls name to file "tar-package"'''
try:
f = open(os.path.join(d.getVar('WORKDIR',True),'tar-package'),'a')
f.write(package_name + ' ')
f.close()
except IOError:
pass
def get_package(d):
'''get tarballs name from "tar-package"'''
work_dir = (d.getVar('WORKDIR', True))
tarpackage = os.path.join(work_dir,'tar-package')
try:
f = open(tarpackage,'r')
line = list(set(f.readline().replace('\n','').split()))
except IOError:
pass
f.close()
return line
def archive_sources_patches(d,stage_name):
'''archive sources and patches to tarball. stage_name will append strings ${stage_name} to ${PR} as middle name. for example, zlib-1.4.6-prepatch(stage_name).tar.gz '''
import shutil
check_archiving_type(d)
if not_tarball(d):
return
source_tar_name = archive_sources(d,stage_name)
if stage_name == "prepatch":
if d.getVar('PATCHES_ARCHIVE_WITH_SERIES',True).upper() == 'TRUE':
patch_tar_name = select_archive_patches(d,"all")
elif d.getVar('PATCHES_ARCHIVE_WITH_SERIES',True).upper() == 'FALSE':
patch_tar_name = select_archive_patches(d,"applying")
else:
bb.fatal("Please define 'PATCHES_ARCHIVE_WITH_SERIES' is strings 'True' or 'False' ")
else:
patch_tar_name = ''
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
move_tarball_deploy(d,[source_tar_name,patch_tar_name])
else:
tarpackage = os.path.join(d.getVar('WORKDIR', True),'tar-package')
if os.path.exists(tarpackage):
os.remove(tarpackage)
for package in os.path.basename(source_tar_name), patch_tar_name:
if package:
store_package(d,str(package) + ' ')
def archive_scripts_logs(d):
'''archive scripts and logs. scripts include .bb and .inc files and logs include stuff in "temp".'''
work_dir = d.getVar('WORKDIR', True)
temp_dir = os.path.join(work_dir,'temp')
source_archive_log_with_scripts = d.getVar('SOURCE_ARCHIVE_LOG_WITH_SCRIPTS', True)
if source_archive_log_with_scripts == 'logs_with_scripts':
logdir = get_bb_inc(d)
tarlog = archive_logs(d,logdir,True)
elif source_archive_log_with_scripts == 'logs':
if os.path.exists(temp_dir):
tarlog = archive_logs(d,temp_dir,False)
else:
return
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
move_tarball_deploy(d,[tarlog])
else:
store_package(d,tarlog)
def dumpdata(d):
'''dump environment to "${P}-${PR}.showdata.dump" including all kinds of variables and functions when running a task'''
workdir = bb.data.getVar('WORKDIR', d, 1)
distro = bb.data.getVar('DISTRO', d, 1)
s = d.getVar('S', True)
pf = d.getVar('PF', True)
target_sys = d.getVar('TARGET_SYS', True)
licenses = get_licenses(d)
dumpdir = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
if not os.path.exists(dumpdir):
bb.mkdirhier(dumpdir)
dumpfile = os.path.join(dumpdir, bb.data.expand("${P}-${PR}.showdata.dump",d))
bb.note("Dumping metadata into '%s'" % dumpfile)
f = open(dumpfile, "w")
# emit variables and shell functions
bb.data.emit_env(f, d, True)
# emit the metadata which isnt valid shell
for e in d.keys():
if bb.data.getVarFlag(e, 'python', d):
f.write("\npython %s () {\n%s}\n" % (e, bb.data.getVar(e, d, 1)))
f.close()
def create_diff_gz(d):
'''creating .diff.gz in ${DEPLOY_DIR_SRC}/${P}-${PR}.diff.g gz for mapping all content in 's' including patches to xxx.diff.gz'''
import shutil
work_dir = d.getVar('WORKDIR', True)
exclude_from = d.getVar('ARCHIVE_EXCLUDE_FROM', True).split()
pf = d.getVar('PF', True)
licenses = get_licenses(d)
target_sys = d.getVar('TARGET_SYS', True)
diff_dir = d.getVar('DEPLOY_DIR', True) + '/sources/' + target_sys + '/' + licenses + '/' + pf
diff_file = os.path.join(diff_dir, bb.data.expand("${P}-${PR}.diff.gz",d))
f = open(os.path.join(work_dir,'temp/exclude-from-file'), 'a')
for i in exclude_from:
f.write(i)
f.write("\n")
f.close()
s=d.getVar('S', True)
distro = d.getVar('DISTRO',True)
dest = s + '/' + distro + '/files'
if not os.path.exists(dest):
bb.mkdirhier(dest)
for i in os.listdir(os.getcwd()):
if os.path.isfile(i):
try:
shutil.copy(i, dest)
except IOError:
os.system('fakeroot cp -rf ' + i + " " + dest )
bb.note("Creating .diff.gz in ${DEPLOY_DIR_SRC}/${P}-${PR}.diff.gz")
cmd = "LC_ALL=C TZ=UTC0 diff --exclude-from=" + work_dir + "/temp/exclude-from-file -Naur " + s + '.org' + ' ' + s + " | gzip -c > " + diff_file
d.setVar('DIFF', cmd + "\n")
d.setVarFlag('DIFF', 'func', '1')
bb.build.exec_func('DIFF', d)
shutil.rmtree(s + '.org', ignore_errors=True)
# This function will run when user want to get tarball for sources and patches after do_unpack
python do_archive_original_sources_patches(){
archive_sources_patches(d,'prepatch')
}
# This function will run when user want to get tarball for patched sources after do_patch
python do_archive_patched_sources(){
archive_sources_patches(d,'patched')
}
# This function will run when user want to get tarball for configured sources after do_configure
python do_archive_configured_sources(){
archive_sources_patches(d,'configured')
}
# This function will run when user want to get tarball for logs or both logs and scripts(.bb and .inc files)
python do_archive_scripts_logs(){
archive_scripts_logs(d)
}
# This function will run when user want to know what variable and functions in a running task are and also can get a diff file including
# all content a package should include.
python do_dumpdata_create_diff_gz(){
dumpdata(d)
create_diff_gz(d)
}
# This functions prepare for archiving "linux-yocto" because this package create directory 's' before do_patch instead of after do_unpack.
# This is special control for archiving linux-yocto only.
python do_archive_linux_yocto(){
s = d.getVar('S', True)
if 'linux-yocto' in s:
source_tar_name = archive_sources(d,'')
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() not in 'SRPM':
move_tarball_deploy(d,[source_tar_name,''])
}
do_kernel_checkout[postfuncs] += "do_archive_linux_yocto "
# remove tarball for sources, patches and logs after creating srpm.
python do_remove_tarball(){
if d.getVar('SOURCE_ARCHIVE_PACKAGE_TYPE', True).upper() == 'SRPM':
work_dir = d.getVar('WORKDIR', True)
try:
for file in os.listdir(os.getcwd()):
if file in get_package(d):
os.remove(file)
os.remove(os.path.join(work_dir,'tar-package'))
except (TypeError,OSError):
pass
}
do_remove_taball[deptask] = "do_archive_scripts_logs"
do_package_write_rpm[postfuncs] += "do_remove_tarball "
export get_licenses
export get_package

View File

@ -0,0 +1,4 @@
# This will set BTS_HW_VERSION depending on the machine
PACKAGE_ARCH = "${MACHINE_ARCH}"
BTS_HW_VERSION_sysmobts-v1 = "-DHW_SYSMOBTS_V1"
BTS_HW_VERSION_sysmobts-v2 = "-DHW_SYSMOBTS_V2"

View File

@ -0,0 +1,13 @@
# We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES := "${BBFILES} ${LAYERDIR}/yocto-shared/*.bbappend"
BBFILES := "${BBFILES} ${LAYERDIR}/yocto-edison/*.bbappend"
#BBFILES := "${BBFILES} ${LAYERDIR}/yocto-master/*.bbappend"
BBFILE_COLLECTIONS += "sysmocom-bsp"
BBFILE_PATTERN_sysmocom-bsp := "^${LAYERDIR}/"
BBFILE_PRIORITY_sysmocom-bsp = "1"

View File

@ -0,0 +1,2 @@
SOC_FAMILY = "dm6446"

View File

@ -0,0 +1,40 @@
TARGET_ARCH = "arm"
PREFERRED_PROVIDER_virtual/kernel = "linux-sysmocom"
PREFERRED_PROVIDERS += "virtual/${TARGET_PREFIX}depmod:module-init-tools-cross"
PREFERRED_VERSION_u-boot = "git"
KERNEL_IMAGETYPE = "uImage"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"
SERIAL_CONSOLE ?= "115200 ttyS0"
EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"
#ROOT_FLASH_SIZE = "29"
MACHINE_FEATURES = "kernel26 serial"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "\
busybox-ifplugd \
watchdog \
kernel-module-davinci-wdt \
kernel-module-dspdl \
kernel-module-dspdl-dm644x \
kernel-module-fpgadl \
kernel-module-fpgadl-par \
kernel-module-leds-gpio \
kernel-module-msgqueue \
kernel-module-nls-ascii \
kernel-module-nls-utf8 \
kernel-module-rtfifo "
IMAGE_FSTYPES ?= "tar.bz2 cpio.gz ubifs ubi jffs2"
MACHINE_EXTRA_RDEPENDS = "task-sysmocom-bts sysmobts-firmware watchdog"
#MACHINE_EXTRA_RRECOMMENDS = "dsplink-module"
require conf/machine/include/tune-arm926ejs.inc
require conf/machine/include/dm6446.inc

View File

@ -0,0 +1,13 @@
DEFAULTTUNE ?= "geode"
TUNE_PKGARCH ?= "${@bb.utils.contains('TUNE_FEATURES', 'm32', 'geode', '', d)}"
require conf/machine/include/tune-i586.inc
# Extra tune features
TUNEVALID[geode] = "Enable geode specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains('TUNE_FEATURES', 'geode', '-march=geode -mtune=geode', '', d)}"
# Extra tune selections
TUNE_FEATURES_tune-geode ?= "${TUNE_FEATURES_tune-x86} geode"
BASE_LIB_tune-geode ?= "lib"
PACKAGE_EXTRA_ARCHS_tune-geode = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486 i586 geode"

View File

@ -0,0 +1,14 @@
#@TYPE: Machine
#@NAME: sysmocom - systems for mobile communications GmbH GSM BTS
#@DESCRIPTION: sysmocom - systems for mobile communications GmbH GSM BTS
# Make sure we build these too
EXTRA_IMAGEDEPENDS = "dvnixload-native ubl u-boot sysmobts-firmware"
EXTRA_IMAGECMD_jffs2 = "--little-endian --eraseblock=0x20000 --pagesize=0x800 --no-cleanmarkers --pad=0x2000000 -n"
# ubifs config
MKUBIFS_ARGS = "-m 2048 -e 129024 -c 400"
UBINIZE_ARGS = "-m 2048 -p 128KiB -s 512"
require conf/machine/include/sysmobts.inc

View File

@ -0,0 +1,14 @@
#@TYPE: Machine
#@NAME: sysmocom - systems for mobile communications GmbH GSM Superfemto
#@DESCRIPTION: sysmocom - systems for mobile communications GmbH GSM Superfemto
# Make sure we build these too
EXTRA_IMAGEDEPENDS = "dvnixload-native ubl u-boot sysmobts-firmware"
EXTRA_IMAGECMD_jffs2 = "--little-endian --eraseblock=0x20000 --pagesize=0x800 --no-cleanmarkers --pad=0x2000000 -n"
# ubifs config
MKUBIFS_ARGS ?= "-m 2048 -e 129024 -c 400"
UBINIZE_ARGS ?= "-m 2048 -p 128KiB -s 512"
require conf/machine/include/sysmobts.inc

View File

@ -0,0 +1,10 @@
#@TYPE: Machine
#@NAME: common_pc
#@DESCRIPTION: Machine configuration for running a common x86
require sysmocom-bsc.conf
MACHINEOVERRIDES = "${MACHINE}:sysmocom-bsc"
SERIAL_CONSOLE = "19200 ttyS0"
MACHINE_CONSOLE = "console=ttyS0,19200n8"

View File

@ -0,0 +1,37 @@
#@TYPE: Machine
#@NAME: common_pc
#@DESCRIPTION: Machine configuration for running a common x86
TARGET_ARCH = "i586"
PREFERRED_PROVIDER_virtual/libgl = "mesa-dri"
PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
PREFERRED_PROVIDER_virtual/kernel = "linux"
require conf/machine/include/tune-geode.inc
MACHINE_FEATURES += "kernel26 x86 usbhost pci acpi"
KERNEL_IMAGETYPE = "bzImage"
IMAGE_FSTYPES ?= "tar.gz ext3"
SERIAL_CONSOLE = "38400 ttyS0"
MACHINE_CONSOLE = "console=ttyS0,38400n8"
# We bypass swrast but we need it to be present for X to load correctly
XSERVER ?= "xserver-xf86-dri-lite \
mesa-dri-driver-swrast \
xf86-input-vmmouse \
xf86-input-keyboard \
xf86-input-evdev \
xf86-video-vmware"
GLIBC_ADDONS = "nptl"
GLIBC_EXTRA_OECONF = "--with-tls"
#MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d"
MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "\
busybox-ifplugd "

View File

@ -0,0 +1,19 @@
SYSMOCOM := "${@os.path.dirname(bb.data.getVar('FILE', d, True))}"
FILESEXTRAPATHS_prepend := "${SYSMOCOM}/files:"
PRINC = "7"
SRC_URI += "file://busybox-ifplugd.sh \
file://ifplugd.sh"
PACKAGES =+ "${PN}-ifplugd"
FILES_${PN}-ifplugd = "${sysconfdir}/ifplugd.sh ${sysconfdir}/init.d/busybox-ifplugd.sh"
INITSCRIPT_PACKAGES += "${PN}-ifplugd"
INITSCRIPT_NAME = "busybox-ifplugd.sh"
do_install_append() {
install -m 0755 ${WORKDIR}/ifplugd.sh ${D}${sysconfdir}/
install -m 0755 ${WORKDIR}/busybox-ifplugd.sh ${D}${sysconfdir}/init.d/
}

View File

@ -0,0 +1,39 @@
#!/bin/sh
DAEMON=/usr/bin/ifplugd
NAME=ifplugd
DESC="Busybox ifplugd Server"
ARGS=" -i eth0 -M -I -r /etc/ifplugd.sh"
test -f $DAEMON || exit 1
set -e
case "$1" in
start)
echo -n "starting $DESC: $NAME... "
/sbin/start-stop-daemon -S -b -n $NAME -a $DAEMON -- $ARGS
echo "done."
;;
stop)
echo -n "stopping $DESC: $NAME... "
/sbin/start-stop-daemon -K -n $NAME
echo "done."
;;
restart)
echo "restarting $DESC: $NAME... "
$0 stop
$0 start
echo "done."
;;
reload)
echo -n "reloading $DESC: $NAME... "
killall -HUP $(basename ${DAEMON})
echo "done."
;;
*)
echo "Usage: $0 {start|stop|restart|reload}"
exit 1
;;
esac
exit 0

View File

@ -0,0 +1,924 @@
#
# Automatically generated make config: don't edit
# Busybox version: 1.16.2
# Tue Oct 26 15:07:52 2010
#
CONFIG_HAVE_DOT_CONFIG=y
#
# Busybox Settings
#
#
# General Configuration
#
# CONFIG_DESKTOP is not set
# CONFIG_EXTRA_COMPAT is not set
# CONFIG_INCLUDE_SUSv2 is not set
# CONFIG_USE_PORTABLE_CODE is not set
CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
# CONFIG_FEATURE_BUFFERS_GO_ON_STACK is not set
# CONFIG_FEATURE_BUFFERS_GO_IN_BSS is not set
CONFIG_SHOW_USAGE=y
# CONFIG_FEATURE_VERBOSE_USAGE is not set
CONFIG_FEATURE_COMPRESS_USAGE=y
# CONFIG_FEATURE_INSTALLER is not set
CONFIG_LOCALE_SUPPORT=y
# CONFIG_FEATURE_ASSUME_UNICODE is not set
# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set
CONFIG_LONG_OPTS=y
CONFIG_FEATURE_DEVPTS=y
# CONFIG_FEATURE_CLEAN_UP is not set
CONFIG_FEATURE_PIDFILE=y
CONFIG_FEATURE_SUID=y
CONFIG_FEATURE_SUID_CONFIG=y
CONFIG_FEATURE_SUID_CONFIG_QUIET=y
# CONFIG_SELINUX is not set
# CONFIG_FEATURE_PREFER_APPLETS is not set
CONFIG_BUSYBOX_EXEC_PATH="/proc/self/exe"
CONFIG_FEATURE_SYSLOG=y
CONFIG_FEATURE_HAVE_RPC=y
#
# Build Options
#
# CONFIG_STATIC is not set
# CONFIG_PIE is not set
# CONFIG_NOMMU is not set
# CONFIG_BUILD_LIBBUSYBOX is not set
# CONFIG_FEATURE_INDIVIDUAL is not set
# CONFIG_FEATURE_SHARED_BUSYBOX is not set
CONFIG_LFS=y
CONFIG_CROSS_COMPILER_PREFIX=""
CONFIG_EXTRA_CFLAGS=""
#
# Debugging Options
#
# CONFIG_DEBUG is not set
# CONFIG_DEBUG_PESSIMIZE is not set
# CONFIG_WERROR is not set
CONFIG_NO_DEBUG_LIB=y
# CONFIG_DMALLOC is not set
# CONFIG_EFENCE is not set
#
# Installation Options
#
# CONFIG_INSTALL_NO_USR is not set
CONFIG_INSTALL_APPLET_SYMLINKS=y
# CONFIG_INSTALL_APPLET_HARDLINKS is not set
# CONFIG_INSTALL_APPLET_SCRIPT_WRAPPERS is not set
# CONFIG_INSTALL_APPLET_DONT is not set
# CONFIG_INSTALL_SH_APPLET_SYMLINK is not set
# CONFIG_INSTALL_SH_APPLET_HARDLINK is not set
# CONFIG_INSTALL_SH_APPLET_SCRIPT_WRAPPER is not set
CONFIG_PREFIX="./_install"
#
# Busybox Library Tuning
#
CONFIG_PASSWORD_MINLEN=6
CONFIG_MD5_SIZE_VS_SPEED=2
CONFIG_FEATURE_FAST_TOP=y
# CONFIG_FEATURE_ETC_NETWORKS is not set
CONFIG_FEATURE_EDITING=y
CONFIG_FEATURE_EDITING_MAX_LEN=1024
# CONFIG_FEATURE_EDITING_VI is not set
CONFIG_FEATURE_EDITING_HISTORY=15
CONFIG_FEATURE_EDITING_SAVEHISTORY=y
CONFIG_FEATURE_TAB_COMPLETION=y
CONFIG_FEATURE_USERNAME_COMPLETION=y
CONFIG_FEATURE_EDITING_FANCY_PROMPT=y
# CONFIG_FEATURE_EDITING_ASK_TERMINAL is not set
CONFIG_FEATURE_NON_POSIX_CP=y
# CONFIG_FEATURE_VERBOSE_CP_MESSAGE is not set
CONFIG_FEATURE_COPYBUF_KB=4
CONFIG_MONOTONIC_SYSCALL=y
CONFIG_IOCTL_HEX2STR_ERROR=y
CONFIG_FEATURE_HWIB=y
#
# Applets
#
#
# Archival Utilities
#
CONFIG_FEATURE_SEAMLESS_LZMA=y
CONFIG_FEATURE_SEAMLESS_BZ2=y
CONFIG_FEATURE_SEAMLESS_GZ=y
CONFIG_FEATURE_SEAMLESS_Z=y
CONFIG_AR=y
# CONFIG_FEATURE_AR_LONG_FILENAMES is not set
CONFIG_BUNZIP2=y
# CONFIG_BZIP2 is not set
CONFIG_CPIO=y
# CONFIG_FEATURE_CPIO_O is not set
# CONFIG_FEATURE_CPIO_P is not set
# CONFIG_DPKG is not set
# CONFIG_DPKG_DEB is not set
# CONFIG_FEATURE_DPKG_DEB_EXTRACT_ONLY is not set
CONFIG_GUNZIP=y
CONFIG_GZIP=y
# CONFIG_FEATURE_GZIP_LONG_OPTIONS is not set
# CONFIG_LZOP is not set
# CONFIG_LZOP_COMPR_HIGH is not set
# CONFIG_RPM2CPIO is not set
# CONFIG_RPM is not set
CONFIG_TAR=y
CONFIG_FEATURE_TAR_CREATE=y
CONFIG_FEATURE_TAR_AUTODETECT=y
CONFIG_FEATURE_TAR_FROM=y
CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y
# CONFIG_FEATURE_TAR_OLDSUN_COMPATIBILITY is not set
CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y
# CONFIG_FEATURE_TAR_LONG_OPTIONS is not set
# CONFIG_FEATURE_TAR_UNAME_GNAME is not set
# CONFIG_FEATURE_TAR_NOPRESERVE_TIME is not set
# CONFIG_UNCOMPRESS is not set
# CONFIG_UNLZMA is not set
# CONFIG_FEATURE_LZMA_FAST is not set
CONFIG_UNZIP=y
#
# Coreutils
#
CONFIG_BASENAME=y
# CONFIG_CAL is not set
CONFIG_CAT=y
# CONFIG_CATV is not set
CONFIG_CHGRP=y
CONFIG_CHMOD=y
CONFIG_CHOWN=y
# CONFIG_FEATURE_CHOWN_LONG_OPTIONS is not set
CONFIG_CHROOT=y
# CONFIG_CKSUM is not set
# CONFIG_COMM is not set
CONFIG_CP=y
# CONFIG_FEATURE_CP_LONG_OPTIONS is not set
CONFIG_CUT=y
CONFIG_DATE=y
# CONFIG_FEATURE_DATE_ISOFMT is not set
CONFIG_FEATURE_DATE_COMPAT=y
CONFIG_DD=y
CONFIG_FEATURE_DD_SIGNAL_HANDLING=y
# CONFIG_FEATURE_DD_THIRD_STATUS_LINE is not set
# CONFIG_FEATURE_DD_IBS_OBS is not set
CONFIG_DF=y
# CONFIG_FEATURE_DF_FANCY is not set
CONFIG_DIRNAME=y
# CONFIG_DOS2UNIX is not set
# CONFIG_UNIX2DOS is not set
CONFIG_DU=y
CONFIG_FEATURE_DU_DEFAULT_BLOCKSIZE_1K=y
CONFIG_ECHO=y
CONFIG_FEATURE_FANCY_ECHO=y
CONFIG_ENV=y
CONFIG_FEATURE_ENV_LONG_OPTIONS=y
# CONFIG_EXPAND is not set
# CONFIG_FEATURE_EXPAND_LONG_OPTIONS is not set
CONFIG_EXPR=y
# CONFIG_EXPR_MATH_SUPPORT_64 is not set
CONFIG_FALSE=y
# CONFIG_FOLD is not set
# CONFIG_FSYNC is not set
CONFIG_HEAD=y
# CONFIG_FEATURE_FANCY_HEAD is not set
# CONFIG_HOSTID is not set
CONFIG_ID=y
# CONFIG_INSTALL is not set
# CONFIG_FEATURE_INSTALL_LONG_OPTIONS is not set
# CONFIG_LENGTH is not set
CONFIG_LN=y
CONFIG_LOGNAME=y
CONFIG_LS=y
CONFIG_FEATURE_LS_FILETYPES=y
CONFIG_FEATURE_LS_FOLLOWLINKS=y
CONFIG_FEATURE_LS_RECURSIVE=y
CONFIG_FEATURE_LS_SORTFILES=y
CONFIG_FEATURE_LS_TIMESTAMPS=y
CONFIG_FEATURE_LS_USERNAME=y
CONFIG_FEATURE_LS_COLOR=y
# CONFIG_FEATURE_LS_COLOR_IS_DEFAULT is not set
CONFIG_MD5SUM=y
CONFIG_MKDIR=y
CONFIG_FEATURE_MKDIR_LONG_OPTIONS=y
CONFIG_MKFIFO=y
CONFIG_MKNOD=y
CONFIG_MV=y
# CONFIG_FEATURE_MV_LONG_OPTIONS is not set
# CONFIG_NICE is not set
CONFIG_NOHUP=y
CONFIG_OD=y
# CONFIG_PRINTENV is not set
CONFIG_PRINTF=y
CONFIG_PWD=y
CONFIG_READLINK=y
CONFIG_FEATURE_READLINK_FOLLOW=y
CONFIG_REALPATH=y
CONFIG_RM=y
CONFIG_RMDIR=y
# CONFIG_FEATURE_RMDIR_LONG_OPTIONS is not set
CONFIG_SEQ=y
# CONFIG_SHA1SUM is not set
# CONFIG_SHA256SUM is not set
# CONFIG_SHA512SUM is not set
CONFIG_SLEEP=y
CONFIG_FEATURE_FANCY_SLEEP=y
# CONFIG_FEATURE_FLOAT_SLEEP is not set
CONFIG_SORT=y
CONFIG_FEATURE_SORT_BIG=y
# CONFIG_SPLIT is not set
# CONFIG_FEATURE_SPLIT_FANCY is not set
# CONFIG_STAT is not set
# CONFIG_FEATURE_STAT_FORMAT is not set
CONFIG_STTY=y
# CONFIG_SUM is not set
CONFIG_SYNC=y
# CONFIG_TAC is not set
CONFIG_TAIL=y
CONFIG_FEATURE_FANCY_TAIL=y
CONFIG_TEE=y
# CONFIG_FEATURE_TEE_USE_BLOCK_IO is not set
CONFIG_TEST=y
# CONFIG_FEATURE_TEST_64 is not set
CONFIG_TOUCH=y
CONFIG_TR=y
CONFIG_FEATURE_TR_CLASSES=y
# CONFIG_FEATURE_TR_EQUIV is not set
CONFIG_TRUE=y
CONFIG_TTY=y
CONFIG_UNAME=y
# CONFIG_UNEXPAND is not set
# CONFIG_FEATURE_UNEXPAND_LONG_OPTIONS is not set
CONFIG_UNIQ=y
CONFIG_USLEEP=y
# CONFIG_UUDECODE is not set
# CONFIG_UUENCODE is not set
CONFIG_WC=y
# CONFIG_FEATURE_WC_LARGE is not set
CONFIG_WHO=y
CONFIG_WHOAMI=y
CONFIG_YES=y
#
# Common options for cp and mv
#
# CONFIG_FEATURE_PRESERVE_HARDLINKS is not set
#
# Common options for ls, more and telnet
#
CONFIG_FEATURE_AUTOWIDTH=y
#
# Common options for df, du, ls
#
CONFIG_FEATURE_HUMAN_READABLE=y
#
# Common options for md5sum, sha1sum, sha256sum, sha512sum
#
CONFIG_FEATURE_MD5_SHA1_SUM_CHECK=y
#
# Console Utilities
#
CONFIG_CHVT=y
CONFIG_CLEAR=y
CONFIG_DEALLOCVT=y
CONFIG_DUMPKMAP=y
# CONFIG_KBD_MODE is not set
CONFIG_LOADFONT=y
CONFIG_LOADKMAP=y
CONFIG_OPENVT=y
CONFIG_RESET=y
# CONFIG_RESIZE is not set
# CONFIG_FEATURE_RESIZE_PRINT is not set
CONFIG_SETCONSOLE=y
# CONFIG_FEATURE_SETCONSOLE_LONG_OPTIONS is not set
# CONFIG_SETFONT is not set
# CONFIG_FEATURE_SETFONT_TEXTUAL_MAP is not set
CONFIG_DEFAULT_SETFONT_DIR=""
# CONFIG_SETKEYCODES is not set
# CONFIG_SETLOGCONS is not set
# CONFIG_SHOWKEY is not set
#
# Debian Utilities
#
CONFIG_MKTEMP=y
# CONFIG_PIPE_PROGRESS is not set
CONFIG_RUN_PARTS=y
CONFIG_FEATURE_RUN_PARTS_LONG_OPTIONS=y
# CONFIG_FEATURE_RUN_PARTS_FANCY is not set
CONFIG_START_STOP_DAEMON=y
CONFIG_FEATURE_START_STOP_DAEMON_FANCY=y
CONFIG_FEATURE_START_STOP_DAEMON_LONG_OPTIONS=y
CONFIG_WHICH=y
#
# Editors
#
CONFIG_AWK=y
# CONFIG_FEATURE_AWK_LIBM is not set
CONFIG_CMP=y
CONFIG_DIFF=y
# CONFIG_FEATURE_DIFF_LONG_OPTIONS is not set
CONFIG_FEATURE_DIFF_DIR=y
# CONFIG_ED is not set
CONFIG_PATCH=y
CONFIG_SED=y
CONFIG_VI=y
CONFIG_FEATURE_VI_MAX_LEN=1024
CONFIG_FEATURE_VI_8BIT=y
CONFIG_FEATURE_VI_COLON=y
CONFIG_FEATURE_VI_YANKMARK=y
CONFIG_FEATURE_VI_SEARCH=y
CONFIG_FEATURE_VI_USE_SIGNALS=y
# CONFIG_FEATURE_VI_DOT_CMD is not set
# CONFIG_FEATURE_VI_READONLY is not set
# CONFIG_FEATURE_VI_SETOPTS is not set
# CONFIG_FEATURE_VI_SET is not set
CONFIG_FEATURE_VI_WIN_RESIZE=y
CONFIG_FEATURE_VI_OPTIMIZE_CURSOR=y
CONFIG_FEATURE_ALLOW_EXEC=y
#
# Finding Utilities
#
CONFIG_FIND=y
CONFIG_FEATURE_FIND_PRINT0=y
CONFIG_FEATURE_FIND_MTIME=y
CONFIG_FEATURE_FIND_MMIN=y
CONFIG_FEATURE_FIND_PERM=y
CONFIG_FEATURE_FIND_TYPE=y
CONFIG_FEATURE_FIND_XDEV=y
CONFIG_FEATURE_FIND_MAXDEPTH=y
CONFIG_FEATURE_FIND_NEWER=y
# CONFIG_FEATURE_FIND_INUM is not set
CONFIG_FEATURE_FIND_EXEC=y
CONFIG_FEATURE_FIND_USER=y
CONFIG_FEATURE_FIND_GROUP=y
CONFIG_FEATURE_FIND_NOT=y
CONFIG_FEATURE_FIND_DEPTH=y
CONFIG_FEATURE_FIND_PAREN=y
CONFIG_FEATURE_FIND_SIZE=y
CONFIG_FEATURE_FIND_PRUNE=y
# CONFIG_FEATURE_FIND_DELETE is not set
CONFIG_FEATURE_FIND_PATH=y
CONFIG_FEATURE_FIND_REGEX=y
# CONFIG_FEATURE_FIND_CONTEXT is not set
# CONFIG_FEATURE_FIND_LINKS is not set
CONFIG_GREP=y
CONFIG_FEATURE_GREP_EGREP_ALIAS=y
CONFIG_FEATURE_GREP_FGREP_ALIAS=y
CONFIG_FEATURE_GREP_CONTEXT=y
CONFIG_XARGS=y
# CONFIG_FEATURE_XARGS_SUPPORT_CONFIRMATION is not set
# CONFIG_FEATURE_XARGS_SUPPORT_QUOTES is not set
# CONFIG_FEATURE_XARGS_SUPPORT_TERMOPT is not set
# CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM is not set
#
# Init Utilities
#
# CONFIG_INIT is not set
# CONFIG_FEATURE_USE_INITTAB is not set
# CONFIG_FEATURE_KILL_REMOVED is not set
CONFIG_FEATURE_KILL_DELAY=0
# CONFIG_FEATURE_INIT_SCTTY is not set
# CONFIG_FEATURE_INIT_SYSLOG is not set
# CONFIG_FEATURE_EXTRA_QUIET is not set
# CONFIG_FEATURE_INIT_COREDUMPS is not set
# CONFIG_FEATURE_INITRD is not set
CONFIG_HALT=y
# CONFIG_FEATURE_CALL_TELINIT is not set
CONFIG_TELINIT_PATH=""
# CONFIG_MESG is not set
#
# Login/Password Management Utilities
#
# CONFIG_FEATURE_SHADOWPASSWDS is not set
# CONFIG_USE_BB_PWD_GRP is not set
# CONFIG_USE_BB_SHADOW is not set
CONFIG_USE_BB_CRYPT=y
# CONFIG_USE_BB_CRYPT_SHA is not set
# CONFIG_ADDGROUP is not set
# CONFIG_FEATURE_ADDGROUP_LONG_OPTIONS is not set
# CONFIG_FEATURE_ADDUSER_TO_GROUP is not set
# CONFIG_DELGROUP is not set
# CONFIG_FEATURE_DEL_USER_FROM_GROUP is not set
# CONFIG_FEATURE_CHECK_NAMES is not set
# CONFIG_ADDUSER is not set
# CONFIG_FEATURE_ADDUSER_LONG_OPTIONS is not set
CONFIG_FIRST_SYSTEM_ID=0
CONFIG_LAST_SYSTEM_ID=0
# CONFIG_DELUSER is not set
# CONFIG_GETTY is not set
CONFIG_FEATURE_UTMP=y
# CONFIG_FEATURE_WTMP is not set
# CONFIG_LOGIN is not set
# CONFIG_PAM is not set
# CONFIG_LOGIN_SCRIPTS is not set
# CONFIG_FEATURE_NOLOGIN is not set
# CONFIG_FEATURE_SECURETTY is not set
# CONFIG_PASSWD is not set
# CONFIG_FEATURE_PASSWD_WEAK_CHECK is not set
# CONFIG_CRYPTPW is not set
# CONFIG_CHPASSWD is not set
# CONFIG_SU is not set
# CONFIG_FEATURE_SU_SYSLOG is not set
# CONFIG_FEATURE_SU_CHECKS_SHELLS is not set
# CONFIG_SULOGIN is not set
# CONFIG_VLOCK is not set
#
# Linux Ext2 FS Progs
#
CONFIG_CHATTR=y
CONFIG_FSCK=y
# CONFIG_LSATTR is not set
#
# Linux Module Utilities
#
# CONFIG_MODPROBE_SMALL is not set
# CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE is not set
# CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED is not set
CONFIG_INSMOD=y
CONFIG_RMMOD=y
CONFIG_LSMOD=y
# CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT is not set
CONFIG_MODPROBE=y
CONFIG_FEATURE_MODPROBE_BLACKLIST=y
# CONFIG_DEPMOD is not set
#
# Options common to multiple modutils
#
# CONFIG_FEATURE_2_4_MODULES is not set
# CONFIG_FEATURE_INSMOD_TRY_MMAP is not set
# CONFIG_FEATURE_INSMOD_VERSION_CHECKING is not set
# CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS is not set
# CONFIG_FEATURE_INSMOD_LOADINKMEM is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP is not set
# CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL is not set
CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
CONFIG_FEATURE_MODUTILS_ALIAS=y
CONFIG_FEATURE_MODUTILS_SYMBOLS=y
CONFIG_DEFAULT_MODULES_DIR="/lib/modules"
CONFIG_DEFAULT_DEPMOD_FILE="modules.dep"
#
# Linux System Utilities
#
# CONFIG_ACPID is not set
# CONFIG_FEATURE_ACPID_COMPAT is not set
# CONFIG_BLKID is not set
CONFIG_DMESG=y
CONFIG_FEATURE_DMESG_PRETTY=y
CONFIG_FBSET=y
CONFIG_FEATURE_FBSET_FANCY=y
CONFIG_FEATURE_FBSET_READMODE=y
# CONFIG_FDFLUSH is not set
# CONFIG_FDFORMAT is not set
CONFIG_FDISK=y
CONFIG_FDISK_SUPPORT_LARGE_DISKS=y
CONFIG_FEATURE_FDISK_WRITABLE=y
# CONFIG_FEATURE_AIX_LABEL is not set
# CONFIG_FEATURE_SGI_LABEL is not set
# CONFIG_FEATURE_SUN_LABEL is not set
# CONFIG_FEATURE_OSF_LABEL is not set
# CONFIG_FEATURE_FDISK_ADVANCED is not set
# CONFIG_FINDFS is not set
# CONFIG_FREERAMDISK is not set
CONFIG_FSCK_MINIX=y
# CONFIG_MKFS_EXT2 is not set
CONFIG_MKFS_MINIX=y
#
# Minix filesystem support
#
CONFIG_FEATURE_MINIX2=y
# CONFIG_MKFS_REISER is not set
# CONFIG_MKFS_VFAT is not set
# CONFIG_GETOPT is not set
# CONFIG_FEATURE_GETOPT_LONG is not set
CONFIG_HEXDUMP=y
# CONFIG_FEATURE_HEXDUMP_REVERSE is not set
# CONFIG_HD is not set
CONFIG_HWCLOCK=y
CONFIG_FEATURE_HWCLOCK_LONG_OPTIONS=y
CONFIG_FEATURE_HWCLOCK_ADJTIME_FHS=y
# CONFIG_IPCRM is not set
# CONFIG_IPCS is not set
CONFIG_LOSETUP=y
# CONFIG_LSPCI is not set
# CONFIG_LSUSB is not set
# CONFIG_MDEV is not set
# CONFIG_FEATURE_MDEV_CONF is not set
# CONFIG_FEATURE_MDEV_RENAME is not set
# CONFIG_FEATURE_MDEV_RENAME_REGEXP is not set
# CONFIG_FEATURE_MDEV_EXEC is not set
# CONFIG_FEATURE_MDEV_LOAD_FIRMWARE is not set
CONFIG_MKSWAP=y
# CONFIG_FEATURE_MKSWAP_UUID is not set
CONFIG_MORE=y
CONFIG_FEATURE_USE_TERMIOS=y
# CONFIG_VOLUMEID is not set
# CONFIG_FEATURE_VOLUMEID_EXT is not set
# CONFIG_FEATURE_VOLUMEID_BTRFS is not set
# CONFIG_FEATURE_VOLUMEID_REISERFS is not set
# CONFIG_FEATURE_VOLUMEID_FAT is not set
# CONFIG_FEATURE_VOLUMEID_HFS is not set
# CONFIG_FEATURE_VOLUMEID_JFS is not set
# CONFIG_FEATURE_VOLUMEID_XFS is not set
# CONFIG_FEATURE_VOLUMEID_NTFS is not set
# CONFIG_FEATURE_VOLUMEID_ISO9660 is not set
# CONFIG_FEATURE_VOLUMEID_UDF is not set
# CONFIG_FEATURE_VOLUMEID_LUKS is not set
# CONFIG_FEATURE_VOLUMEID_LINUXSWAP is not set
# CONFIG_FEATURE_VOLUMEID_CRAMFS is not set
# CONFIG_FEATURE_VOLUMEID_ROMFS is not set
# CONFIG_FEATURE_VOLUMEID_SYSV is not set
# CONFIG_FEATURE_VOLUMEID_OCFS2 is not set
# CONFIG_FEATURE_VOLUMEID_LINUXRAID is not set
CONFIG_MOUNT=y
# CONFIG_FEATURE_MOUNT_FAKE is not set
# CONFIG_FEATURE_MOUNT_VERBOSE is not set
# CONFIG_FEATURE_MOUNT_HELPERS is not set
# CONFIG_FEATURE_MOUNT_LABEL is not set
CONFIG_FEATURE_MOUNT_NFS=y
# CONFIG_FEATURE_MOUNT_CIFS is not set
CONFIG_FEATURE_MOUNT_FLAGS=y
CONFIG_FEATURE_MOUNT_FSTAB=y
CONFIG_PIVOT_ROOT=y
CONFIG_RDATE=y
# CONFIG_RDEV is not set
# CONFIG_READPROFILE is not set
# CONFIG_RTCWAKE is not set
# CONFIG_SCRIPT is not set
# CONFIG_SCRIPTREPLAY is not set
# CONFIG_SETARCH is not set
CONFIG_SWAPONOFF=y
# CONFIG_FEATURE_SWAPON_PRI is not set
CONFIG_SWITCH_ROOT=y
CONFIG_UMOUNT=y
CONFIG_FEATURE_UMOUNT_ALL=y
#
# Common options for mount/umount
#
CONFIG_FEATURE_MOUNT_LOOP=y
# CONFIG_FEATURE_MTAB_SUPPORT is not set
#
# Miscellaneous Utilities
#
# CONFIG_ADJTIMEX is not set
# CONFIG_BBCONFIG is not set
# CONFIG_BEEP is not set
CONFIG_FEATURE_BEEP_FREQ=0
CONFIG_FEATURE_BEEP_LENGTH_MS=0
# CONFIG_CHAT is not set
# CONFIG_FEATURE_CHAT_NOFAIL is not set
# CONFIG_FEATURE_CHAT_TTY_HIFI is not set
# CONFIG_FEATURE_CHAT_IMPLICIT_CR is not set
# CONFIG_FEATURE_CHAT_SWALLOW_OPTS is not set
# CONFIG_FEATURE_CHAT_SEND_ESCAPES is not set
# CONFIG_FEATURE_CHAT_VAR_ABORT_LEN is not set
# CONFIG_FEATURE_CHAT_CLR_ABORT is not set
# CONFIG_CHRT is not set
# CONFIG_CROND is not set
# CONFIG_FEATURE_CROND_D is not set
# CONFIG_FEATURE_CROND_CALL_SENDMAIL is not set
CONFIG_FEATURE_CROND_DIR=""
# CONFIG_CRONTAB is not set
CONFIG_DC=y
# CONFIG_FEATURE_DC_LIBM is not set
# CONFIG_DEVFSD is not set
# CONFIG_DEVFSD_MODLOAD is not set
# CONFIG_DEVFSD_FG_NP is not set
# CONFIG_DEVFSD_VERBOSE is not set
# CONFIG_FEATURE_DEVFS is not set
# CONFIG_DEVMEM is not set
# CONFIG_EJECT is not set
# CONFIG_FEATURE_EJECT_SCSI is not set
# CONFIG_FBSPLASH is not set
# CONFIG_FLASHCP is not set
# CONFIG_FLASH_LOCK is not set
# CONFIG_FLASH_UNLOCK is not set
# CONFIG_FLASH_ERASEALL is not set
# CONFIG_IONICE is not set
# CONFIG_INOTIFYD is not set
# CONFIG_LAST is not set
# CONFIG_FEATURE_LAST_SMALL is not set
# CONFIG_FEATURE_LAST_FANCY is not set
CONFIG_LESS=y
CONFIG_FEATURE_LESS_MAXLINES=9999999
CONFIG_FEATURE_LESS_BRACKETS=y
CONFIG_FEATURE_LESS_FLAGS=y
# CONFIG_FEATURE_LESS_MARKS is not set
# CONFIG_FEATURE_LESS_REGEXP is not set
# CONFIG_FEATURE_LESS_WINCH is not set
# CONFIG_FEATURE_LESS_DASHCMD is not set
# CONFIG_FEATURE_LESS_LINENUMS is not set
# CONFIG_HDPARM is not set
# CONFIG_FEATURE_HDPARM_GET_IDENTITY is not set
# CONFIG_FEATURE_HDPARM_HDIO_SCAN_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_UNREGISTER_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_DRIVE_RESET is not set
# CONFIG_FEATURE_HDPARM_HDIO_TRISTATE_HWIF is not set
# CONFIG_FEATURE_HDPARM_HDIO_GETSET_DMA is not set
# CONFIG_MAKEDEVS is not set
# CONFIG_FEATURE_MAKEDEVS_LEAF is not set
# CONFIG_FEATURE_MAKEDEVS_TABLE is not set
# CONFIG_MAN is not set
CONFIG_MICROCOM=y
# CONFIG_MOUNTPOINT is not set
# CONFIG_MT is not set
# CONFIG_RAIDAUTORUN is not set
# CONFIG_READAHEAD is not set
# CONFIG_RUNLEVEL is not set
# CONFIG_RX is not set
# CONFIG_SETSID is not set
CONFIG_STRINGS=y
# CONFIG_TASKSET is not set
# CONFIG_FEATURE_TASKSET_FANCY is not set
CONFIG_TIME=y
# CONFIG_TIMEOUT is not set
# CONFIG_TTYSIZE is not set
# CONFIG_VOLNAME is not set
# CONFIG_WALL is not set
# CONFIG_WATCHDOG is not set
#
# Networking Utilities
#
CONFIG_FEATURE_IPV6=y
# CONFIG_FEATURE_UNIX_LOCAL is not set
CONFIG_FEATURE_PREFER_IPV4_ADDRESS=y
# CONFIG_VERBOSE_RESOLUTION_ERRORS is not set
# CONFIG_ARP is not set
# CONFIG_ARPING is not set
# CONFIG_BRCTL is not set
# CONFIG_FEATURE_BRCTL_FANCY is not set
# CONFIG_FEATURE_BRCTL_SHOW is not set
# CONFIG_DNSD is not set
# CONFIG_ETHER_WAKE is not set
# CONFIG_FAKEIDENTD is not set
# CONFIG_FTPD is not set
# CONFIG_FEATURE_FTP_WRITE is not set
# CONFIG_FEATURE_FTPD_ACCEPT_BROKEN_LIST is not set
# CONFIG_FTPGET is not set
# CONFIG_FTPPUT is not set
# CONFIG_FEATURE_FTPGETPUT_LONG_OPTIONS is not set
CONFIG_HOSTNAME=y
# CONFIG_HTTPD is not set
# CONFIG_FEATURE_HTTPD_RANGES is not set
# CONFIG_FEATURE_HTTPD_USE_SENDFILE is not set
# CONFIG_FEATURE_HTTPD_SETUID is not set
# CONFIG_FEATURE_HTTPD_BASIC_AUTH is not set
# CONFIG_FEATURE_HTTPD_AUTH_MD5 is not set
# CONFIG_FEATURE_HTTPD_CGI is not set
# CONFIG_FEATURE_HTTPD_CONFIG_WITH_SCRIPT_INTERPR is not set
# CONFIG_FEATURE_HTTPD_SET_REMOTE_PORT_TO_ENV is not set
# CONFIG_FEATURE_HTTPD_ENCODE_URL_STR is not set
# CONFIG_FEATURE_HTTPD_ERROR_PAGES is not set
# CONFIG_FEATURE_HTTPD_PROXY is not set
CONFIG_IFCONFIG=y
CONFIG_FEATURE_IFCONFIG_STATUS=y
# CONFIG_FEATURE_IFCONFIG_SLIP is not set
# CONFIG_FEATURE_IFCONFIG_MEMSTART_IOADDR_IRQ is not set
CONFIG_FEATURE_IFCONFIG_HW=y
# CONFIG_FEATURE_IFCONFIG_BROADCAST_PLUS is not set
# CONFIG_IFENSLAVE is not set
CONFIG_IFPLUGD=y
CONFIG_IFUPDOWN=y
CONFIG_IFUPDOWN_IFSTATE_PATH="/var/run/ifstate"
# CONFIG_FEATURE_IFUPDOWN_IP is not set
# CONFIG_FEATURE_IFUPDOWN_IP_BUILTIN is not set
CONFIG_FEATURE_IFUPDOWN_IFCONFIG_BUILTIN=y
CONFIG_FEATURE_IFUPDOWN_IPV4=y
CONFIG_FEATURE_IFUPDOWN_IPV6=y
CONFIG_FEATURE_IFUPDOWN_MAPPING=y
# CONFIG_FEATURE_IFUPDOWN_EXTERNAL_DHCP is not set
# CONFIG_INETD is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_ECHO is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DISCARD is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_TIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_DAYTIME is not set
# CONFIG_FEATURE_INETD_SUPPORT_BUILTIN_CHARGEN is not set
# CONFIG_FEATURE_INETD_RPC is not set
CONFIG_IP=y
CONFIG_FEATURE_IP_ADDRESS=y
CONFIG_FEATURE_IP_LINK=y
CONFIG_FEATURE_IP_ROUTE=y
CONFIG_FEATURE_IP_TUNNEL=y
# CONFIG_FEATURE_IP_RULE is not set
# CONFIG_FEATURE_IP_SHORT_FORMS is not set
# CONFIG_FEATURE_IP_RARE_PROTOCOLS is not set
# CONFIG_IPADDR is not set
# CONFIG_IPLINK is not set
# CONFIG_IPROUTE is not set
# CONFIG_IPTUNNEL is not set
# CONFIG_IPRULE is not set
# CONFIG_IPCALC is not set
# CONFIG_FEATURE_IPCALC_FANCY is not set
# CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
# CONFIG_NAMEIF is not set
# CONFIG_FEATURE_NAMEIF_EXTENDED is not set
CONFIG_NC=y
# CONFIG_NC_SERVER is not set
# CONFIG_NC_EXTRA is not set
CONFIG_NETSTAT=y
# CONFIG_FEATURE_NETSTAT_WIDE is not set
# CONFIG_FEATURE_NETSTAT_PRG is not set
CONFIG_NSLOOKUP=y
# CONFIG_NTPD is not set
# CONFIG_FEATURE_NTPD_SERVER is not set
CONFIG_PING=y
CONFIG_PING6=y
CONFIG_FEATURE_FANCY_PING=y
# CONFIG_PSCAN is not set
CONFIG_ROUTE=y
# CONFIG_SLATTACH is not set
CONFIG_TELNET=y
# CONFIG_FEATURE_TELNET_TTYPE is not set
CONFIG_FEATURE_TELNET_AUTOLOGIN=y
# CONFIG_TELNETD is not set
# CONFIG_FEATURE_TELNETD_STANDALONE is not set
# CONFIG_FEATURE_TELNETD_INETD_WAIT is not set
CONFIG_TFTP=y
# CONFIG_TFTPD is not set
CONFIG_FEATURE_TFTP_GET=y
CONFIG_FEATURE_TFTP_PUT=y
# CONFIG_FEATURE_TFTP_BLOCKSIZE is not set
# CONFIG_FEATURE_TFTP_PROGRESS_BAR is not set
# CONFIG_TFTP_DEBUG is not set
CONFIG_TRACEROUTE=y
# CONFIG_TRACEROUTE6 is not set
# CONFIG_FEATURE_TRACEROUTE_VERBOSE is not set
# CONFIG_FEATURE_TRACEROUTE_SOURCE_ROUTE is not set
# CONFIG_FEATURE_TRACEROUTE_USE_ICMP is not set
CONFIG_UDHCPD=y
# CONFIG_DHCPRELAY is not set
CONFIG_DUMPLEASES=y
# CONFIG_FEATURE_UDHCPD_WRITE_LEASES_EARLY is not set
CONFIG_DHCPD_LEASES_FILE="/var/lib/misc/udhcpd.leases"
CONFIG_UDHCPC=y
CONFIG_FEATURE_UDHCPC_ARPING=y
# CONFIG_FEATURE_UDHCP_PORT is not set
CONFIG_UDHCP_DEBUG=0
# CONFIG_FEATURE_UDHCP_RFC3397 is not set
CONFIG_UDHCPC_DEFAULT_SCRIPT="/usr/share/udhcpc/default.script"
CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS=80
CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS="-R -n"
# CONFIG_VCONFIG is not set
CONFIG_WGET=y
CONFIG_FEATURE_WGET_STATUSBAR=y
CONFIG_FEATURE_WGET_AUTHENTICATION=y
CONFIG_FEATURE_WGET_LONG_OPTIONS=y
# CONFIG_ZCIP is not set
# CONFIG_TCPSVD is not set
# CONFIG_TUNCTL is not set
# CONFIG_FEATURE_TUNCTL_UG is not set
# CONFIG_UDPSVD is not set
#
# Print Utilities
#
# CONFIG_LPD is not set
# CONFIG_LPR is not set
# CONFIG_LPQ is not set
#
# Mail Utilities
#
# CONFIG_MAKEMIME is not set
CONFIG_FEATURE_MIME_CHARSET=""
# CONFIG_POPMAILDIR is not set
# CONFIG_FEATURE_POPMAILDIR_DELIVERY is not set
# CONFIG_REFORMIME is not set
# CONFIG_FEATURE_REFORMIME_COMPAT is not set
# CONFIG_SENDMAIL is not set
#
# Process Utilities
#
CONFIG_FREE=y
CONFIG_FUSER=y
CONFIG_KILL=y
CONFIG_KILLALL=y
# CONFIG_KILLALL5 is not set
# CONFIG_NMETER is not set
# CONFIG_PGREP is not set
CONFIG_PIDOF=y
# CONFIG_FEATURE_PIDOF_SINGLE is not set
# CONFIG_FEATURE_PIDOF_OMIT is not set
# CONFIG_PKILL is not set
CONFIG_PS=y
CONFIG_FEATURE_PS_WIDE=y
# CONFIG_FEATURE_PS_TIME is not set
# CONFIG_FEATURE_PS_ADDITIONAL_COLUMNS is not set
# CONFIG_FEATURE_PS_UNUSUAL_SYSTEMS is not set
CONFIG_RENICE=y
CONFIG_BB_SYSCTL=y
CONFIG_TOP=y
CONFIG_FEATURE_TOP_CPU_USAGE_PERCENTAGE=y
CONFIG_FEATURE_TOP_CPU_GLOBAL_PERCENTS=y
# CONFIG_FEATURE_TOP_SMP_CPU is not set
# CONFIG_FEATURE_TOP_DECIMALS is not set
# CONFIG_FEATURE_TOP_SMP_PROCESS is not set
# CONFIG_FEATURE_TOPMEM is not set
# CONFIG_FEATURE_SHOW_THREADS is not set
CONFIG_UPTIME=y
CONFIG_WATCH=y
#
# Runit Utilities
#
# CONFIG_RUNSV is not set
# CONFIG_RUNSVDIR is not set
# CONFIG_FEATURE_RUNSVDIR_LOG is not set
# CONFIG_SV is not set
CONFIG_SV_DEFAULT_SERVICE_DIR=""
# CONFIG_SVLOGD is not set
# CONFIG_CHPST is not set
# CONFIG_SETUIDGID is not set
# CONFIG_ENVUIDGID is not set
# CONFIG_ENVDIR is not set
# CONFIG_SOFTLIMIT is not set
# CONFIG_CHCON is not set
# CONFIG_FEATURE_CHCON_LONG_OPTIONS is not set
# CONFIG_GETENFORCE is not set
# CONFIG_GETSEBOOL is not set
# CONFIG_LOAD_POLICY is not set
# CONFIG_MATCHPATHCON is not set
# CONFIG_RESTORECON is not set
# CONFIG_RUNCON is not set
# CONFIG_FEATURE_RUNCON_LONG_OPTIONS is not set
# CONFIG_SELINUXENABLED is not set
# CONFIG_SETENFORCE is not set
# CONFIG_SETFILES is not set
# CONFIG_FEATURE_SETFILES_CHECK_OPTION is not set
# CONFIG_SETSEBOOL is not set
# CONFIG_SESTATUS is not set
#
# Shells
#
CONFIG_FEATURE_SH_IS_ASH=y
# CONFIG_FEATURE_SH_IS_HUSH is not set
# CONFIG_FEATURE_SH_IS_NONE is not set
CONFIG_ASH=y
CONFIG_ASH_BASH_COMPAT=y
CONFIG_ASH_JOB_CONTROL=y
CONFIG_ASH_ALIAS=y
CONFIG_ASH_GETOPTS=y
CONFIG_ASH_BUILTIN_ECHO=y
CONFIG_ASH_BUILTIN_PRINTF=y
CONFIG_ASH_BUILTIN_TEST=y
# CONFIG_ASH_CMDCMD is not set
# CONFIG_ASH_MAIL is not set
CONFIG_ASH_OPTIMIZE_FOR_SIZE=y
# CONFIG_ASH_RANDOM_SUPPORT is not set
CONFIG_ASH_EXPAND_PRMT=y
# CONFIG_HUSH is not set
# CONFIG_HUSH_BASH_COMPAT is not set
# CONFIG_HUSH_HELP is not set
# CONFIG_HUSH_INTERACTIVE is not set
# CONFIG_HUSH_JOB is not set
# CONFIG_HUSH_TICK is not set
# CONFIG_HUSH_IF is not set
# CONFIG_HUSH_LOOPS is not set
# CONFIG_HUSH_CASE is not set
# CONFIG_HUSH_FUNCTIONS is not set
# CONFIG_HUSH_LOCAL is not set
# CONFIG_HUSH_EXPORT_N is not set
# CONFIG_HUSH_RANDOM_SUPPORT is not set
# CONFIG_LASH is not set
# CONFIG_MSH is not set
CONFIG_SH_MATH_SUPPORT=y
# CONFIG_SH_MATH_SUPPORT_64 is not set
CONFIG_FEATURE_SH_EXTRA_QUIET=y
# CONFIG_FEATURE_SH_STANDALONE is not set
# CONFIG_FEATURE_SH_NOFORK is not set
# CONFIG_CTTYHACK is not set
#
# System Logging Utilities
#
CONFIG_SYSLOGD=y
CONFIG_FEATURE_ROTATE_LOGFILE=y
CONFIG_FEATURE_REMOTE_LOG=y
# CONFIG_FEATURE_SYSLOGD_DUP is not set
CONFIG_FEATURE_IPC_SYSLOG=y
CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=16
CONFIG_LOGREAD=y
CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y
CONFIG_KLOGD=y
CONFIG_LOGGER=y

View File

@ -0,0 +1,12 @@
#!/bin/sh
case $2 in
up)
echo "UP"
/sbin/ifup $1
;;
down)
echo "DOWN"
/sbin/ifdown $1
;;
esac

View File

@ -0,0 +1,20 @@
DESCRIPTION = "sysmocom BSC/E1 image"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
LICENSE = "MIT"
inherit boot-directdisk
do_bootdirectdisk_prepend () {
import bb
fstypes = bb.data.getVar('IMAGE_FSTYPES', d, True)
if 'ext3' not in fstypes:
bb.msg.fatal(bb.msg.domain.Build, "ext3 not in IMAGE_FSTYPES")
}
ROOTFS = "${DEPLOY_DIR_IMAGE}/sysmocom-bsc-e1-image-${MACHINE}.ext3"
do_bootdirectdisk[depends] += "sysmocom-bsc-e1-image:do_rootfs"

View File

@ -0,0 +1,10 @@
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom \
task-sysmocom-debug task-sysmocom-tools task-sysmocom-e1 task-gprscore \
e2fsprogs-mke2fs e2fsprogs-tune2fs e2fsprogs-e2fsck e2fsprogs-fsck \
kernel-module-nls-iso8859-1 kernel-module-nls-cp437"
IMAGE_LINGUAS = " "
LICENSE = "MIT"
inherit core-image
IMAGE_ROOTFS_SIZE = "524288"

View File

@ -0,0 +1,8 @@
require sysmocom-image.inc
# This variant of the image will run osmo-bts and osmo-bsc
activate_bsc() {
echo "NO_START=0" > ${IMAGE_ROOTFS}/etc/default/osmo-bsc
}
IMAGE_PREPROCESS_COMMAND += "activate_bsc; "

View File

@ -0,0 +1,20 @@
DESCRIPTION = "sysmocom BSC/IP image"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
LICENSE = "MIT"
inherit boot-directdisk
do_bootdirectdisk_prepend () {
import bb
fstypes = bb.data.getVar('IMAGE_FSTYPES', d, True)
if 'ext3' not in fstypes:
bb.msg.fatal(bb.msg.domain.Build, "ext3 not in IMAGE_FSTYPES")
}
ROOTFS = "${DEPLOY_DIR_IMAGE}/sysmocom-bsc-ip-image-${MACHINE}.ext3"
do_bootdirectdisk[depends] += "sysmocom-bsc-ip-image:do_rootfs"

View File

@ -0,0 +1,7 @@
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom task-sysmocom-debug task-sysmocom-tools task-gprscore sysmocom-udhcpd-config busybox-udhcpd"
IMAGE_LINGUAS = " "
LICENSE = "MIT"
inherit core-image
IMAGE_ROOTFS_SIZE = "262144"

View File

@ -0,0 +1,10 @@
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} task-osmocom task-sysmocom"
IMAGE_LINGUAS = " "
LICENSE = "MIT"
inherit core-image
IMAGE_ROOTFS_SIZE = "8192"
# remove not needed ipkg informations
ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

View File

@ -0,0 +1 @@
require sysmocom-image.inc

View File

@ -0,0 +1,19 @@
DEPENDS = "${MACHINE_EXTRA_RDEPENDS}"
IMAGE_INSTALL = "task-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${ROOTFS_PKGMANAGE} task-osmocom task-sysmocom task-sysmocom-debug task-sysmocom-tools ${MACHINE_EXTRA_RDEPENDS} "
IMAGE_LINGUAS = " "
LICENSE = "MIT"
inherit core-image
IMAGE_ROOTFS_SIZE = "32768"
link_uimage() {
echo "Linking the current uImage to /boot/uImage"
OLD_PWD=$PWD
cd ${IMAGE_ROOTFS}/boot
ln -s uImage-* uImage || true
cd $OLD_PWD
}
IMAGE_PREPROCESS_COMMAND += "link_uimage; "

View File

@ -0,0 +1,8 @@
require sysmocom-image.inc
# This variant of the image will run osmo-bts and osmo-nitb
activate_nitb() {
echo "NO_START=0" > ${IMAGE_ROOTFS}/etc/default/osmo-nitb
}
IMAGE_PREPROCESS_COMMAND += "activate_nitb; "

View File

@ -0,0 +1,5 @@
start 10.23.24.123
end 10.23.24.254
interface eth1

View File

@ -0,0 +1,13 @@
DESCRIPTION = "Task for sysmocom external tools"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
SRC_URI = "file://udhcpd.conf"
CONFFILES_${PN} = "${sysconfdir}/udhcpd.conf"
do_install() {
install -d ${D}${sysconfdir}
install -m 0644 ${WORKDIR}/udhcpd.conf ${D}${sysconfdir}/
}

View File

@ -0,0 +1,3 @@
PRINC = "6"
RDEPENDS_task-core-boot += ""

View File

@ -0,0 +1,14 @@
DESCRIPTION = "Task for GPRS core network"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
DEPENDS = "virtual/kernel"
ALLOW_EMPTY = "1"
PR = "r1"
RDEPENDS_task-gprscore = "\
openggsn \
gprs-routing osmo-sgsn \
sysmocom-ggsn-config \
"

View File

@ -0,0 +1,17 @@
DESCRIPTION = "Task for sysmoBTS"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
DEPENDS = "virtual/kernel"
ALLOW_EMPTY = "1"
PR = "r13"
# TODO: re-add femtobts-calib after it went through the API migration
RDEPENDS_task-sysmocom-bts = "\
osmo-bts \
osmo-bts-remote \
sysmobts-calib \
osmo-pcu \
lmsensors-scripts \
"

View File

@ -0,0 +1,19 @@
DESCRIPTION = "Task for sysmocom development/debugging"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
DEPENDS = "virtual/kernel"
ALLOW_EMPTY = "1"
PR = "r2"
RDEPENDS_task-sysmocom-debug = "\
dropbear \
mtd-utils \
strace \
tcpdump \
gdb \
gdbserver \
oprofile \
net-tools \
"

View File

@ -0,0 +1,12 @@
DESCRIPTION = "Task for E1 based sysmocom"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
ALLOW_EMPTY = "1"
PR = "r1"
RDEPENDS_task-sysmocom-e1 = "\
dahdi-linux \
dahdi-firmware \
dahdi-tools \
"

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