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'
```
This should fix an issue when running with python 3.11 (possibly only 3.11.5<= ).
```
47.45 | I | exchange_rate.CoinGecko | getting fx quotes for EUR
48.18 | E | exchange_rate.CoinGecko | failed fx quotes: ClientOSError('Cannot write to closing transport')
Traceback (most recent call last):
File "...\electrum\env11\Lib\site-packages\aiohttp\client.py", line 599, in _request
resp = await req.send(conn)
^^^^^^^^^^^^^^^^^^^^
File "...\electrum\env11\Lib\site-packages\aiohttp\client_reqrep.py", line 712, in send
await writer.write_headers(status_line, self.headers)
File "...\electrum\env11\Lib\site-packages\aiohttp\http_writer.py", line 130, in write_headers
self._write(buf)
File "...\electrum\env11\Lib\site-packages\aiohttp\http_writer.py", line 75, in _write
raise ConnectionResetError("Cannot write to closing transport")
ConnectionResetError: Cannot write to closing transport
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "...\electrum\electrum\exchange_rate.py", line 85, in update_safe
self._quotes = await self.get_rates(ccy)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "...\electrum\electrum\exchange_rate.py", line 345, in get_rates
json = await self.get_json('api.coingecko.com', '/api/v3/exchange_rates')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "...\electrum\electrum\exchange_rate.py", line 69, in get_json
async with session.get(url) as response:
File "...\electrum\env11\Lib\site-packages\aiohttp\client.py", line 1187, in __aenter__
self._resp = await self._coro
^^^^^^^^^^^^^^^^
File "...\electrum\env11\Lib\site-packages\aiohttp\client.py", line 613, in _request
raise ClientOSError(*exc.args) from exc
aiohttp.client_exceptions.ClientOSError: Cannot write to closing transport
```
related:
https://github.com/romis2012/aiohttp-socks/issues/27https://github.com/python/cpython/issues/109321
Ah ok, I give up for now... the prev does not really work.
The prior commit works on Windows but not on macOS.
On Windows, it would package all plugins as code and only as code.
On MacOS however, it would not package any plugins at all. And with this commit,
where I mark the plugins folder to be packaged as *data*, it packages all plugins as *both* code and data.
Not sure why.
Let's just package all plugins as both code and data, and ignore the code instances explicitly...
The hw_wallet and jade plugins were being included twice in the pyinstaller binaries.
They were apparently the only two plugins being picked as "modules" (a.pure),
which by default are included as compiled-bytecode.
In addition, we included "electrum/plugins" as data (a.data), which meant all
plugins in source form.
Instead of hacking around to fix the specific issue, this attempts a larger clean-up.
