linux/poky.git/bitbake/lib/bb/fetch2, branch 1.2_M4.rc3.1

Hob: add fadeout display effection for recipe view include page

2012-04-10T23:04:44+00:00

As UI request, in recipes selection page, if user exclude a item, the related depends recipes will be excluded together,so the view clearly to add it. [YOCTO #2100] (Bitbake rev: c9eed04c6275ef2c694f89e047f85c7de76f89b6) Signed-off-by: Liming An Signed-off-by: Shane Wang Signed-off-by: Richard Purdie

bitbake/fetch2: Ensure mirror tarballs have .done stamps so we don't redownload and corrupt them

2012-03-23T14:54:16+00:00

[YOCTO #2154] (Bitbake rev: 521d6b14151d3bf934b9597557f7ae46e50a3d7a) Signed-off-by: Richard Purdie

bitbake/fetch2: Fix typo which broke use of tarballs

2012-03-16T23:44:23+00:00

(Bitbake rev: 5a1e62a8cdd4f0253b0dc59046b3b4c3186af461) Signed-off-by: Gary Thomas Signed-off-by: Richard Purdie

bitbake/fetch: Fix uri_replace

2012-03-15T22:56:16+00:00

We were seeing duplicate endings to urls: DEBUG: For url ['http', 'www.apache.org', '/dist/subversion/subversion-1.7.1.tar.bz2', '', '', {}] comparing ['http', 'www.apache.org', '/dist', '', '', {}] to ['http', 'archive.apache.org', '/dist', '', '', {}] DEBUG: For url http://www.apache.org/dist/subversion/subversion-1.7.1.tar.bz2 returning http://archive.apache.org/dist/subversion/subversion-1.7.1.tar.bz2/subversion-1.7.1.tar.bz2 This patch addresses this by only performing substitutions when really needed. (Bitbake rev: a17473d51f54a9dfb4eeaa5ad516c4851d5ac142) Signed-off-by: Richard Purdie

stderr would previously be appended to stdout, corrupting the result when something was outputed to stderr but exit code was still 0 (non-fatal warning messages). This commit makes the code parse only stdout, but output stderr if an error happened.

2012-03-02T16:22:46+00:00

(Bitbake rev: 4a480a052f450c4ee061ab0e60a495a45f140cf9) Signed-off-by: Adrien Bustany Signed-off-by: Richard Purdie

fetch2/git: create bareclone option

2012-02-24T16:40:08+00:00

For similar reasons as the nocheckout option, packages that need enhanced control over the checkout and branch creation on a repository may want a complete mirror/bareclone created of the repository when performing the unpack. This is useful/required when a local respository is being used, but local tracking branches have not been created for all branches that a given recipe needs to manipulate. The standard git clone operations will create remote branches for the branches that are local to the source repository, but branches that are remote do not translate to the destination repository. Doing a mirror/bare clone of the source, makes all branches available to the repository. This is a particular use case, but the ability to do a bare clone creates great flexibility in recipe space, with no impact to recipes that don't need this functionality. To implement this, a new option 'bareclone' is craeted which creates a mirror copy of the repository and leaves it bare in the unpacking phase. A recipe that uses this option must both checkout and debare the repository itself. (Bitbake rev: 82482aae6f311c994275fb0b6b32d954bbfc78c3) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

fetch2/git: Add workaround for clone using alternates problem

2012-02-01T15:08:43+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

bitbake/fetch2: allow resuming interrupted fetch

2012-01-20T16:47:39+00:00

A lot of our checks in the fetcher code assume that if the downloaded file exists, the download finished successfully; this meant that if BitBake was interrupted in the middle of a fetch then it would not resume the fetch the next time, but instead attempt to use the half-fetched file and usually fail as a result. Since we're already writing a ".done" stamp file when a fetch completes, just check for its existence and assume the download didn't complete successfully if it isn't present. (Bitbake rev: 721e986624529aedef96dd06c9fe6243f2897b10) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake/fetch2: reduce output for fetch failures

2012-01-15T10:06:22+00:00

Make the warning for the initial fetch failure a single line - we don't need the full command and output here yet, but write it into the log in full as a debug message. However, if fetching from mirrors fails as well then print out the full details for the first error that occurred as an ERROR rather than a WARNING. Since this is logged as an ERROR, combined with an earlier patch it suppresses the full log which does make the output much more readable for any fetch error. Fixes [YOCTO #1832]. (Bitbake rev: 6bbdc7d259c0cc041b62dbdb26cfc3ec6edcb6f3) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake/fetch2: correctly decode exit signal/status

2012-01-15T10:06:21+00:00

The termination signal and exit code of the fetch process were not being decoded correctly, resulting in bitbake reporting that the process terminated with a signal of the exit code (if it was under 255). There are functions in the Python os module to do this decoding correctly (for Unix at least), so let's use them. (Bitbake rev: 50aea9a76e40cf71cc3f1462c88298e4846a031c) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie