I thought to give this it’s own thread for any user searching for the error message. There are 10 search hits on the error message, but usually older (2019-2021) threads.
Before /e/ introduced a bit of tag-detection in the docker build-community.sh script, that error turned up more often. However if you’re still running into it, it’s most likely
an issue within one of the two repo stages init or sync - the repo log will give hints and after correcting a retry most often is successful
some repos in a device specific xml (“roomservice.xml”) that can’t be fulfilled - so it errors out, but script comes to a standstil later.
Any errors at those stages will run into “Missing "vendor/lineage", aborting”, as a failed workingdir checkout then is noticed, as it never occurred.
Reasons to fail can be missing referenced git repositories in the manifest xml files - especially on community builds where git repos can vanish, or unavailable default branches in the repos of the manifest xml. This can be fixed by looking for alternative repos or determining a suitable branch and changing manifest xml.
I got opinionated on the usage of the script - it is very procedural and makes some assumptions. For building with the main branches it should work though and the docker distribution of the script is a great simplifier.
Upstream at lineage4microg (the origin of the script) multibranch and local mirror support was introduced a few years ago. Most users probably don’t make use of this pattern though and it introduces some complexity to the script that could be avoided. Mirror usage can save lots of disk space, depending on for how many branches and devices one is building, git behavior can also be massaged to create really thin clones, either from a mirror or if a user knows to “build just once”.
I’m unaware of better alternatives, but keep looking. Upstream the script is improving regularly, it’s worth watching and remerging into /e/ community script.
Skipping the script and directly using the lineage envsetup.sh offers a bit more ergonomy at the expense of needing to grok repo, the mealtime commands (breakfast, lunch and brunch) and depending on rebuilding the aosp Makefile (m, mm, mmm targets etc) - so the script clearly wins on ease of use if no hiccup occurs.
on the usage of the script - it is very procedural and makes some assumptions. For building with the main branches it should work though and the docker distribution of the script is a great simplifier.