linux/poky.git/bitbake, branch genericarm64

bitbake: Revert "bitbake: wget.py: always use the custom user agent"

2024-02-20T12:56:40+00:00

This reverts commit 987ab2a446aab235d6e86e97c05f25fb800d7acc. There's been a report that this breaks downloads from Jfrog Artifactory as self.user_agent is set to 'Mozilla Firefox', and when Artifactory sees that, it sends a response tailored for showing in an interactive browser (which in my opinion it has every right to). If we're using wget, we should say so via wget's default; handling uncooperative servers should be done on per-recipe basis, and ideally with tickets to admins of those servers. (Bitbake rev: feef5cd12e877f42ffcace168d44b0e6eb80a907) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

bitbake: fetch2/git: Make latest_versionstring extract tags with slashes correctly

2024-02-19T15:08:30+00:00

Before, everything up to the last slash was removed when extracting the names of the tags. This would lead to that a tag such as "agent/11.0.0" would be incorrectly identified as "11.0.0", which would then be treated as a correct version matching "^(?P\d+(\.\d+)+)". (Bitbake rev: 8b21024b9966d5158ac4a77e87ffb935c2a57764) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: fetch2/git: A bit of clean-up of latest_versionstring()

2024-02-19T15:08:30+00:00

This is mostly preparations for the next commit. (Bitbake rev: dcd2abfde55cc59d9869a7c97620b6fc30a52047) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: tests/fetch: Make test_git_latest_versionstring support a max version

2024-02-19T15:08:30+00:00

In some cases, the version found by latest_versionstring() may be higher than the real version. Make it possible to specify a maximum version so that this case can be detected. (Bitbake rev: 9134d4777109bc78410c3e641420d9a78b485e33) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

bitbake: fetch2/git.py: add comment in try_premirrors

2024-02-19T15:08:30+00:00

The purpose of ensuring 'incremental fetch' is not easy to see from the codes. So add comments to explain this. (Bitbake rev: 8b890b87e30cd05ec92ed71ee3691a47b4d77253) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: tests/fetch.py: add test case for using premirror in restricted network

2024-02-19T15:08:30+00:00

We had issue when BB_ALLOWED_NETWORKS is set and `bitbake grpc-native -c fetch' failed even with all contents available in PREMIRRORS. Add a test case to ensure no regression in the future. (Bitbake rev: 80c91ceb81b1cae203067af58d3f1fe9c619ae83) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: fetch2/git.py: fix a corner case in try_premirror

2024-02-19T15:08:30+00:00

For gitsm recipes, it's possible that some URL is used more than once. e.g., A -> B:rev1 (B is a submodule of A) A -> C (C is a submodule of A) C -> B:rev2 (B is a submodule of C) A anc C are both using B as submodules, but on different revs. Now if we have: B:rev1 -> D B:rev2 -> E Then, the mirror will not be fully used. Say we have all repo mirrors for A, B, C, D, E, then in theory it's not necessary to reach out to any network for downloading. But it's not the case. After downloading B(rev1) and its submodule D from mirrors, the fetch process continues to download C, thus B(rev2) and E. Now it finds that B needs an update because its submodule E needs an update. Of course this is true because E is not downloaded yet. Now the problem comes to whether to use mirror or not. The git.py defines try_premirror to return 'False' when the ud.clonedir exists. As B has been cloned, the ud.clonedir exists and try_mirror returns False, resulting in not using mirror and going to upstream directly. We can see that the mirrors are not fully used. This is usually not problem, as the cost is only some network download. But in case the following two settings are there, we get errors. BB_NO_NETWORK = "0" BB_ALLOWED_NETWORKS = "*.some.allowed.domain" In such case, the gitsm recipe A will fail to fetch. Note that all contents that A needs are in mirrors and now it's failing to fetch. This is unexpected. Note that the different revs of the same repo in gitsm recipe is not the only way to reveal this problem. For example, there might be a recipe call B that uses B:rev3. Check the protobuf and grpc recipes as an example. For now, we can use the following steps to reproduce this issue. To be clear, the grpc recipe in meta-oe is now 1.60.0. 1. Add in local.conf: DL_DIR = "${TOPDIR}/downloads-premirror" bitbake grpc -c fetch 2. Comment out the DL_DIR setting in local.conf and add the following lines: PREMIRRORS:append = " \ git://.*/.* git://${TOPDIR}/downloads-premirror/git2/MIRRORNAME;protocol=file \n \ gitsm://.*/.* gitsm://${TOPDIR}/downloads-premirror/git2/MIRRORNAME;protocol=file \n \ " 3. Set BB_NO_NETWORK = "1" and then 'bitbake grpc -c fetch'. This command succeeds and this shows that the premirror holds everything we need. 4. Add the following lines and then 'bitbake grpc -c fetch'. BB_NO_NETWORK = "0" BB_ALLOWED_NETWORKS = "*.some.domain" After step 4, the error message is as below: ERROR: grpc-1.60.0-r0 do_fetch: The URL: 'gitsm://github.com/protocolbuffers/protobuf.git;protocol=https;name=third_party/protobuf;subpath=third_party/protobuf;nobranch=1;lfs=True;bareclone=1;nobranch=1' is not trusted and cannot be used This patch fixes this problem by handling this corner case, that is, if the URL is not trusted from the settings of BB_NO_NETWORK and BB_ALLOWED_NETWORKS, then we should try premirrors because trying to reach upstream is destined to fail. (Bitbake rev: e1be272ad105b47d3131b77168d9172386993fcb) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

bitbake: tests/fetch.py: add multiple fetches test

2024-02-19T12:52:30+00:00

Fetch from premirror few times to emulate multiple machines sharing same clonedir or few rebuilds of the package from (pre)mirror Regression test for [Yocto #15369] (Bitbake rev: 7fcbac574c68f16b95ab7abb2874931d168d3c9e) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie

bitbake: fetch2/git.py: Fetch mirror into HEAD

2024-02-19T12:52:30+00:00

Fix the issue with using of (pre)mirror in case if clonedir exists but outdated. Previous version of the code fetched new mirror content into FETCH_HEAD instead of branch which caused refetch from the upstream. Add new remote add fetch from it instead so the ref can be found by "_contains_ref" Fixes [Yocto #15369] (Bitbake rev: 69588e2a5c7c200e47b02b2391498dcb72388bd2) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie

bitbake: git-make-shallow: support git's safe.bareRepository

2024-02-19T12:00:59+00:00

When git is configured with safe.bareRepository=explicit [1], the git-make-shallow fails miserably. LWN has an article about the problem that this configuration option addresses and why it is useful in [2]. It also seems that it is being rolled out in some environments as a default for users. In order to allow having this configuration turned on for a user's environment in general, the fetcher has to be tought to use --git-dir= for all relevent git operations. The alternative, implemented here, is to forcibly turn off that option for all git operations. In the future, we could look into converting these to using the --git-dir= command line argument instead. Link: https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/config/safe.txt#n1 [1] Link: https://lwn.net/Articles/892755/ [2] (Bitbake rev: 7c63989db4590564516ed150930f4e2fa503e98f) Signed-off-by: André Draszik Signed-off-by: Richard Purdie