15197 2023-08-18 09:06:00 +0000 bitbake does not recognize that git-lfs is not installed when usehead=1 is used 2026-10-01 15:48:11 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple ACCEPTED Medium normal 6.2 1 tom.georgi richard.purdie ccasciato konrad.scherer poky.bs.watcher poky.watcher randy.macleod sivakumar.bs tom.georgi --- --- No (bug/feature does not impact docs) oldest_to_newest 96280 0 tom.georgi 2023-08-18 09:06:00 +0000 git-lfs was not installed. The error should have been caught by poky and throw an error message accordingly. The method contains_lfs() under the file bitbake/lib/bb/fetch2/git.py sets the variable refname to the respective specified branch. Since in our case no branch name but usehead=1 is specified, this is empty for us, whereby the subsequent command does not find any git-lfs files. Bitbake has an instance variable `revision` in this class, which resolves all names as revisions. When specifying usehead=1, HEAD will be resolved as a revision as well. Instead of using `ud.branches` as refname, `ud.revisions` could be used in this method to solve the bug. Since in our case the lfs files are local and not downloaded through the network, they can also be fetched in a later step. However, if the data was downloaded through the network, then this would lead to an error. For this reason, we have come to the assumption that this is a bug in BitBake. 96301 1 randy.macleod 2023-08-24 15:05:00 +0000 Tom, Can you submit a patch? 96591 2 randy.macleod 2023-09-28 15:04:16 +0000 Richard will try to make time for this bug in 5.0. 105981 3 sivakumar.bs 2026-06-22 14:21:31 +0000 This looks fixed on current master, as a side effect of: commit 2515fbd10824005fa7f34e87706000c079920366 "fetch: Drop multiple branch/revision support for single git urls" Richard Purdie, 2025-03-18 That commit collapsed ud.branches/ud.revisions (dicts) down to singular ud.branch/ud.revision. As part of it, _contains_lfs()'s refname is now derived from ud.revision instead of ud.branches[name]: cmd = ud.basecmd + ['grep', '^[^#].*lfs', ud.revision + ':.gitattributes'] ud.revision is always a resolved SHA, including when usehead=1 is set (HEAD resolves to a real revision during urldata_init), so the original problem - empty branch under usehead=1 causing the LFS check to silently no-op - no longer applies. Confirmed by replaying the old refname = ud.branches[ud.names[0]] logic against a local repo with LFS-marked .gitattributes: it fails with "fatal: ambiguous argument ':.gitattributes'", swallowed by the existing except (FetchError, ValueError): pass, so _contains_lfs() returns False. The current ud.revision-based version returns True against the same repo.