AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

android build: cache p4a recipe downloads even for FRESH_CLONE builds

Public commit record

What the developer wrote

Authored by SomberNight

81/100 · Strong
android build: cache p4a recipe downloads even for FRESH_CLONE builds

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
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change is a build-system optimization for Electrum's Android release builds. It caches large Qt source downloads between builds so they are not repeatedly downloaded from the internet. There is no security vulnerability here.

Recommended action

No security action needed. This is a benign build optimization.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.