Note that 0f541be6f1 added a warning log if asserts are disabled.
It is intentional that these two things are in separate files:
We always want to log that warning, even if someone is using electrum as a library.
However, in that latter case, I think it's fine not to sys.exit(), but leave the decision up to the library user.
Similar thinking when running from source: let's log the warning but don't sys.exit().
reproducibility probably needs a hardcoded userid
Also, move the UID arg later in the dockerfiles, for better caching.
(if local dev build and repro build set different UIDs, the build caches
will diverge at that step)
The google play store will require 31, starting 2022-11 (next month).
A few commits are cherry-picked onto our forks of p4a and buildozer
from upstream, but the forks are not rebased.
Note that the compileSdkVersion is kept at 30,
only the targetSdkVersion is bumped 30->31.
closes https://github.com/spesmilo/electrum/pull/8010
I am trying to upstream some relevant p4a and buildozer changes
in e.g. https://github.com/kivy/python-for-android/pull/2686
The current system python in the docker baseimage is py3.9, while the
targetpython and hostpython built by p4a are py3.8, and this was causing
linker issues in the pyqt5 build.
It is also cleaner IMHO to have p4a handle what is needed for a recipe
instead of assuming it is available in the system. (and I think this is
how other existing recipes work)
fixes https://github.com/spesmilo/electrum/issues/8016
This is the new minimum the google play store requires.
note: the newer android command-line tools use a tiny bit different paths,
hence the `mv "${ANDROID_SDK_HOME}/cmdline-tools" "${ANDROID_SDK_HOME}/tools"` rename
see https://github.com/kivy/python-for-android/issues/2540
This includes two logically separate changes:
- on the host, try not to require sudo when running the build scripts
- namely when interacting with the docker daemon, this requires
the unix user on the host to be part of the `docker` group
- this solves part of https://github.com/spesmilo/electrum/issues/7602
- while running inside the docker containers, do not run as root
- this means that e.g. files created in mounted folders should
no longer be owned by root on the host
- there is some code duplication involved here - not sure
how it could be deduped.
maybe fixes https://github.com/spesmilo/electrum/issues/7640
Looks like by default pip is ignoring the locally available setuptools and wheel,
and downloading the latest ones from the internet at build time...
https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/?highlight=no-build-isolation#disabling-build-isolationhttps://stackoverflow.com/a/62889268
> When making build requirements available, pip does so in an isolated environment. That is, pip does not install those requirements into the user’s site-packages, but rather installs them in a temporary directory which it adds to the user’s sys.path for the duration of the build. This ensures that build requirements are handled independently of the user’s runtime environment. For example, a project that needs a recent version of setuptools to build can still be installed, even if the user has an older version installed (and without silently replacing that version).
>
> In certain cases, projects (or redistributors) may have workflows that explicitly manage the build environment. For such workflows, build isolation can be problematic. If this is the case, pip provides a --no-build-isolation flag to disable build isolation. Users supplying this flag are responsible for ensuring the build environment is managed appropriately (including ensuring that all required build dependencies are installed).
If only it were that easy!
If we add the "--no-build-isolation" flag, it becomes our responsibility to install *all* build time deps,
hence we now have "requirements-build-makepackages.txt".
Rebased our branches on latest p4a develop HEAD and buildozer master HEAD.
Re `android.allow_backup = False` in buildozer.spec, now that this setting
has been exposed to buildozer.spec (see https://github.com/kivy/buildozer/pull/1206),
we could finally drop a commit from our branch that did the same:
7a7d415d90
Re commenting out `android.arch` in buildozer.spec, we are setting this
via the ENV VAR in make_apk.
follow-up: 59e9337be0
For some reason, without this change, the first build works but subsequent builds fail.
Not sure what the cause is. This is why Travis builds work.
If there is a collision between a branch name and a commit hash, git
will choose the branch, even if the full 40-hex-long commit hash is
given. GitHub disallows branches/tags with such a name but git itself
does not. By adding the `^{commit}` syntax sugar after a ref name,
we can tell git that we want the commit hash to be preferred,
and hence we don't need to trust GitHub (only git).
see https://security.stackexchange.com/questions/225411/
