Closed Exodusnick closed 1 year ago
@bananer do you already have info
I did not attempt to build LineageOS 20 yet and I don't have access to non-publich information regarding it.
@bananer Can you add lineageos 20? https://github.com/lineageos4microg/docker-lineage-cicd/blob/master/src/build.sh#L133
@bananer https://github.com/lineageos4microg/docker-lineage-cicd/blob/lineage-20/src/build.sh
Building for lineage-20 Starting ninja... FAILED: ninja: 'user-keys/sdk_sandbox.x509.pem', needed by 'out/soong/.intermediates/packages/modules/AdServices/sdksandbox/SdkSandbox/SdkSandbox/android_common_apex33/SdkSandbox.apk', missing and no known rule to make it 13:56:14 ninja failed with: exit status 1
@bananer lineage-20.0-20221011-microG-signed-herolte.log built with -e "SIGNATURE_SPOOFING=restricted" \
@bananer The build with signature spoofing no does not work. No permission to enable the microG settings.
Somewhere in the pachter is an error
My colleague has the same problem as me Something is wrong with the signature spoofing lease.
Starting ninja... FAILED: ninja: 'user-keys/sdk_sandbox.x509.pem', needed by 'out/soong/.intermediates/packages/modules/AdServices/sdksandbox/SdkSandbox/SdkSandbox/android_common_apex33/SdkSandbox.apk', missing and no known rule to make it 13:56:14 ninja failed with: exit status 1
Android 13 apparently needs more keys than previous versions
The fix for this is to change lines 40 & 45 in init.sh
to
for c in releasekey platform shared media networkstack verity sdk_sandbox bluetooth; do
Starting ninja... FAILED: ninja: 'user-keys/sdk_sandbox.x509.pem', needed by 'out/soong/.intermediates/packages/modules/AdServices/sdksandbox/SdkSandbox/SdkSandbox/android_common_apex33/SdkSandbox.apk', missing and no known rule to make it 13:56:14 ninja failed with: exit status 1
Android 13 apparently needs more keys than previous versions The fix for this is to change lines 40 & 45 in
init.sh
tofor c in releasekey platform shared media networkstack verity sdk_sandbox bluetooth; do
Is no longer relevant Lineageos 20 microg building works for me .
Is no longer relevant Lineageos 20 microg building works for me .
With docker? Using the lineageos4microg/docker-lineage-cicd:lineage-20
image?
If not with docker, how do you build?
Thanks
example
docker run \ -e "CCACHE_SIZE=100G" \ -e "BRANCH_NAME=lineage-20.0" \ -e "DEVICE_LIST=hero2lte" \ -e "RELEASE_TYPE=microG-214816048" \ -e "SIGN_BUILDS=true" \ -e "SIGNATURE_SPOOFING=restricted" \ -e "INCLUDE_PROPRIETARY=false" \ -e "MANIFESTS_8890=true" \ -v "...:/srv/src" \ -v "...:/srv/zips" \ -v "...:/srv/logs" \ -v "...:/srv/ccache" \ -v ".../LINEAGE_20_0/keys/lineage:/srv/keys" \
lineageos4microg/docker-lineage-cicd:lineage-20
Thank you.
(Sorry for the noob questions, but I am just learning about using different Docker images)
> On 21 October 2022 10:38:53 BST, Christian Canale ***@***.***> wrote:
>>[petefoth](https://github.com/petefoth)
>>
>>example
>>
> <snip>
> -e "MANIFESTS_8890=true" \
> <snip>
>>danielk43/docker-lineage-cicd:lineage-20.0-8890
>>
>>--
This is just an example I use a custom docker.sh Is only relevant for me.
No only works for Samsung Galaxy S7
@petefoth
docker run -e "CCACHE_SIZE=100G" -e "BRANCH_NAME=lineage-20.0" -e "DEVICE_LIST=your device" -e "RELEASE_TYPE=microG" -e "SIGN_BUILDS=true" -e "SIGNATURE_SPOOFING=restricted" -e "INCLUDE_PROPRIETARY=false" -v "...:/srv/src" -v "...:/srv/zips" -v "...:/srv/logs" -v "...:/srv/ccache" -v ".../LINEAGE_20_0/keys/lineage:/srv/keys" \ lineageos4microg/docker-lineage-cicd:lineage-20
See here for example https://github.com/lineageos4microg/docker-lineage-cicd
Thanks. I have managed to run the lineageos4microg/docker-lineage-cicd:lineage-20
image
I am seeing the same errors as reported by @Exodusnick
@bananer lineage-20.0-20221011-microG-signed-herolte.log built with -e "SIGNATURE_SPOOFING=restricted" \
The error is
frameworks/base/services/core/java/com/android/server/pm/ComputerEngine.java:1595: error: cannot find symbol
Bundle metaData = p.getMetaData();
^
symbol: class Bundle
location: class ComputerEngine
frameworks/base/services/core/java/com/android/server/pm/ComputerEngine.java:1651: error: cannot find symbol
mPermissionManager.getGrantedPermissions(ps.name, userId)
^
symbol: variable name
location: variable ps of type PackageStateInternal
2 errors
These lines of code are inserted by the android_frameworks_base-Android13.patch
file
Should I create a new issue which only refers to this problem, rather than lineage-20.0 in general?
These lines of code are inserted by the
android_frameworks_base-Android13.patch
file ... Should I create a new issue which only refers to this problem, rather than lineage-20.0 in general?
I have created #353 to track this problem
is booting
@Exodusnick
@petefoth
docker run -e "CCACHE_SIZE=100G" -e "BRANCH_NAME=lineage-20.0" -e "DEVICE_LIST=your device" -e "RELEASE_TYPE=microG" -e "SIGN_BUILDS=true" -e "SIGNATURE_SPOOFING=restricted" -e "INCLUDE_PROPRIETARY=false" -v "...:/srv/src" -v "...:/srv/zips" -v "...:/srv/logs" -v "...:/srv/ccache" -v ".../LINEAGE_20_0/keys/lineage:/srv/keys" lineageos4microg/docker-lineage-cicd:lineage-20
That build command does not include the line
-e "WITH_GMS=true" \
Is that no longer needed? All the examples in the README include it.
see here https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20
To include microG (or possibly the actual Google Mobile Services) in your build, LineageOS expects certain Makefiles in vendor/partner_gms and variable WITH_GMS set to true.
-e "WITH_GMS=true"
docker run \ -e "CCACHE_SIZE=100G" \ -e "BRANCH_NAME=lineage-20.0" \ -e "DEVICE_LIST=hero2lte" \ -e "RELEASE_TYPE=microG-signed" \ -e "SIGN_BUILDS=true" \ -e "WITH_SU=false" \ -e "SIGNATURE_SPOOFING=restricted" \ -e "INCLUDE_PROPRIETARY=false" \ -e "WITH_GMS=true" \ -e "CUSTOM_PACKAGES=GmsCore GsfProxy FakeStore NominatimGeocoderBackend IchnaeaNlpBackend FDroidPrivilegedExtension FDroid" \ -v "/home/...../Lineageos/20.0_microG/lineage:/srv/src" \ -v "/home/...../Lineageos/20.0_microG/zips:/srv/zips" \ -v "/home/...../Lineageos/20.0_microG/logs:/srv/logs" \ -v "/home/...../Lineageos/20.0_microG/cache:/srv/ccache" \ -v "/home/...../Lineageos/20.0_microG/keys:/srv/keys" \ -v "/home/...../Lineageos/20.0_microG/manifests:/srv/local_manifests" \
Thank you very much for continuing to try and help sort this out :)
see here https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20
To include microG (or possibly the actual Google Mobile Services) in your build, LineageOS expects certain Makefiles in vendor/partner_gms and variable WITH_GMS set to true.
-e "WITH_GMS=true"
Yes - I have been including that in my build commands: I was querying it, because the build command you included in your earlier comment did not include that line.
-e "CUSTOM_PACKAGES=GmsCore GsfProxy FakeStore NominatimGeocoderBackend IchnaeaNlpBackend FDroidPrivilegedExtension FDroid"
As far as I know, this line is no longer needed, since this commit in December 2021) when the required local manifest entry changed from
<project name="lineageos4microg/android_prebuilts_prebuiltapks" path="prebuilts/prebuiltapks" remote="github" revision="master" />
to
<project name="lineageos4microg/android_prebuilts_prebuiltapks" path="prebuilts/prebuiltapks" remote="github" revision="master" />
I have successfully been making 18.1
and 19.1
builds without including that line.
But none of this explains why your builds succeed, while mine fail because the code added to frameworks/base/services/core/java/com/android/server/pm/ComputerEngine.java
(by the patch in android_frameworks_base-Android13.patch
) does not compile.
From what I understand
../ComputerEngine.java
will not compile So - sadly - I remain confused, and unable to build 20.0
:(
You have to read everything and not only what you want to read and I think you know better English than I do. Because my English is not good at all and I have to use a translation. I'm related to my last post .
You have to read everything and not only what you want to read and I think you know better English than I do.
???
I have been back and re-read every post in this issue and in #353, and all of the README.md
at https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20
I am building with
-e "BRANCH_NAME=lineage-20.0"
-e "WITH_GMS=true"
-e "SIGNATURE_SPOOFING=restricted"
-e "INCLUDE_PROPRIETARY=false"
I don't
WITH_SU=false
, because it is set to false
by default at line 76 in Dockerfile
CUSTOM_PACKAGES
list, because, according to README.md
it is not requiredI am using the lineageos4microg/docker-lineage-cicd:lineage-20
docker image
I have lineageos4microg/android_vendor_partner_gms
in my local manifest.
As far as I can tell, I am following the documentation at https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20 very closely. And still the code added in the patch file does not compile.
Please can you tell me what it is that you think I am not reading?
You have to read everything and not only what you want to read and I think you know better English than I do.
???
I have been back and re-read every post in this issue and in #353, and all of the README.md
at https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20
I am building with
-e "BRANCH_NAME=lineage-20.0"
-e "WITH_GMS=true"
-e "SIGNATURE_SPOOFING=restricted"
-e "INCLUDE_PROPRIETARY=false"
I don't
WITH_SU=false
, because it is set to false
by default at line 76 in Dockerfile
CUSTOM_PACKAGES
list, because, according to README.md
it is not requiredI am using the lineageos4microg/docker-lineage-cicd:lineage-20
docker image
I have lineageos4microg/android_vendor_partner_gms
in my local manifest.
As far as I can tell, I am following the documentation at https://github.com/lineageos4microg/docker-lineage-cicd/tree/lineage-20 very closely. And still the code added in the patch file does not compile.
Please can you tell me what it is that you think I am not reading?
With the Release of LineageOS 20 we probably can expect some new builds soonish? Or are there any remaining road blockers to debug or things to test?
Builds for 20 are scheduled to start with the next round on Jan 15th.
This also means we will no longer be building 18.1 and will have to remove those images sometime before we run out of space. If you want to keep your 18.1 device running, save the last official image now or try building it yourself.
@bananer
This also means we will no longer be building 18.1 and will have to remove those images sometime before we run out of space. If you want to keep your 18.1 device running, save the last official image now or try building it yourself.
What is missing in terms of resources to continue 18.1 and maybe restart 17.1 building? Or at least to keep already built ones on download server?
There is a bunch of devices in official lineageOS 18.1 with continued support due to kernel version prohibiting the upgrade.
What is missing in terms of resources to continue 18.1 and maybe restart 17.1 building? Or at least to keep already built ones on download server?
As I said, resources are limited.
We have one build server which manages to go through the roster of officially supported devices in 7-10 days. That means we can realistically run two rounds of builds per month.
For every device, we keep two builds from the latest version and one from the previous version around, which currently is almost 500GB.
On top of that there's the time it takes to manage and troubleshoot the builds, which is also very limited.
If you want to host the old builds, go ahead and rent some large enough webspace. I could even help you transfer the files server to server. We could later figure out how you could prove that the builds hosted by you are unmodified and legit.
There is a bunch of devices in official lineageOS 18.1 with continued support due to kernel version prohibiting the upgrade.
Yeah, seems like they are indeed continuing to build 18.1, which is different from how it went in the past. I just go by their buildserver configuration, but do you know of an official statemant about that?
Let's do a round of 19.1+20.0 this time and see how long it takes. If there is enough breathing room, I will enable 18.1 again for February.
We have one build server which manages to go through the roster of officially supported devices in 7-10 days. That means we can realistically run two rounds of builds per month.
Isn't one round enough to keep up with security patches?
If you want to host the old builds, go ahead and rent some large enough webspace. I could even help you transfer the files server to server. We could later figure out how you could prove that the builds hosted by you are unmodified and legit.
I will work into archive.org - A one-time backup looks like a good job. And they seem to be legit. https://web.archive.org/web/20230113194540/https://download.lineage.microg.org/
Yeah, seems like they are indeed continuing to build 18.1, which is different from how it went in the past. I just go by their buildserver configuration, but do you know of an official statemant about that?
LineageOS 18.1 builds were not deprecated this year "I am alive, but very badly burned"
Let's do a round of 19.1+20.0 this time and see how long it takes. If there is enough breathing room, I will enable 18.1 again for February.
Thank You
If you want to host the old builds, go ahead and rent some large enough webspace. I could even help you transfer the files server to server. We could later figure out how you could prove that the builds hosted by you are unmodified and legit.
@bananer Just as an idea:
Keep the SHA256 checksums and whathever is needed to verify the build integrity on your servers forever (shouldn't take too much space) or in an official GitHub repo and only remove the ZIP files with the old builds.
Those old builds can be grabbed from various other sources such as archive.org or maybe even in a decrentralized way (e.g. via torrents)?
Some builds finished successfully, however, rhere were also quite a few build failures so far...
akari:
[ 58% 401/684] including out/soong/Android-lineage_akari.mk ...
FAILED:
In file included from out/soong/installs-lineage_akari.mk:164748:
In file included from out/soong/Android-lineage_akari.mk:395531:
In file included from build/make/core/soong_cc_rust_prebuilt.mk:54:
build/make/core/base_rules.mk:338: error: device/sony/tama-common/libhidl: MODULE.TARGET.SHARED_LIBRARIES.android.hidl.base@1.0 already defined by hardware/lineage/compat.
20:32:13 ckati failed with: exit status 1
aura, axolot, beckham, berlin, beryllium, channel, cheeseburger, chef, chiron, dipper, dubai, dumpling, enchilada, equuleus, evert, fajita, FP4 all had an error like this:
FAILED: out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status
/bin/bash -c "(rm -f out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status ) && (build/soong/scripts/manifest_check.py --enforce-uses-libraries --enforce-uses-libraries-status out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status --aapt out/host/linux-x86/bin/aapt --uses-library com.android.location.provider --optional-uses-library androidx.window.extensions --optional-uses-library androidx.window.sidecar --dexpreopt-config out/target/product/aura/obj/JAVA_LIBRARIES/com.android.location.provider_intermediates/dexpreopt.config vendor/partner_gms/GmsCore/GmsCore.apk )"
error: mismatch in the <uses-library> tags between the build system and the manifest:
- required libraries in build system: [com.android.location.provider]
vs. in the manifest: [com.android.location.provider]
- optional libraries in build system: [androidx.window.extensions, androidx.window.sidecar]
vs. in the manifest: [org.apache.http.legacy, androidx.window.extensions, androidx.window.sidecar]
- tags in the manifest (vendor/partner_gms/GmsCore/GmsCore.apk):
uses-library-not-required:'org.apache.http.legacy' uses-library:'com.android.location.provider' uses-library-not-required:'androidx.window.extensions'
uses-library-not-required:'androidx.window.sidecar'
note: the following options are available:
- to temporarily disable the check on command line, rebuild with RELAX_USES_LIBRARY_CHECK=true (this will set compiler filter "verify" and disable AOT-compilation in dexpreopt)
- to temporarily disable the check for the whole product, set PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true in the product makefiles
- to fix the check, make build system properties coherent with the manifest
- for details, see build/make/Changes.md and https://source.android.com/devices/tech/dalvik/art-class-loader-context
might be fixable with https://github.com/lineageos4microg/android_vendor_partner_gms/pull/19
Is there any way to obtain an RSS or Atom feed of build successes and failures, as I'd like to add it to the bot that serves microG's Matrix/IRC chatroom (#microG:matrix.org or #microg on Libera)?
Seems like kebab has also failed as it went from heart
to kiev
Can confirm that using https://github.com/lineageos4microg/android_vendor_partner_gms/pull/19 fixes build for fajita.
Seems like kebab has also failed as it went from
heart
tokiev
Excuse my ignorance, but where do you people get these build logs? If there is a way to get them programmatically, I may not need an RSS or Atom feed as I asked above since I could probably just add some ad hoc functionality to the bot.
Seems like kebab has also failed as it went from
heart
tokiev
Excuse my ignorance, but where do you people get these build logs? If there is a way to get them programmatically, I may not need an RSS or Atom feed as I asked above since I could probably just add some ad hoc functionality to the bot.
It's not a build log. For now you would need to sort the download page by modification date and compare the entries with the alphabetical list of LOS20 Builds
I manually flashed lineage-20.0-20230119-microG-redfin.zip
on my device and it does not boot, instead kicking me back to my 19.1 install on the other slot. Thought I would raise this here in case anyone else is having this happen (or isn't).
I manually flashed
lineage-20.0-20230119-microG-redfin.zip
on my device and it does not boot, instead kicking me back to my 19.1 install on the other slot. Thought I would raise this here in case anyone else is having this happen (or isn't).
Worked fine with a clean install and another redfin device was able to "dirty" flash just fine, so not sure what was going on.
log is created automatically and can be found under my example 20.0_microG/logs/herolte
on docker.sh -v "/home/..../Lineageos/20.0_microG/logs:/srv/logs" \
to follow the log enter this
example .....:~/Lineageos/20.0_microG/logs/herolte$ tail -f /home/.../Lineageos/20.0_microG/logs/herolte/lineage-20.0-20230119-microG-signed-herolte.log
soory pressed incorrectly
Some builds finished successfully, however, rhere were also quite a few build failures so far...
akari:
[ 58% 401/684] including out/soong/Android-lineage_akari.mk ... FAILED: In file included from out/soong/installs-lineage_akari.mk:164748: In file included from out/soong/Android-lineage_akari.mk:395531: In file included from build/make/core/soong_cc_rust_prebuilt.mk:54: build/make/core/base_rules.mk:338: error: device/sony/tama-common/libhidl: MODULE.TARGET.SHARED_LIBRARIES.android.hidl.base@1.0 already defined by hardware/lineage/compat. 20:32:13 ckati failed with: exit status 1
aura, axolot, beckham, berlin, beryllium, channel, cheeseburger, chef, chiron, dipper, dubai, dumpling, enchilada, equuleus, evert, fajita, FP4 all had an error like this:
FAILED: out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status /bin/bash -c "(rm -f out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status ) && (build/soong/scripts/manifest_check.py --enforce-uses-libraries --enforce-uses-libraries-status out/target/common/obj/APPS/GmsCore_intermediates/enforce_uses_libraries.status --aapt out/host/linux-x86/bin/aapt --uses-library com.android.location.provider --optional-uses-library androidx.window.extensions --optional-uses-library androidx.window.sidecar --dexpreopt-config out/target/product/aura/obj/JAVA_LIBRARIES/com.android.location.provider_intermediates/dexpreopt.config vendor/partner_gms/GmsCore/GmsCore.apk )" error: mismatch in the <uses-library> tags between the build system and the manifest: - required libraries in build system: [com.android.location.provider] vs. in the manifest: [com.android.location.provider] - optional libraries in build system: [androidx.window.extensions, androidx.window.sidecar] vs. in the manifest: [org.apache.http.legacy, androidx.window.extensions, androidx.window.sidecar] - tags in the manifest (vendor/partner_gms/GmsCore/GmsCore.apk): uses-library-not-required:'org.apache.http.legacy' uses-library:'com.android.location.provider' uses-library-not-required:'androidx.window.extensions' uses-library-not-required:'androidx.window.sidecar' note: the following options are available: - to temporarily disable the check on command line, rebuild with RELAX_USES_LIBRARY_CHECK=true (this will set compiler filter "verify" and disable AOT-compilation in dexpreopt) - to temporarily disable the check for the whole product, set PRODUCT_BROKEN_VERIFY_USES_LIBRARIES := true in the product makefiles - to fix the check, make build system properties coherent with the manifest - for details, see build/make/Changes.md and https://source.android.com/devices/tech/dalvik/art-class-loader-context
might be fixable with lineageos4microg/android_vendor_partner_gms#19
get the same error in 19.1 and 20.0 the fix does not work for me in 20.0 for 19.1 yes https://github.com/lineageos4microg/android_vendor_partner_gms/pull/19/commits/6f5277dcc9b0f8f7830cea4697e57b57c07eee35
Strange that fajita failed @Exodusnick, a previous comment seemed to indicate that it worked for them with fajita. I have built umi 19.1 and 20.0 and have had no issues when pointing to my vendor gms fork. I wonder why it works on some devices and not others, the gms manifest should be the same for all builds, and have the same library requirements...
Strange that fajita failed @Exodusnick, a previous comment seemed to indicate that it worked for them with fajita. I have built umi 19.1 and 20.0 and have had no issues when pointing to my vendor gms fork. I wonder why it works on some devices and not others, the gms manifest should be the same for all builds, and have the same library requirements...
Not for fajita . For cheeseburger,dumpling ,herolte,hero2lte,bacon And still others had worked without problems last week . Something is broken that the error comes.
Is the Z01RD one of the devices affected by the issue discussed here? (zippo is after it in the list and already has a build available)
I merged the change in the partner_gms repo and started another round of 20.0 builds. Let's see if we get fewer failures now.
@bananer For my works building for cheeseburger and dompling Again 👍
aura, axolot, beckham, berlin and beryllium built successfully already. Looks good.
I just dirty flashed the new fajita build and it's working great. Nice work!
Linaeageos 20.0 is upcoming. https://www.lineageoslog.com/20.0
We might want to adopt the build script and patch to that :-)