From: pedro.ms.ferreira@ctw.bmwgroup.com
To: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH] fetch2: avoid reuse download filenames
Date: Thu, 05 Mar 2026 02:22:40 -0800 [thread overview]
Message-ID: <245205.1772706160236503925@lists.openembedded.org> (raw)
In-Reply-To: <e58fedf42052698a50007bd5d49a70e0b77aa702.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]
Hi Richard,
I tested a few scenarios to be sure that this is not blocking or changing behavior apart from the one use case that im trying to fix.
Use case 1
- No local file
- Two mirrors with the source file:
- Mirror 1: 7da977765ddfe7a38e72905d6e2ae71b
- Mirror 2: 12e597833772126eade44740570aab3c
- Recipe points SRC_URI to 12e597833772126eade44740570aab3c
- PREMIRRORS appended with both http servers
bitbake -C fetch local-test - Succeeds
---------------------------------------------------------------------------------------------------
WARNING: local-test-1.0-r0 do_fetch: Checksum mismatch for local file (...) /yocto-downloads/test_download.tar.gz
Cleaning and trying again.
WARNING: local-test-1.0-r0 do_fetch: Renaming (...)/yocto-downloads/ test_download.tar.gz to (...) /yocto-downloads/ test_download.tar.gz_bad-checksum_f03e325aa451beda1b340a7ce0fcfd620b74c86e12b8156a3d4949f7de67fc87
WARNING: local-test-1.0-r0 do_fetch: Checksum failure encountered with premirror download of http://0.0.0.0:1234/ test_download.tar.gz - will attempt other sources.
---------------------------------------------------------------------------------------------------
Use case 2
- No local file
- Two mirrors with the source file:
- Mirror 1: 7da977765ddfe7a38e72905d6e2ae71b
- Mirror 2: 7da977765ddfe7a38e72905d6e2ae71b
- Recipe points SRC_URI to 12e597833772126eade44740570aab3c
- PREMIRRORS appended with both http servers
bitbake -C fetch local-test - Fails
---------------------------------------------------------------------------------------------------
ERROR: local-test-1.0-r0 do_fetch: Fetcher failure for URL: 'http://0.0.0.0:1234/test_download.tar.gz'. Checksum mismatch!
File: '(...)/yocto-downloads/test_download.tar.gz.tmp' has sha256 checksum 'f03e325aa451beda1b340a7ce0fcfd620b74c86e12b8156a3d4949f7de67fc87' when '0f27e2d871ee8ae4784e4461ea2c35190df94ec8e8b07caba80056b2520999e1' was expected
If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:
SRC_URI[sha256sum] = "f03e325aa451beda1b340a7ce0fcfd620b74c86e12b8156a3d4949f7de67fc87"
Otherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.
ERROR: local-test-1.0-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'http://0.0.0.0:1234/test_download.tar.gz')
ERROR: Logfile of failure stored in:(...)/qemux86-64/build/tmp/work/core2-64-poky-linux/local-test/1.0/temp/log.do_fetch.13826
ERROR: Task (.../local-test/local-test.bb:do_fetch) failed with exit code '1'
---------------------------------------------------------------------------------------------------
Use case 3 (Target scenario with the patch proposed)
- Local file (7da977765ddfe7a38e72905d6e2ae71b)
- Two mirrors with the source file:
- Mirror 1: 12e597833772126eade44740570aab3c
- Mirror 2: 12e597833772126eade44740570aab3c
- Recipe points SRC_URI to 12e597833772126eade44740570aab3c
- PREMIRRORS appended with both http servers
bitbake -C fetch local-test - Fails
---------------------------------------------------------------------------------------------------
ERROR: local-test-1.0-r0 do_fetch: Checksum mismatch for local file (...)/yocto-downloads/test_download.tar.gz
ERROR: Logfile of failure stored in: (...)/qemux86-64/build/tmp/work/core2-64-poky-linux/local-test/1.0/temp/log.do_fetch.28967
ERROR: Task (.../local-test/local-test.bb:do_fetch) failed with exit code '1'
---------------------------------------------------------------------------------------------------
I think this covers at least the most common cases, imho it makes sense to block any attempt of users to overwrite old source files,
and this should be user responsibility to fix the recipe.
If you have any other use case in mind please let me know.
Cheers.
[-- Attachment #2: Type: text/html, Size: 5244 bytes --]
next prev parent reply other threads:[~2026-03-05 10:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 15:14 [PATCH] fetch2: avoid reuse download filenames Pedro Ferreira
2026-03-02 15:56 ` [bitbake-devel] " Richard Purdie
2026-03-02 16:54 ` pedro.ms.ferreira
2026-03-02 17:17 ` [bitbake-devel] " Yoann Congal
2026-03-05 10:22 ` pedro.ms.ferreira [this message]
2026-03-05 7:39 ` Mathieu Dubois-Briand
2026-03-05 15:21 ` pedro.ms.ferreira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=245205.1772706160236503925@lists.openembedded.org \
--to=pedro.ms.ferreira@ctw.bmwgroup.com \
--cc=bitbake-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox