android build: cache p4a recipe downloads even for FRESH_CLONE builds#10744
Open
SomberNight wants to merge 1 commit into
Open
android build: cache p4a recipe downloads even for FRESH_CLONE builds#10744SomberNight wants to merge 1 commit into
SomberNight wants to merge 1 commit into
Conversation
I propose we cache some downloads even for "fresh clone" builds (that have `ELECBUILD_COMMIT` env var set), with an opt-out reusing the existing `ELECBUILD_NOCACHE` env var. Currently `ELECBUILD_NOCACHE` only opts-out from the docker build cache, now I would reuse it for p4a recipe downloads. `qt-everywhere-src-6.10.2.tar.xz` [0] is 1.3 GiB, and we download it twice per arch. (once for the qt6 recipe, once for the hostqt6 recipe) It seems to me, download.qt.io is heavily rate-limiting downloads from some IPs. When doing a release, we build 3 archs, so we download Qt six times. With this patch, we would only download it twice. (note: I see no need to have separate caches per arch atm.) Also, when doing multiple builds to debug reproducibility, with this patch, only the first attempt needs to download Qt (twice). Subsequent attempts hit the cache. --- note: the git tag is part of the cache key out of cache-staleness paranoia. It is not the full commit though, as that would kill the reproducibility-debugging use case. [0]: https://github.com/spesmilo/python-for-android/blob/8c0fcc9ef2e559918ca96ecde6e09fe521bb1427/pythonforandroid/recipes/qt6/__init__.py#L11
SomberNight
commented
Jul 8, 2026
| DOCKER_RUN_FLAGS="$DOCKER_RUN_FLAGS -v $FRESH_CLONE_BASE/downloads_cache/$GIT_TAG/p4a_packages:/home/user/wspace/electrum/.buildozer/android/platform/build-armeabi-v7a/packages" | ||
| DOCKER_RUN_FLAGS="$DOCKER_RUN_FLAGS -v $FRESH_CLONE_BASE/downloads_cache/$GIT_TAG/p4a_packages:/home/user/wspace/electrum/.buildozer/android/platform/build-arm64-v8a/packages" | ||
| DOCKER_RUN_FLAGS="$DOCKER_RUN_FLAGS -v $FRESH_CLONE_BASE/downloads_cache/$GIT_TAG/p4a_packages:/home/user/wspace/electrum/.buildozer/android/platform/build-x86/packages" | ||
| DOCKER_RUN_FLAGS="$DOCKER_RUN_FLAGS -v $FRESH_CLONE_BASE/downloads_cache/$GIT_TAG/p4a_packages:/home/user/wspace/electrum/.buildozer/android/platform/build-x86_64/packages" |
Member
Author
There was a problem hiding this comment.
note: .buildozer/android/platform/build-$ARCH/packages is the folder p4a internally uses for caching downloads. This PR would just persist the cache through build attempts.
note2: p4a already puts a marker next to each download to detect staleness, with the version in the name. Though I remark it does not work for git clones (see plyer):
dir structure of packages folder
$ tree -L2 -a /var/tmp/electrum_build/android/downloads_cache/4.8.0/p4a_packages/
/var/tmp/electrum_build/android/downloads_cache/4.8.0/p4a_packages/
├── cffi
│ ├── .mark-v2.0.0.tar.gz
│ └── v2.0.0.tar.gz
├── hostpython3
│ ├── .mark-Python-3.11.15.tgz
│ └── Python-3.11.15.tgz
├── hostqt6
│ ├── .mark-qt-everywhere-src-6.10.2.tar.xz
│ └── qt-everywhere-src-6.10.2.tar.xz
├── libffi
│ ├── .mark-v3.4.8.tar.gz
│ └── v3.4.8.tar.gz
├── libiconv
│ ├── .mark-libiconv-1.18.tar.gz
│ └── libiconv-1.18.tar.gz
├── libsecp256k1
│ ├── .mark-1a53f4961f337b4d166c25fce72ef0dc88806618.zip
│ └── 1a53f4961f337b4d166c25fce72ef0dc88806618.zip
├── libzbar
│ ├── .mark-bb05ec54eec57f8397cb13fb9161372a281a1219.zip
│ └── bb05ec54eec57f8397cb13fb9161372a281a1219.zip
├── openssl
│ ├── .mark-openssl-3.0.21.tar.gz
│ └── openssl-3.0.21.tar.gz
├── packaging
│ ├── .mark-packaging-26.0.tar.gz
│ └── packaging-26.0.tar.gz
├── plyer
│ ├── .mark-plyer
│ └── plyer
├── pycparser
│ ├── .mark-pycparser-2.22.tar.gz
│ └── pycparser-2.22.tar.gz
├── pycryptodomex
│ ├── .mark-v3.23.0x.tar.gz
│ └── v3.23.0x.tar.gz
├── pyjnius
│ ├── .mark-1.7.0.zip
│ └── 1.7.0.zip
├── pyparsing
│ ├── .mark-pyparsing-3.0.7.tar.gz
│ └── pyparsing-3.0.7.tar.gz
├── pyqt6
│ ├── .mark-pyqt6-6.10.2.tar.gz
│ └── pyqt6-6.10.2.tar.gz
├── pyqt6sip
│ ├── .mark-pyqt6_sip-13.10.3.tar.gz
│ └── pyqt6_sip-13.10.3.tar.gz
├── pyqt_builder
│ ├── .mark-pyqt_builder-1.19.1.tar.gz
│ └── pyqt_builder-1.19.1.tar.gz
├── python3
│ ├── .mark-Python-3.11.15.tgz
│ └── Python-3.11.15.tgz
├── qt6
│ ├── .mark-qt-everywhere-src-6.10.2.tar.xz
│ └── qt-everywhere-src-6.10.2.tar.xz
├── sip
│ ├── .mark-sip-6.15.1.tar.gz
│ └── sip-6.15.1.tar.gz
├── six
│ ├── .mark-six-1.17.0.tar.gz
│ └── six-1.17.0.tar.gz
└── sqlite3
├── .mark-sqlite-amalgamation-3500000.zip
└── sqlite-amalgamation-3500000.zip
24 directories, 43 files
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I propose we cache some downloads even for "fresh clone" builds (that have
ELECBUILD_COMMITenv var set), with an opt-out reusing the existingELECBUILD_NOCACHEenv var. CurrentlyELECBUILD_NOCACHEonly opts-out from the docker build cache, now I would reuse it for p4a recipe downloads.qt-everywhere-src-6.10.2.tar.xzis 1.3 GiB, and we download it twice per arch. (once for the qt6 recipe, once for the hostqt6 recipe) It seems to me, download.qt.io is heavily rate-limiting downloads from some IPs.When doing a release, we build 3 archs, so we download Qt six times. With this patch, we would only download it twice.
(note: I see no need to have separate caches per arch atm.)
Also, when doing multiple builds to debug reproducibility, with this patch, only the first attempt needs to download Qt (twice). Subsequent attempts hit the cache.
note: the git tag is part of the cache key out of cache-staleness paranoia. It is not the full commit though, as that would kill the reproducibility-debugging use case.