linux/poky.git/scripts, branch yocto-2.1

devtool: sdk-update: fix handling of UNINATIVE_CHECKSUM changes

2016-04-19T20:11:24+00:00

If UNINATIVE_CHECKSUM changes over an SDK update, bitbake within the extensible SDK will be broken because it will see that the matching uninative tarball doesn't exist and if there is a default value of UNINATIVE_URL it will attempt to download the file and will then fail because the checksums don't match up; alternatively if no UNINATIVE_URL is set then it'll also fail with an error about misconfiguration. To fix this, add some logic to devtool sdk-update to download the matching uninative tarball(s) for the checksum(s) in the newly fetched SDK configuration. Fixes [YOCTO #9301]. (From OE-Core rev: 14ff58ad98a5afac08db77068d80f152d8875766) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

oe-selftest: Correct the usage examples

2016-04-18T15:28:22+00:00

(From OE-Core rev: 7f5d150e4f9270e586c8a279ee64561c54689ffc) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: sdk-update: reset git metadata on update

2016-04-18T15:28:22+00:00

Replace git pull with fetch and reset to avoid the merge logic in the event that the layers repo in the published SDK we're updating to isn't fast-forward merge from the local repo. Also add gitignore and committer info during publish to avoid errors and to be sure that the first commit has a dummy user in it. [ YOCTO #9368 ] (From OE-Core rev: 4657bc9d165e51981e034e73e7b92552e873eef7) Signed-off-by: Stephano Cetola Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: upgrade: handle recipes where source is not first entry in SRC_URI

2016-04-15T05:59:43+00:00

It is unusual but not impossible to find recipes whose first entry is not the main source URL but instead some patch or other local file, for example python-cryptography in meta-python (which sets SRC_URI before inheriting pypi). There's nothing inherently wrong with this, and we shouldn't assume that the first entry is the main source URL, so just take the first non-local entry instead. (From OE-Core rev: c868198c1f6006789707b497c2ae34d7cc5e706f) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

runqemu: let ramfs equal to cpio.gz

2016-04-14T09:58:34+00:00

For example, support both: $ runqemu qemux86-64 ramfs $ runqemu qemux86-64 cpio.gz (new) (From OE-Core rev: 6529264776701d4f5a1e4a8336ac2e01a6ddea85) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

wic: fix bug in handling fsoptions

2016-04-14T09:58:33+00:00

Partitions specifying --fsoptions were silently skipped by wic due to the old bug introduced when removing code related to subvolume handling: - if mountpoint == "/" or not fsopts or fsopts.find("subvol=") == -1 + if mountpoint == "/" or not fsopts: [YOCTO #9396] (From OE-Core rev: be7ff1741e8ab5f2724b3f64da1bed8b0d3dcb7c) Signed-off-by: Ed Bartosh Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

Revert "wic/utils/partitionedfs.py: assemble .wic images as sparse files"

2016-04-13T09:12:52+00:00

It turns out that dd's conv=sparse doesn't look at the file extents, but simply checks if a "block" is all zero. If the block of zero was meaningful it gets lost and if the image is subsequently written to media using a sparse-aware writer then the block of zeros won't be written at all. This reverts commit 5fd592fbae2e046bcb8c3a6c3ef4993fe0400676. (From OE-Core rev: 63d15764cc2014dba9fee2186f0c8b97c2ac5682) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

wic/utils/partitionedfs.py: assemble .wic images as sparse files

2016-04-09T22:00:45+00:00

The individual partitions created by wic are sparse but without this change the assembled image is written as one (potentially very) large file. Preserve sparseness in the assembled image by passing the sparse conversion symbol. [YOCTO #9099] (From OE-Core rev: 5fd592fbae2e046bcb8c3a6c3ef4993fe0400676) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

build-perf-test: add eSDK installed size to metrics

2016-04-09T22:00:45+00:00

(From OE-Core rev: 57040305dea7e2167adb47c136a7b85f09ee7d24) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: Create unlocked-sigs.inc containing items in the workspace

2016-04-09T22:00:43+00:00

When a recipe is added to the workspace, the signatures for the tasks will change. This means that bitbake must be told to allow the signatures to be different if they are in locked-sigs.inc. This is done by creating an unlocked-sigs.inc file which contains all the recipes in the workspace each time devtool reads the workspace. So not only will necessary things get added, previously added items will be removed by virtue of them no longer being in the workspace. This also makes sure that the extensible sdk picks up unlocked-sigs.inc as part of the configuration. [YOCTO #9195] (From OE-Core rev: 6b2b5ffdcb8bf885a1c756ea132e9d2c55e13dcd) Signed-off-by: Randy Witt Signed-off-by: Richard Purdie