linux/poky.git/bitbake/lib/bb/fetch2, branch uninative-1.7

bitbake: lib/fetch2/init.py: Fix unpack comment

2017-07-27T14:14:20+00:00

(Bitbake rev: b8f477de204ab5d0680b2b7c42370d13395be46c) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

bitbake: fetch2/init.py: replace stray logger.warn() with logger.warning()

2017-07-25T22:15:53+00:00

Update stray usage of deprecated logger.warn(), which was introduced to fetch2/__init__.py after all other instances had been replaced by logger.warning(): http://git.openembedded.org/bitbake/commit/?id=5a53e7d7b017769a6eb0f0a6335735a1fe51a5ec http://git.openembedded.org/bitbake/commit/?id=676a5f592e8507e81b8f748d58acfea7572f8796 (Bitbake rev: 1b14f115a9e929e29e91e8ac70826a3fe7259961) Signed-off-by: Andre McCurdy Signed-off-by: Richard Purdie

bitbake: fetch/wget: mitigate a wget race condition when listing FTP directories

2017-07-25T14:53:19+00:00

When wget is fetching a listing for a directory over FTP it writes to a temporary file called .listing in the current directory. If there are many such operations happening in parallel - for example during 'bitbake world -c checkpkg' - then up to BB_NUMBER_THREADS instances of wget will be racing to write to, read, and delete the same file. This results in various failures such as the file disappearing before wget has processed it or the file changing contents, which causes checkpkg to randomly fail. Mitigate the race condition by creating a temporary directory to run wget in when doing directory listings. [ YOCTO #11828 ] (Bitbake rev: 91d4ca93df092cf86ab84faaa94cc66ff9f43057) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: fetch2/wget.py: improve error handling during sstate check

2017-07-21T08:26:37+00:00

When the sstate is accessed via HTTP, the existence check can fail due to network issues, in which case bitbake silently continues without sstate. One such network issue is an HTTP server like Python's own SimpleHTTP which closes the TCP connection despite an explicit "Keep-Alive" in the HTTP request header. The server does that without a "close" in the HTTP response header, so the socket remains in the connection cache, leading to "urlopen failed: " (only visible in "bitbake -D -D" output) when trying to use the cached connection again. The connection might also get closed for other reasons (proxy, timeouts, etc.), so this is something that the client should be able to handle. This is achieved by checking for the error, removing the bad connection, and letting the check_status() method try again with a new connection. It is necessary to let the second attempt fail permanently, because bad proxy setups have been observed to also lead to such broken connections. In that case, we need to abort for real after trying twice, otherwise a build would just hang forever. [YOCTO #11782] (Bitbake rev: 6fa07752bbd3ac345cd8617da49a70e0b2dd565f) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

bitbake: fetch2: fire an event when there are missing checksums

2017-07-21T07:41:12+00:00

If BB_STRICT_CHECKSUMS is set to anything other than "1" i.e. we're not going to raise an error, then fire an event so that scripts can listen for it and get the checksums. (Bitbake rev: 8b2ccb4b865f2df118ef668847df682a83f9c500) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch2: allow hiding checksum warning

2017-07-21T07:41:12+00:00

If BB_STRICT_CHECKSUMS is set to "ignore" then don't display a warning if no checksums are specified in the recipe. This is not intended to be used from recipes - it is needed when we move to using more standard code paths to fetch new files from scripts i.e. where we don't know what the checksums are in advance. (Bitbake rev: f15ca7339de8a448a93a14cf6130b3925178a920) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch2: fix indentation

2017-07-18T21:39:33+00:00

(Bitbake rev: 6683338598ce97278f188fbcd780c3e3754e5b9a) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: npm fetcher: fix unknown variable name.

2017-06-29T13:33:42+00:00

'mirrortarball' is supposed to be a local variable to the function. (Bitbake rev: a457cbfb1f20a47db3978290921d0708cd96bd70) Signed-off-by: Ismo Puustinen Signed-off-by: Richard Purdie

bitbake: fetch: fix handling of files with incorrect checksums from a premirror

2017-06-22T08:23:39+00:00

Ensure that when an item fetched from a premirror has an invalid checksum the fetcher falls back to the usual logic of trying the upstream and any configured mirrors. (Bitbake rev: 022adb30dbb0df764c9fb515918cb9a88e4f8d6f) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

bitbake: fetch/git: add support for removing arbitrary revs for shallow

2017-06-02T12:36:57+00:00

In certain cases, it's valuable to be able to exert more control over what history is removed, beyond srcrev+depth. As one example, you can remove most of the upstream kernel history from a kernel repository, keeping predominently the non-publically-accessible content. If the repository is private, the history in that repo couldn't be restored via `git fetch --unshallow`, but upstream history could be. Example usage: # Remove only these revs, not at a particular depth BB_GIT_SHALLOW_DEPTH_pn-linux-foo = "0" BB_GIT_SHALLOW_REVS_pn-linux-foo = "v4.1" (Bitbake rev: 97f856f0455d014ea34c28b1c25f09e13cdc851b) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie