A bit surprised by this one. ERROR: ExpansionError during parsing /tmp/devtoolqazanfp7bs/core-copy/meta/recipes-extended/bzip2/bzip2_1.0.8.bb bb.data_smart.ExpansionError: Failure expanding variable fetcher_hashes_dummyfunc[vardepvalue], expression was ${@bb.fetch.get_hashvalue(d)} which triggered exception FetchError: Fetcher failure: The SRCREV_FORMAT variable must be set when multiple SCMs are used. The SCMs are: git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests;branch=master;protocol=https git://sourceware.org/git/bzip2-tests.git;name=bzip2-tests;branch=master;protocol=https;type=git-dependency The variable dependency chain for the failure is: fetcher_hashes_dummyfunc[vardepvalue] So this is twice the same git, with just `;type=git-dependency` added. Of course it only appears once in the recipe.
oe-selftest-fedora rocky8-vk-1 master completed at 2025-05-03T03:18:17Z https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/1421/steps/15/logs/stdio
RP suspects that this is a network glitch. It has been seen before.
Likely a network glitch, perhaps due to the high load due to AI site scrapping. Re-open if it happens again.
It happened again :( whinlatter oe-selftest-fedora fedora40-vk-3 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3216 Also, errors.yoctoproject.org has 3 other occurrences: https://errors.yoctoproject.org/Errors/Search/?query=The+SRCREV_FORMAT+variable+must+be+set+when+multiple+SCMs+are+used
Just to triage on swatbot and use formalism detected by Ross tool: oe-selftest-fedora fedora40-vk-3 whinlatter&stable/whinlatter-nut&2.16 completed at 2026-03-04 14:11:38+00:00 https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3216/steps/15/logs/stdio
We could mirror the repository used to run the test in addition to reporting the problem to whoever runs sourceware. A mirror is a bit heavy for a problem that happens around once a year but intermittent failures are annoying.
Bulk move of unassigned 6.0-M* bugs to 6.1-M2.
A quick comment: After doing some checkup `;type=git-dependency` is not something a network failure can produce — it is written by devtool at: `scripts/lib/devtool/standard.py:929`, which appends it to secondary non-local sources via a paired `SRC_URI:remove / SRC_URI:append` in the workspace bbappend. For bzip2 that is the bzip2-tests git URL, since SRC_URI begins with the tarball and standard.py:920 skips entry 0. This matches `test_devtool_modify_multiple_sources` (`meta/lib/oeqa/selftest/cases/devtool.py:1217`), which runs devtool modify `bzip2`. I don't think the duplicate is in `SRC_URI`, though. `_get_srcrev()` (`bitbake/lib/bb/fetch2/__init__.py:819-822`) builds its SCM list by iterating fetcher.ud rather than fetcher.urls. ud comes from the module-global urldata_cache, keyed on `mc + FILE + id(d) (fetch2/__init__.py:1842-1845`) and merged into rather than replaced, with no invalidation when SRC_URI changes. externalsrc.bbclass — always inherited under devtool modify — does exactly that: get_hashvalue(d) at line 80 caches the full URL set, then line 89 does d.setVar('SRC_URI', ...) with only the local subset, on the same datastore. A later `_get_srcrev()` then sees both the pre-bbappend URL and the `;type=git-dependency` one, and reports two SCMs for a recipe that has one. Note externalsrc itself iterates fetch.urls at line 83, while `_get_srcrev` iterates ud. That would explain the intermittency without invoking the network: it depends on parse ordering and on whether a prior Fetch on the same cache key survives in the process, which varies with the long-lived bitbake server that oe-selftest uses. Similar to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=16382