Bug 4622 - buildhistory fails or reports wrong info when building 2 SDK images in one bitbake call
Summary: buildhistory fails or reports wrong info when building 2 SDK images in one bi...
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.4
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.5
Assignee: Paul Eggleton
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2013-06-06 18:26 UTC by Martin Jansa
Modified: 2013-06-12 09:33 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Jansa 2013-06-06 18:26:55 UTC
buildhistory_get_sdk_installed doesn't work well when 2 sdk images are built at the same time, they share some temporary files ($1 is set to "target" or "host")
POPULATE_SDK_POST_TARGET_COMMAND_append = "buildhistory_get_sdk_installed target ; "
POPULATE_SDK_POST_HOST_COMMAND_append = "buildhistory_get_sdk_installed host ; "

shared files:
pkgcache="$1/installed-packages.tmp"
$1/depends.tmp
$1/depends.dot
$1/installed-package-sizes.tmp
$1/installed-package-sizes.txt
4 more $1/depends-*dot are used only when != sdk

when 2 tasks run together, the 2nd fails with
rm: cannot remove '/OE/shr-core/buildhistory/sdk/oecore-i686-cortexa8-vfp-neon/target/installed-packages.tmp': No such file or directory

and even the 1st can have invalid buildhistory info (some parts could be overwritten from 2nd task)
Comment 1 Martin Jansa 2013-06-06 21:32:03 UTC
Now when it completed successfully I can see that's a bit worse, both SDK images are written to the same directory in buildhistory, this is from building
meta-toolchain-gmae and then meta-toolchain-efl:

https://github.com/shr-distribution/buildhistory/commit/27d505b4f4c1730d187a84413bbc05f01f69d953

It would be nice to put them in "sdk name" directory like it's done for normal images.
Comment 2 Paul Eggleton 2013-06-07 16:37:13 UTC
I've sent a patch to add IMAGE_BASENAME to the path within buildhistory to avoid this issue.
Comment 3 Martin Jansa 2013-06-07 16:47:44 UTC
Thanks for quick fix.