linux/poky.git/bitbake/lib/bb/fetch2, branch 5.2_M1

bitbake: fetch2: fix unpack of a single zstd file

2024-11-29T18:26:14+00:00

do_unpack generates a 'Bitbake Fetcher Error: UnpackError' when uncompressing a single 'file.zst', zstd command line returns the error 'unexpected end of file', and the input file 'file.zst' becomes empty. The command line is 'zstd --decompress --stdout file.zst > file.zst'. So the issue is that the input and output filenames are the same. Fix the output filename when using zstd for a single file. (Bitbake rev: 5881ca0e0d53937cd25a57ff682a3b7577b0b7f8) Signed-off-by: Pascal Eberhard Signed-off-by: Richard Purdie

bitbake: fetch/wget: Increase timeout to 100s from 30s

2024-11-21T12:16:28+00:00

Testing shows the worst case CDN response time can be up to 100s. The wget fetcher is used for accessing sstate from the CDN so increase our timeouts there to match our worst case repsonse times. (Bitbake rev: 7aca591529e115bc277f93811d8c586630acc8c3) Signed-off-by: Richard Purdie

bitbake: git: Clean broken symlink

2024-10-28T14:08:33+00:00

The file may be a symlink when mirror from local disk, and the symlink will be broken when the linked file is removed, use os.path.islink() to check and remove the broken symlink. (Bitbake rev: d0deb5fe6e7a84b07b49ef685b209729d2fdc780) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: git: Clean shallow mirror tarball

2024-10-28T14:08:33+00:00

Fixed: BB_GIT_SHALLOW = "1" BB_GENERATE_SHALLOW_TARBALLS = "1" $ bitbake utfcpp -cfetch && bitbake utfcpp -ccleanall The downloads/gitsmshallow_github.com.nemtrif.*.tar.gz won't be cleaned without this fix. (Bitbake rev: bab7a8970a0237a9d24217685a595e76a1336c07) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: gitsm: Add clean function

2024-10-28T14:08:33+00:00

Fixed: $ bitbake utfcpp -cfetch && bitbake utfcpp -ccleanall The downloads/git2/github.com.nemtrif.ftest won't be cleaned without this fix. (Bitbake rev: 79f25fc5c1b8d0e08540f4aa07875309f5325f47) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: gitsm: Remove downloads/tmpdir when failed

2024-10-28T14:08:33+00:00

The tmpdir such as downloads/tmplp3cnemv won't be removed without this fix. (Bitbake rev: 2ba8d3214759142afc11f0a88d80eb30a8bcde3a) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: gitsm: Add call_process_submodules() to remove duplicated code

2024-10-28T14:08:33+00:00

There are 14 lines can be removed, and can make it easy to maintain. (Bitbake rev: 0ea2c1ac079d63349407a69172ff80cd9acc7252) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: fetch2/wget: set User-Agent to 'bitbake/version' in checkstatus()

2024-10-22T10:16:32+00:00

This eliminates the last usage of 'fake mozilla' in bitbake, and it's then truthful everywhere about presenting itself, or wget (when that is used). I understand this will make people nervous so I want to provide an extended decription. 1. How was this tested? - bitbake-selftest -k FetchCheckStatusTest (tests a few hardcoded URIs, all passed) - bitbake -k -c checkuri world (runs checkstatus() over all recipes in oe-core, and all passed again - this hopefully goes a long way to reassure everyone that hosts around the world and various CDNs typically do not have a problem with user-agent strings they haven't seen before or bitbake user-agent specifically) 2. What about that removed cloudflare comment? I digged into git history, and I think it is not fully accurate. First, 'fake mozilla' agent is used only for checkstatus() - in actual fetching with wget it is not. And that has not been a problem for anyone. Second, here's how the comment occured. Usage of 'fake mozilla' was introduced here: https://git.yoctoproject.org/poky/commit/?h=master&id=ab26fdae9e5ae56bb84196698d3fa4fd568fe903 At that point it did not have to be specifically 'mozilla', the commit message indicates that any User-Agent would have been ok. Mozilla was simply copied from upstream version check for convenience. Later on, the string was updated to a more recent Mozilla: https://git.yoctoproject.org/poky/commit/?h=master&id=9f123238261a68e37cec634782e9320633cac5d4 The claim in the added comment become something else: that User-Agent *must* a browser, without evidence or tests. Even though it demonstrably doesn't have to be - wget is ok. 3. What if someone has a server that is ok with wget agent, but not ok with bitbake agent? Please see point one. It's not impossible but I think it's highly unlikely. I do think we should rather tell servers the truth, and learn where the actual issues are. Then we can consider options - whether that would be pretending to be wget, or allowing user-agent to be configured. We should also add such servers to bitbake-selftest so we know what they are. (Bitbake rev: 234f9e810494394527f59fdf22eb86435d046d53) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: fetch2/wget.py: use default wget user-agent in upstream version checks

2024-10-22T10:16:32+00:00

This has been set to various mozilla versions from this point onwards without explanation or specific examples: https://git.yoctoproject.org/poky/commit/?h=master-next&id=ba06cc8943d021f406c3d292ce415b77319ca5c6 However, sourceforge has recently banned the current 'fake mozilla' version we've been supplying, resulting in broken version checks: alex@Zen2:/srv/storage/alex/yocto/build-test-sourceforge$ devtool check-upgrade-status gptfdisk ... --2024-10-12 11:53:23-- https://sourceforge.net/projects/gptfdisk/files/gptfdisk/ Resolving sourceforge.net (sourceforge.net)... 172.64.150.145, 104.18.37.111, 2606:4700:4400::6812:256f, ... Connecting to sourceforge.net (sourceforge.net)|172.64.150.145|:443... connected. HTTP request sent, awaiting response... 403 Forbidden 2024-10-12 11:53:24 ERROR 403: Forbidden. gptfdisk 1.0.10 UNKNOWN_BROKEN Alexander Kanavin On the other hand, using wget's default user-agent works just fine: --2024-10-12 12:16:06-- https://sourceforge.net/projects/gptfdisk/files/gptfdisk/ Resolving sourceforge.net (sourceforge.net)... 104.18.37.111, 172.64.150.145, 2606:4700:4400::6812:256f, ... Connecting to sourceforge.net (sourceforge.net)|104.18.37.111|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] (Bitbake rev: 138117dfc05248dcb48707c838c8c1cc09f12d07) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: fetch2: add GitHub Codespaces support

2024-10-14T20:44:38+00:00

GitHub Codespaces allow users to use GitHub-hosted pre-configured Docker containers to work on GitHub repositories in VS Code within the browser or using a locally running instance of VS Code [1]. Users can define access permissions for Codespaces containers, allowing them to clone or work with other private repositories [2]. To do this, a git credential helper is injected into the container at /.codespaces/bin/gitcredential_github.sh, which contains the following lines: #!/bin/sh echo protocol=https echo host=github.com echo path= echo username=PersonalAccessToken echo password=$GITHUB_TOKEN The `GITHUB_TOKEN` environment variable is automatically set when the Codespaces container is created. If authorized by the user, it has the specified permissions. It is thus required to be able to fetch private git repos from a Codespace container, so add it to `FETCH_EXPORT_VARS` to make it available for invocations of git. [1] https://docs.github.com/en/codespaces/overview [2] https://docs.github.com/en/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces (Bitbake rev: 71ca83bdd541f70737a3a85f05e40c222611af2f) Signed-off-by: Oliver Kästner Signed-off-by: Richard Purdie