| Summary: | AB-INT: SRCREV_FORMAT variable must be set on bzip2 | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mathieu Dubois-Briand <mathieu.dubois-briand> |
| Component: | oe-core other | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | mingli.yu, pacopedraza87, randy.macleod, yoann.congal |
| Version: | 5.99 | ||
| Target Milestone: | 6.1 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | AB-INT | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
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
|
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.