What are the q/r/s/t tag suffixes? And building for FP4

[9600]

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

[irrlicht]

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”???)

[9600]

Thanks for clarifying.

@irrlicht

s means Android 12, so r is Android 11, t is 13.

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.

[irrlicht]

@9600

So is this an Android or /e/ specific convention?

No. The letter is just the first letter of the “internal code names” given in the past.

@9600

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.

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.

[ronnz98]

See here:
https://en.wikipedia.org/wiki/Android_version_history

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…

[piero]

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
U
V
W
X
Y
Z

How will gogol do in 2029 ?

[Vaughan]

@irrlicht

Still more idiotic and more superfluous are the names, what is “Nougat”???

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.

[aibd]

@9600

It is also noted that with some devices you may need to first extract proprietary blobs

Are you planning to use docker ?

• https://gitlab.e.foundation/e/os/docker-lineage-cicd/-/blob/master/README.md

Proprietary files
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

• e/OS + Android OS version names and numbers? - #3 by aibd

[9600]

@aibd

Are you planning to use docker ?

Yes.

@aibd

… “is enabled by default” – so no blobs to extract.

I see, thanks. The main documentation could do to be clearer:

https://doc.e.foundation/support-topics/build-e#how-to-build-the-rom

I was just following the above and hadn’t though to also look at README in a repo.

[aibd]

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.

[petefoth]

@aibd

a very experienced builder comment that this mechanism is broken for community user

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.

[aibd]

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

[petefoth]

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

[aibd]

@9600, there is a useful build guide here

• https://git.coop/phone-custom-roms/backlog/-/wikis/Building-`e`-ROMs

[9600]

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:

https://gitlab.e.foundation/e/os/releases/-/tags/v1.12.3-s

[tcecyk]

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”

[9600]

@tcecyk

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.

[tcecyk]

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

[aibd]

@9600

How do I now build a specific release?

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 & 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.

@9600

by specifying the v1-s branch I simply get a bleeding edge build based on the latest development commit.

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

[9600]

@tcecyk

For android building, I think of tags as a newspaper from yesterday. Why use it if the branch already moved on? prefer branch.

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.