- wallet.get_receiving_addresses is guaranteed to exist (maybe it was only for HD wallets in the past)
- wallet.is_mine is stricter than wallet.adb.is_mine, usually we want the former
Previously it was only the actual commands that directly or indirectly verified
the password. This adds a check that runs for any command requiring a password.
related https://github.com/spesmilo/electrum/pull/9238
This is most useful if the user wants to import a significant number of keys,
as every invocation of `importprivkey` results in rewriting the wallet file to disk.
The API of "importprivkey" is left unchanged for the single privkey case.
setup exe used to install Electrum to `C:\Program Files (x86)\Electrum`,
but now as the binaries are amd64, we should install to `C:\Program Files\Electrum`.
With this change, based on my experiments, looks like if there is an existing install,
nsis will keep using that path, but if it's a fresh install, it will now use the 64-bit path.
follow-up fcc4e1d387
follow-up fcc4e1d387
error msg was:
```
SHA for cache folders (/opt/wine64/drive_c/electrum/contrib/build-wine/.cache/win32/wine_pip_cache, /opt/wine64/drive_c/electrum/contrib/build-wine/.cache/win64/wine_pip_cache) is 'be33ad1b0598b1733992e36659bb71406f8fcfaa3a442166ecbe26e2db9a65c2'
Failed to tar caches for Upload 'pip' cache with error walking folder /opt/wine64/drive_c/electrum/contrib/build-wine/.cache/win32/wine_pip_cache: lstat /opt/wine64/drive_c/electrum/contrib/build-wine/.cache/win32/wine_pip_cache: no such file or directory!
```
- fdroid maintainers asked that releases use fixed forks of p4a and buildozer,
so now we use the newly created forks in the spesmilo org. I plan to keep using
my existing contributor-specific repos for development, but whatever we push
to electrum master, should use the new spesmilo/ forks.
see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15858#note_2136345746
- Also, I added branch protection rules for branches named "electrum_*", so if
we name the branches that are actually used in releases as such, we won't
accidentally force-push them. (ref https://github.com/spesmilo/electrum/issues/8162)
I think we can just create a new branch whenever we would want to force-push
the existing one.
- also factored out some parameters so that it is easier to programmatically
access them from the fdroid build script.
see https://gitlab.com/fdroid/fdroiddata/-/merge_requests/15858#note_2136094409
Looks like upstream key file changed. Still the same crypto key, just updated expiration date.
```
$ sha256sum winehq_20*
78b185fabdb323971d13bd329fefc8038e08559aa51c4996de18db0639a51df6 *winehq_2019.key
d965d646defe94b3dfba6d5b4406900ac6c81065428bf9d9303ad7a72ee8d1b8 *winehq_2024.key
$ gpg winehq_2019.key
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2018-12-10 [SC]
D43F640145369C51D786DDEA76F1A20FF987672F
uid WineHQ packages <wine-devel@winehq.org>
sub rsa3072 2018-12-10 [E] [expired: 2020-12-09]
$ gpg winehq_2024.key
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2018-12-10 [SC]
D43F640145369C51D786DDEA76F1A20FF987672F
uid WineHQ packages <wine-devel@winehq.org>
sub rsa3072 2018-12-10 [E]
```
Co-authored-by: SomberNight <somber.night@protonmail.com>
Use our own logic to go from ELECTRUM_VERSION to numeric android versionCode,
instead of using the default conversion done by python-for-android.
Even before this, we were already patching p4a to modify their logic (see [0]).
This commit changes that logic again, and moves it into a separate script in our repo.
- calculation change is due to the f-droid maintainers asking for the
arch code to be in the least significant digits (instead of most sig digits) (see [1])
I have pushed and changed to a new p4a branch, which is just a copy of the previous one
with 3 commits related to versionCode calc squashed.
[0]: edb7e4fe6d
[1]: https://github.com/spesmilo/electrum/issues/9210#issuecomment-2380559324
To comply with new google play store requirement:
> Starting August 31 2024:
> - New apps and app updates must target Android 14 (API level 34) or higher to be submitted to Google Play
AFAICS, we do not need to adapt to any of the changes.
https://developer.android.com/about/versions/14/behavior-changes-14
Sander van Grieken
SomberNight
ThomasV
thecockatiel