linux/poky.git/scripts, branch 1.5_M5.rc5

scripts/runqemu: write temp file into correct location

2013-09-24T16:57:03+00:00

We want the temporary file to be written in /tmp not the current directory. (From OE-Core rev: fcb40c11998030eb5fce89ce5a9ca567870aafa9) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

yocto-bsp: add 3.10/remove 3.8 kernel from templates

2013-09-24T11:01:47+00:00

For Yocto 1.5, 3.10 is the preferred kernel and 3.8 is obsolete. This also removes any mention of emgd from the templates - we want to discourage users from using it - it will be obsolete soon in any case. Fixes [YOCTO #5107] (From meta-yocto rev: 4dd4bf6ac2dcc7652ec8f807df02298546bdb41b) Signed-off-by: Tom Zanussi Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

runqemu: set qemuarm memory size back to 128MB

2013-09-22T11:19:41+00:00

The following commit, 6ccd4d6, increased the RAM size for qemu machines to 256MB due to some smart sanity tests failing on autobuilder because more memory was needed. Unfortunately this leads to various, potentially dangerous, issues like the one observed during sudoku-savant project compilation: collect: relinking collect2: error: '_ZNK6sudoku5ClearINS_6SquareEEclERS1_' was assigned to 'board.rpo', but was not defined during recompilation, or vice versa board.o:(.rodata+0x8): undefined reference to `sudoku::Clear::operator()(sudoku::Square&) const' board.o:(.rodata+0x20): undefined reference to `sudoku::Clear::operator()(sudoku::Sequence&) const' board.o:(.rodata+0x34): undefined reference to `typeinfo for sudoku::Action' ...AND THE LIST CONTINUES... collect2: error: ld returned 1 exit status make: *** [sudoku-savant] Error 1 After some tests, I found that the maximum amount of memory needed for sudoku to compile properly is 146MB(!?!). My attempts to create a simpler test case (using templates), in order to replicate and isolate the issue failed. All the tests compiled just fine. So, my guess is that this problem is certainly memory related but the cause might be hidden in any of the following: qemu versatile hw model, in the kernel or, highly unlikely but not impossible, the toolchain itself. The reason I don't really think the cause is in the toolchain is the fact that the compilation completes just fine for 128MB on qemuarm but also on other qemu machines (with 256MB of memory). Since this issue might need lots of time to have a proper fix, I'll revert back to using 128MB for qemuarm for the time being. [YOCTO #5133] (From OE-Core rev: 06605bd6ddd4d6a788e1a107dcf15dde1027c094) Signed-off-by: Laurentiu Palcu Signed-off-by: Richard Purdie

classes/imagetest-qemu: remove old image testing class

2013-09-22T11:19:41+00:00

This has now been superseded by testimage. (From OE-Core rev: d469c92394a1a95ae7a45b8b80dc4c2918e0e9a6) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

wipe-sysroot: delete pkgdata stamps

2013-09-22T11:19:32+00:00

The pkgdata stamps now need to be wiped away if the sysroot is destroyed. (From OE-Core rev: e6ef8399cd8e97b9cd59855e11f1792445f0e65b) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts/contrib/build-perf-test.sh: record size in kb and remove extra spaces

2013-09-14T07:29:41+00:00

(From OE-Core rev: 8c2b5948d41d753982242cd86a1498ab4f1bb317) Signed-off-by: Stefan Stanacar Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific directory

2013-09-14T07:21:00+00:00

Currently we have a hierarchy of pkgdata directories and the code has to put together a search path and look through each in turn until it finds the data it needs. This has lead to a number of hardcoded paths and file globing which is unpredictable and undesirable. Worse, certain tricks that should be easy like a GL specific package architecture become problematic with the curretn search paths. With the modern sstate code, we can do better and construct a single pkgdata directory for each machine in just the same way as we do for the sysroot. This is already tried and well tested. With such a single directory, all the code that iterated through multiple pkgdata directories and simply be removed and give a significant simplification of the code. Even existing build directories adapt to the change well since the package contents doesn't change, just the location they're installed to and the stamp for them. The only complication is the we need a different shlibs directory for each multilib. These are only used by package.bbclass and the simple fix is to add MLPREFIX to the shlib directory name. This means the multilib packages will repackage and the sstate checksum will change but an existing build directory will adapt to the changes safely. It is close to release however I believe the benefits this patch give us are worth consideration for inclusion and give us more options for dealing with problems like the GL one. It also sets the ground work well for shlibs improvements in 1.6. (From OE-Core rev: 1b8e4abd2d9c0901d38d89d0f944fe1ffd019379) Signed-off-by: Richard Purdie

bitbake.conf: include machine name in DEPLOY_DIR_IMAGE

2013-09-14T07:21:00+00:00

This allows a clean seperation between image outputs from different machines, and makes it possible to have convenience symlinks to make the output ready to deploy. This did require some surgery in runqemu; if explicit paths to the image and kernel are not supplied then DEPLOY_DIR_IMAGE needs to be determined from bitbake or set in the environment. However the script does try to avoid requiring it unless it really is needed. Corresponding changes were made in the automated testing code as well. Based on an RFC patch by Koen Kooi (From OE-Core rev: 7e90261aec61f79680b5eaeaf5b18c7b795412a4) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bb-matrix-plot: Use interpolation for sparse data

2013-09-14T07:21:00+00:00

If not every combination of BB_NUMBER_THREADS and PARALLEL_MAKE have been tested by bb-matrix.sh, e.g., by using BB_RANGE="04 08 10 12 16" and PM_RANGE="04 08 10 12 16", then the graph that gnuplot generates by default looks very jagged due to the missing data points. By using splines to interpolate the missing data the graph looks a lot better. This should not change graphs where all data points are available in any way, only improve sparse graphs. (From OE-Core rev: 9642c1314da64c70254f6b012aa73ef37bbaa33f) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bb-matrix: Clean before, rather than after, building

2013-09-14T07:20:59+00:00

This makes sure the the first build starts from a clean state. Otherwise one could have the first build affected by any leftover state from a previous build. This also leaves a working state behind after the final build. (From OE-Core rev: f8f86ac88aa1bba99ba28762cfbd97d3721da7d9) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie