I do not use docker, but in this post we see a very experienced builder comment that this mechanism is broken for community users Can't find extract-files.sh/can't run it while following "How to Build the /e/ ROM?" page - #9 by petefoth, suggesting (effectively) that one should include
the flag INCLUDE_PROPRIETARY=true
as also Can't build for Oneplus Nord (avicii) - #3 by petefoth
The variable would be defined as
-e "INCLUDE_PROPRIETARY=true"
… and of course can do no harm.
That’s a very old (experienced? 
) post. Docker works fine for building /e/OS - it’s how I do all my /e/OS builds now. The problem is that that the officially documented way of using it (specifically, the ‘Extract proprietary blobs’ section ) does not work. Luckily that step is not needed for devices - including FP4 - officially supported by LineageOS
Then the blobs for officially supported devices are available in the TheMuppets github repos (for FP4 in this repo) and Docker will pick them up from there because the INCLUDE_PROPRIETARY flag is set to true by default in the DockerFile.
Good to sort that out ! 
Lets’ include the bit from the DockerFile https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/blob/master/Dockerfile.community for good measure
#Include proprietary files, downloaded automatically from github.com/TheMuppets/ and gitlab.com/the-muppets/
#Only some branches are supported
ENV INCLUDE_PROPRIETARY true
Good luck getting changes made / errors fixed in the /e/ documentation! Been there, done that, got the tee-shirt, but gave up eventually in frustration 
Not having much luck with the Docker container. My command is:
$ sudo docker run -v "/data/e/src:/srv/src" -v "/data/e/zips:/srv/zips" -v "/data/e/logs:/srv/logs" -v "/data/e/ccache:/srv/ccache" -e "BRANCH_NAME=v1.12.3-s" -e "DEVICE_LIST=FP4" -e "CCACHE_SIZE=250G" -e "REPO=https://gitlab.e.foundation/e/os/releases.git" registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community
Tried a bunch of different tags. Every time it fails with:
[Fri Jul 21 16:04:52 UTC 2023] Missing "vendor/lineage", aborting
The log file meanwhile contains entries like:
fatal: cannot obtain manifest https://gitlab.e.foundation/e/os/releases.git
manifests:
fatal: couldn't find remote ref refs/heads/v1.12.3-s
But if I go to that git URI and look at the tags I see the one I specified:
that error message of yours comes up any time a repo sync fails, so it could be many things - 'Missing "vendor/lineage", aborting' - docker build error explained
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’d go with the branch, not a tag - “v1-s”
That works and on the face of it makes more sense, as I think it’s repo init failing and BRANCH_NAME being passed as the -b argument; there is no v1.12.3-s branch. Which then begs the questions:
v1-s branch I simply get a bleeding edge build based on the latest development commit.there’s a little typo bug in the build script that matches for tags, will get right onto it. If it would have matched, the revision checkout would be prefixed with “refs/tags/<yourtag>” and the repo init would have worked. It just needs a ref.
For android building, I think of tags as a newspaper from yesterday. Why use it if the branch already moved on? prefer branch.
The script is a great simplifier for newcomers and I think it is an asset and a good intro - but as a regular user, I’m just not a fan.
MR: https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/merge_requests/73
Hello Houston I think that there is another documentation issue !
In https://doc.e.foundation/support-topics/build-e#how-to-build-the-rom I see
List of tags to use for
BRANCH_NAMEis available at https://gitlab.e.foundation/e/os/releases/-/tags.
Tip: We now use git tags in addition to a specific manifest for each release. It let us to know exactly what’s inside each build.
If you want to build a test version, you can use:
BRANCH_NAMEset to v1-nougat, v1-oreo , v1-pie or v1-q to get the last test buildBRANCH_NAMEset to v1-nougat, v1-oreo , v1-pie or v1-q &REPO=https://gitlab.e.foundation/e/os/android.git
Has this not been edited to conceal the correct use of refs/tags/ ?
This page https://gitlab.e.foundation/steadfasterX/android_vendor_e
will give insight to the way to build a specific release.
Not today ! It looks like it is https://gitlab.e.foundation/e/os/releases/-/tags/v1.13-beta-s which has v1-s, a month old version of 1.13-beta while there is a day old release candidate 4 v1.13-rc.4-s. Looks like last month’s magazine
I’m assuming that in using the v1-s branch I get the bleeding edge, complete with the latest development commits, whereas tags give me stable, tested releases, the same as would be pushed out via OTA update.
If I wanted to do my own build to try something out or just because, I’d more than likely to build on stable foundations and not a build which may periodically be broken.
tags on the release manifest repo do not hold as much meaning in /e/ as they’d do for an individual code project - the upstream manifest revisions for most of the aosp and lineage repos do not change with every minor revision (still dozens, but no turmoil) - so what you get is mainly updated package forks from the main git-lfs prebuilt repo with what you’d see in lineage weeklies anyway
Still feels non-deterministic; might run build one day and it succeeds, while another day it fails. At the very least I’m going to get different versions of dependencies and building external stuff on top of a moving target branch, rather than a point-in-time tag, just feels error prone and plain wrong.
Building v1-s for FP4 target has failed. Will start a new thread with some details.
The Docker image can work it all out: it sees that the BRANCH_NAME is a tag, so it automatically adds the refs/tags/ prefix - see
https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/blob/master/src/build.sh#L94-99
So when I use the followiing docker run command:
docker run \
-v "/srv/src:/srv/src" \
-v "/srv/zips:/srv/zips" \
-v "/srv/logs:/srv/logs" \
-v "/srv/cache:/srv/ccache" \
-v "/srv/keys:/srv/keys" \
-v "/srv/local_manifests:/srv/local_manifests" \
-v "/srv/userscripts:/srv/userscripts" \
-e "SIGN_BUILDS=true" \
-e "INCLUDE_PROPRIETARY=false" \
-e "RELEASE_TYPE=CUSTOM" \
-e "CLEAN_AFTER_BUILD=true" \
-e "BRANCH_NAME=v1.12.3-r" \
-e "DEVICE_LIST=z3tc,z3tcw" \
-e "REPO=https://gitlab.e.foundation/e/os/releases.git" \
registry.gitlab.e.foundation:5000/e/os/docker-lineage-cicd:community
I see the following line in the log file
>> [Wed Jul 5 14:26:13 UTC 2023] Branch name v1.12.3-r is a tag on e/os/releases, prefix with refs/tags/ for 'repo init'
pete, as written, there’s a bug in the lines you quote currently. Run that curl without grep -q and you’ll see. Maybe this works for you because you didn’t pull the image from the registry since that part of the code was merged. See the MR, it’s just a url param error
that said: putting dynamic elements into scripts is… on top of bash, you get no stacktraces, no failure attribution, just the next echo that happens to come up
I am looking at the master branch, and according to git blame those lines were added between 3yrs ago and 5 months ago. The curl ... line was added buy you.
The docker run command I quoted was run on 5th July this year on a ‘clean’ cloud server. My log file shows that the lastest image (on that date) was downloaded. I have been using tags to build /e/OS with docker for quite a long time now: it has always worked for me
nah, not in that form - git commits are just text when unsigned. I authored the commit that brought up the discussion, it wasn’t merged as authored, see MR for the real links.
I’m not sure what I’m discussing: as said I welcome the script, but anybody using either the lineage4microg or the /e/ fork version (that introduced more dynamic elements / regexes for subtle failure) will have difficulties when things break because bash is just not good at bubbling up errors
Me neither
All I know is that the latest docker-lineage-cicd:community image works for me if I use tags, and -e "REPO=https://gitlab.e.foundation/e/os/releases.git" . I can see that using a branch name on https://gitlab.e.foundation/e/os/releases.git, or using a tag on https://gitlab.e.foundation/e/os/android.git might fail, possibly because of the typo in the curl command.
in its current defective form (we’re discussing one symbol really) the repo init + sync will not fail if the tag name also exists as branch reference, then the logic doesn’t matter because there is fallback.
But if both references exist, a tag will always take precedence. As originally intended, but it’s subtle, users might not be aware of it because of the variable name (BRANCH_NAME) - and that is why I don’t like it - but tried to fix 2 times anyway, because a all-in-one-build-command is a good entry level asset.
A sensible course forward would be to use separate arg flags and variable names to differentiate tags from branches.
This topic was automatically closed after 90 days. New replies are no longer allowed.