15848 2025-05-05 08:41:14 +0000 AB-INT: SRCREV_FORMAT variable must be set on bzip2 2026-08-05 16:52:09 +0000 1 1 7 Build System, Metadata & Runtime OE-Core oe-core other 5.99 x86 Multiple NEW AB-INT Medium+ normal 6.1 M2 1 mathieu.dubois-briand unassigned mingli.yu pacopedraza87 randy.macleod yoann.congal --- --- No (bug/feature does not impact docs) oldest_to_newest 101872 0 mathieu.dubois-briand 2025-05-05 08:41:14 +0000 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. 101877 1 mathieu.dubois-briand 2025-05-05 08:52:53 +0000 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 101906 2 randy.macleod 2025-05-08 14:36:55 +0000 RP suspects that this is a network glitch. It has been seen before. 102349 3 randy.macleod 2025-06-26 14:53:10 +0000 Likely a network glitch, perhaps due to the high load due to AI site scrapping. Re-open if it happens again. 104493 4 yoann.congal 2026-03-04 17:39:47 +0000 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 104507 5 mathieu.dubois-briand 2026-03-05 12:43:32 +0000 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 104528 6 randy.macleod 2026-03-05 15:55:34 +0000 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. 105630 7 randy.macleod 2026-05-28 13:17:56 +0000 Bulk move of unassigned 6.0-M* bugs to 6.1-M2. 106435 8 pacopedraza87 2026-08-05 16:52:09 +0000 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