linux/poky.git/bitbake, branch edison

bitbake/persist_data: Reconnect when DB is locked

2012-05-31T20:16:41+00:00

[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 Signed-off-by: Richard Purdie Signed-off-by: Joshua Lock

runqueue.py: Add inter setscene task dependency handling

2012-05-31T20:16:41+00:00

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 Signed-off-by: Joshua Lock

runqueue.py: Fix missing setscene dependencies

2012-05-31T20:16:41+00:00

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 Signed-off-by: Joshua Lock

fetch2/git: Add workaround for clone using alternates problem

2012-02-03T17:42:14+00:00

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

ui/crumbs/hobprefs: trigger a reparse after changing IMAGE_FSTYPES

2012-01-30T16:16:13+00:00

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 Signed-off-by: Richard Purdie

ui/crumbs/runningbuild: handle InvalidTask events

2012-01-30T16:16:13+00:00

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 Signed-off-by: Richard Purdie

siggen.py: If both sigs have a variable in it's whitelist then don't say it's changed

2012-01-30T16:16:13+00:00

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 Signed-off-by: Richard Purdie

bitbake: Update and fix bitbake-runtask

2012-01-30T16:16:13+00:00

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 Signed-off-by: Richard Purdie

bitbake/siggen.py: Don't backtrace if the taskhash data isn't present

2012-01-30T16:16:13+00:00

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

build.py: Be determistic about a function's cwd

2012-01-30T16:16:13+00:00

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