linux/poky.git/bitbake/lib/bb/fetch2/init.py, branch 1.7_M3

bitbake: fetch2: Add module for ClearCase (ccrc://)

2014-07-21T18:24:29+00:00

The clearcase fetcher is used to retrieve files from a ClearCase (http://en.wikipedia.org/wiki/Rational_ClearCase) repository. Usage in the recipe: SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module" SRCREV = "EXAMPLE_CLEARCASE_TAG" PV = "${@d.getVar("SRCREV").replace("/", "+")}" The fetcher uses the rcleartool or cleartool remote client, depending on which one is available. Supported SRC_URI options are: - vob (required) The name of the clearcase VOB (with prepending "/") - module The module in the selected VOB (with prepending "/") The module and vob parameters are combined to create the following load rule in the view config spec: load - proto http or https Related variables: CCASE_CUSTOM_CONFIG_SPEC Write a config spec to this variable in your recipe to use it instead of the default config spec generated by this fetcher. Please note that the SRCREV loses its functionality if you specify this variable. SRCREV is still used to label the archive after a fetch, but it doesn't define what's fetched. User credentials: When using cleartool: The login of cleartool is handled by the system. No special steps needed. When using rcleartool: In order to use rcleartool with authenticated users an `rcleartool login` is necessary before using the fetcher. (Bitbake rev: 76cff0aaad4cf10b325bceadd8ea90b3d75edcc2) Signed-off-by: Dennis Meier Reviewed-by: Roger Meier Reviewed-by: Christian Liechti Reviewed-by: Henrique Mendonca Reviewed-by: Pascal Bach Signed-off-by: Richard Purdie

bitbake: fetch2: improve handling of two classes of URL parameter mistakes

2014-05-30T09:20:25+00:00

Handle the following situations in a URL (e.g. in SRC_URI): * Trailing semicolon in a URL - this is now ignored. * Parameter specified with no value (no equals sign). This still produces an error, but at least it is MalformedUrl with a proper message rather than "ValueError: need more than 1 value to unpack". (Bitbake rev: bfd13dfbc4c9f1dd8315002271791b1d9e274989) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: Fix refetch of local files when they are read only

2014-05-08T15:17:05+00:00

(Bitbake rev: 42b7be1a6c5ff559f4a213eed04b370ca955460d) Signed-off-by: Nick Lewis Signed-off-by: Richard Purdie

bitbake: fetch2: Cleanup file checksum generation, v2

2014-04-29T16:33:58+00:00

The initial version of this patch was reverted in 0a94e568152de550dedc8135a766beb18bf064ab However, it was later agreed upon that it was reverted due to a misunderstanding during code review; the patch is ok. This version of the patch also removes an unneeded initialization of the 'checksum' variable outside the scopes it is being used in. (Bitbake rev: 9ee19a3ca2f8e11a91f0289ea3486310c61d40f2) Signed-off-by: Jacob Kroon Signed-off-by: Richard Purdie

bitbake: Revert "fetch2: Cleanup file checksum generation"

2014-04-28T11:54:06+00:00

This reverts commit 6dfb33fd7204e09815bde7ba5bf21941a73fe965. It causes an unindeded change in behaviour. Signed-off-by: Richard Purdie

bitbake: fetch2: Cleanup file checksum generation

2014-04-27T00:27:55+00:00

Cleanup the fix done in f9416e76e272ba3249abff099f6f3a47fe82e03e. Instead of adding continue statements we can just move the last statements into the final else-clause. (Bitbake rev: 6dfb33fd7204e09815bde7ba5bf21941a73fe965) Signed-off-by: Jacob Kroon Signed-off-by: Richard Purdie

bitbake: fetch2: fix traceback when a wildcard matches a directory

2014-04-08T17:05:26+00:00

If there is a directory matching a wildcard in SRC_URI when getting file checksums, we should recurse into that instead of producing an error. (Bitbake rev: ae87b7eb414e3d5eefd2effec7b30c22d2186b02) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch2: handle wildcards correctly when recording file checksums

2014-04-08T17:05:26+00:00

The Local fetcher's localpath is returning the parent directory for a wildcard match; we need to handle this and add the wildcard specification so that we checksum the correct files. Fixes [YOCTO #6127]. (Bitbake rev: 4a90edd62c16cbf41b5b93280e155077564c774a) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch2: avoid cache ignoring missing files

2014-04-08T12:07:25+00:00

Previously, if a file listed in SRC_URI was missing at the time of parsing, and then was added and bitbake run again, it would not be picked up because the recipe was cached without it. If we allow the file to be added to the list of files to checksum, then it will be checked for and found on the second run. Fixes [YOCTO #4790]. (Bitbake rev: 71da822762cb298261cccdfa54b9c0fea02c3c5d) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: fetch2: Fix bug in file checksum generation

2014-04-06T10:31:26+00:00

For a while its been puzzling me why connman-gnome rebuilds as often as it does. It turns out you can trigger this with a new checkout of the metadata. The SRC_URI that is causing the problems is: SRC_URI = "file://images/*" and rather oddly the results in checksums for a file "." being added to the tree, e.g.: ('.', 'ab48a68186f0e0f277c21ef4cb390b4b') The problem is that when iterating files lists, the checksum variable can become set yet we don't break the out from the for loop, which leads to odd (and non-deterministic) entries being added into the file checksum list. The exact item added probably depends on the order of items on the disk. Before this change, bitbake-diffsigs on connman-gnome:do_fetch would report: This task depends on the checksums of files: [ ('connman-signal-03.png', 'f6c16aee57b37b73793a2f1dea433ffa'), ('connman-signal-02.png', 'ad0cd22710c097d8174121fc1023c3be'), ('connman-signal-01.png', '8842bd83d2fa9ba56480df34c727c629'), ('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'), ('connman-signal-05.png', '808589e7e8d502b44c7b007e9e68d48c'), ('connman-signal-04.png', 'ab48a68186f0e0f277c21ef4cb390b4b'), ('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'), ('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'), ('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'), ('.', 'ab48a68186f0e0f277c21ef4cb390b4b')] Afterwards: This task depends on the checksums of files: [ ('connman-signal-03.png', 'f6c16aee57b37b73793a2f1dea433ffa'), ('connman-signal-02.png', 'ad0cd22710c097d8174121fc1023c3be'), ('connman-signal-01.png', '8842bd83d2fa9ba56480df34c727c629'), ('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'), ('connman-signal-05.png', '808589e7e8d502b44c7b007e9e68d48c'), ('connman-signal-04.png', 'ab48a68186f0e0f277c21ef4cb390b4b'), ('null_check_for_ipv4_config.patch', 'a23271e41c9fe81551244d875106af10'), ('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85'), ('0001-Removed-icon-from-connman-gnome-about-applet.patch', 'e2d8269357c1e8c84291606da24eea85')] which is correct and deterministic without the "." entry. (Bitbake rev: f9416e76e272ba3249abff099f6f3a47fe82e03e) Signed-off-by: Richard Purdie

linux/poky.git/bitbake/lib/bb/fetch2/__init__.py, branch 1.7_M3