does not work with current beta:
```
d142c5534f4da4a7f0a1f52676716908f674ff9e06b87f7b153384b161296eaf /home/user/wspace/electrum/contrib/android/../../dist/Electrum-4.5.0.0-armeabi-v7a-release-unsigned.apk
+ mv dist/Electrum-4.5.0b0.0-armeabi-v7a-release-unsigned.apk dist/Electrum-4.5.0b0.0-armeabi-v7a-release.apk
mv: cannot stat 'dist/Electrum-4.5.0b0.0-armeabi-v7a-release-unsigned.apk': No such file or directory
```
- risk_of_burning_coins_as_fees is turned into a private (helper) method, only called by check_sighash.
UIs should only care about check_sighash.
- check_sighash returns instance of new class "TxSighashDanger" instead of tuple
- made warning levels more fine-grained (FEE_WARNING_SKIPCONFIRM vs FEE_WARNING_NEEDCONFIRM)
- this became more complicated than I had hoped for but I think it is worth it to ~merge
check_sighash and risk_of_burning_coins_as_fees into one.
related https://github.com/spesmilo/electrum/pull/8699
I think it's nicer for the network status to be rightmost, which was the case for a long time.
(Though plugins are still added after (via multiple different mechanisms, see 2fa, hww, revealer).
We could perhaps add a VLine separator, or add them to the left instead.)
follow-up 90d1d587e8
follow-up https://github.com/spesmilo/electrum/pull/8651
We cannot do direct comparison of path-like strings without normalisation.
E.g.
```
relative_path() cp1. path='c:\\users\\user\\appdata\\roaming\\electrum\\wallets\\9dk', wallets=C:\Users\User\AppData\Roaming\Electrum\wallets
relative_path() cp2. commonpath='c:\\users\\user\\appdata\\roaming\\electrum\\wallets'
relative_path() cp3. new_path='9dk'
```
- For the notarisation, we were using "altool" (part of xcode), but Apple now fully deprecated that.
- need to migrate from altool to notarytool
https://developer.apple.com/news/?id=y5mjxqmn
- currently using macOS 10.14.6
and xcode 11.3.1
- notarytool requires xcode 13+
- xcode 13 requires macOS 11.3
https://en.wikipedia.org/wiki/Xcode#Version_comparison_table
==> created new build VM with macOS 11.7.10 and xcode 13.2
With newer xcode (12+, I think), the default behaviour is to build
universal binaries that include native code for both arm64 and x86_64.
On older xcode, the default was to only target x86_64.
I am not sure why, but "hid.cpython-310-darwin.so" is not built
reproducibly when it is "universal".
(Even for consecutive builds done on the same machine.)
```
- + diff='Files /tmp/electrum_compare_dmg/signed_app/Electrum.app/Contents/MacOS/hid.cpython-310-darwin.so and /tmp/electrum_compare_dmg/dmg2/Electrum.app/Contents/MacOS/hid.cpython-310-darwin.so differ
```
This commit works around the reproducibly issue by making clang only
build for the x86_64 target. The binary should still be able to run
on arm64 macs using rosetta (same with previous versions of Electrum).
-----
The `lipo` tool can tell what archs a shared object is built for, e.g.:
```
$ lipo -info /Users/vagrant/electrum/contrib/osx/build-venv/lib/python3.10/site-packages/hid.cpython-310-darwin.so
Non-fat file: /Users/vagrant/electrum/contrib/osx/build-venv/lib/python3.10/site-packages/hid.cpython-310-darwin.so is architecture: x86_64
```
For quick testing, we don't need to build the whole .app, only hid.so:
```
source /Users/vagrant/electrum/contrib/osx/build-venv/bin/activate
export CFLAGS="-g0"
python3 -m pip install -I --no-build-isolation --no-dependencies --no-binary :all: --no-warn-script-location hidapi==0.14.0
strip -x /Users/vagrant/electrum/contrib/osx/build-venv/lib/python3.10/site-packages/hid.cpython-310-darwin.so
cp /Users/vagrant/electrum/contrib/osx/build-venv/lib/python3.10/site-packages/hid.cpython-310-darwin.so /Users/vagrant/wspace/tmp/try7/hid10.so
```
Re ARCHFLAGS env var, see https://stackoverflow.com/a/5808548
-----
Note: I've found several xcode build settings that looked relevant
but in the end were not useful, e.g. ARCHS, ONLY_ACTIVE_ARCH,
EXCLUDED_ARCHS, VALID_ARCHS.
- see https://developer.apple.com/documentation/technotes/tn3117-resolving-build-errors-for-apple-silicon
- see https://stackoverflow.com/a/64422757
In the db, the 'seed_type' field could be present both at the top-level and inside keystores.
Note:
- both fields had usages
- the top-level field was added in 2.8 re "initial segwit support" (3a64ec0f2e)
- there was no db upgrade for it, so older files are missing it
- if present, valid values can be electrum types but also
other types supported by the wizard, e.g. "bip39"
- the keystore-level field was added in 4.1 (7b7bba2299)
- there was a db upgrade when it was introduced, so old files also have it
- if present, valid values can only be electrum types
- there is not much value in the top-level one having a non-electrum value,
and those values were never used by other parts of the code
- note that when creating a standard wallet from a bip39 seed, the seed is discarded.
Only the derived xprv and the derivation path are kept. If we changed this and also kept the seed,
e.g. to display it to the user, then it would make sense to save the seed type (e.g. "bip39").
However storing that seed_type would make more sense at the keystore level (not top-level).
We delete the top-level 'seed_type' field.
```
{
"keystore": {
"seed_type": "segwit",
...
},
"seed_type": "segwit",
...
}
```
```
32.40 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/qt/wizard/wallet.py", line 709, in <lambda>
button.clicked.connect(lambda: Bip39RecoveryDialog(self, get_account_xpub, on_account_select))
File "/home/user/wspace/electrum/electrum/gui/qt/bip39_recovery_dialog.py", line 40, in __init__
fut = asyncio.run_coroutine_threadsafe(coro, network.asyncio_loop)
AttributeError: 'NoneType' object has no attribute 'asyncio_loop'
```
