Looking at the tags available at the time of writing, it would appear as though the latest stable release is v1.12.3. However, I cannot seem to find details of the significance of the -q, -r, -s and -t suffixes, hence would appreciate it if someone could explain the difference.
It is also noted that with some devices you may need to first extract proprietary blobs, but from the documentation build and FP4 pages I cannot determine whether this would be the case for Fairphone 4.
Regain your privacy! Adopt /e/ the unGoogled mobile OS and online services
Android versions. /e/ sits on top of an underlying Android, so each /e/ release is compiled for a concrete Android version.
s means Android 12, so
r is Android 11,
t is 13.
I found these letters always idiotic. They are completely superfluous, confusing and especially limited to the alphabet. What is when
z is reached? (Still more idiotic and more superfluous are the names, what is “Nougat”???)
Thanks for clarifying.
So is this an Android or /e/ specific convention? Just curious.
This also raises a second question related to FP4 and whether Android 13 is stable or I might be better instead building an Android 12 release.
No. The letter is just the first letter of the “internal code names” given in the past.
As far as I know /e/ on 12 is stable. Probably the device will get an OTA update to Android 13 when /e/ on 13 will be stable.
until Android 9 Pie they used names from sweets. Starting from Android 10 this was not done any more (only unofficial)… So Android 10 is Q, A11 is R, A12 is S and A13 is T…
J was Jelly Bean (2012) A 4.2 / cm 10
K was Kitkat (2013) A 4.4 / cm 11
L was Lolypop (2014) A 5 / cm 12
M was Marchmalow (2015) A 6 / cm 13
N was for Nougat (2016) AOSP 7.1.2 / cm/LOS 14.1
O was for Oreo (2017) AOSP 8.1 / LOS 15.1
P was for Pie (2018) AOSP 9 / LOS 16
Q is for Quince Tart (2019) AOSP 10 / LOS 17
R is for Red Velvet Cake (2020) AOSP 11 / LOS 18
S is for Snow Cone (2021) AOSP 12 / LOS 19
T is for Tiramisu (2022) AOSP 13 / LOS 20
How will gogol do in 2029 ?
The whole dessert name, primary colour thing is about infantilising users so that they look the other way from the data hoovering and just watch in wonder at the chocolate factory’s latest creation. Even better than an everlasting gobstopper for capturing attention.
Are you planning to use docker ?
Some proprietary files are needed to create a LineageOS build, but they’re not included in the LineageOS repo for legal reasons.
The third way is the easiest one and is enabled by default; if you’re OK with that just move on, otherwise set
INCLUDE_PROPRIETARY (true) to
false and manually provide the blobs (not explained in this guide).
… “is enabled by default” – so no blobs to extract.
Alternatively if you are using a manual method it is good to know that proprietary_vendor_fairphone_FP4 exists
I see, thanks. The main documentation could do to be clearer:
I was just following the above and hadn’t though to also look at README in a repo.
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
… 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
@9600, there is a useful build guide here
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
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:
- Why does the e documentation say to use a tag name, where the environment variable is for a branch and the container README says to use a branch name also?
- How do I now build a specific release? Presumably by specifying the
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.
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_NAME is 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_NAME set to v1-nougat, v1-oreo , v1-pie or v1-q to get the last test build
BRANCH_NAME set to v1-nougat, v1-oreo , v1-pie or v1-q &
Has this not been edited to conceal the correct use of
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.