Updates the appimage build scripts to use the newer
https://github.com/AppImage/appimagetool tool to bundle the appimage
instead of the discontinued https://github.com/AppImage/AppImageKit.
To prevent the new appimagetool from downloading a random "latest"
appimage runtime (`type2-runtime`) binary this PR also adds
functionality to clone and build
https://github.com/AppImage/type2-runtime from source. This is done
using the build scripts provided in the `type2-runtime` repository,
however the Dockerfile they use for building is replaced by a copy with
pinned package versions to prevent issues with reproducibility.
This should fix the issue of missing libfuse2 which users of the appimage
have on "modern" distributions.
The new `type2-runtime` is statically linked and includes the required
dependencies now instead of relying on the host to provide it.
if I ran the script with the *.sombernight_releasekey.asc sigs present in dist/,
"SomberNight" and "sombernight_releasekey" were both included as signers
Adds a script `make_barcode_scanner.sh` which builds the
`BarcodeScannerView` library and its dependencies, `zxing-cpp` and
`CameraView` from source. Builds `zxing-cpp` architecture dependent
reducing the final apk size.
pins the barcode scanner aar used in the android build and its 2
dependencies to a sha256 hash using a script `fetch_barcode_scanner.sh`
which is called in the process of building the apk by `make_apk.sh`.
It fetches the 3 aar files if not already existing, puts them in
`/contrib/android/aars` and verifies their shasum against the hardcoded
hashes in `fetch_barcode_scanner.sh`.
Replaces the unmaintained and unreliable
`me.dm7.barcodescanner:zxing:1.9.8` qr code scanning library used only
on android with the `com.github.markusfisch:BarcodeScannerView:1.6.0`
(https://github.com/markusfisch/BarcodeScannerView) library which seems
more actively maintained.
The `BarcodeScannerView` library is incredibly fast and scanning qr
codes is now fun again :)
wip: still looking into ways to pin the library.
Adds a check to the Windows nsis installer and uninstaller
that will show an error popup if Electrum is still running to prevent
a broken installation that happen if the installer only partly
overwrites the existing installation (see #6748).
This works by trying to open the .exe files in the Electrum installation
directory in append mode, if Electrum is still running the installer
will not be able to open the .exe and the check fails.
Based on https://github.com/Electron-Cash/Electron-Cash/pull/2185
If osslsigncode is missing `build-wine/unsign.sh` fails silently with
status code 0 causing the `release.sh` script to interpret the result as
valid and skipping the actual comparison of the windows binaries.
adds binary downloading from website if the specified signer is not one
of the two hardcoded signers with sftp access to the airlock server.
This makes it easier for other signers to run the script and create
signatures for spesmilo/electrum-signatures.
probably since qt6 migration many symlinks inside the .app in bundled PyQt were broken:
```
$ cp -r $HOME/electrum/dist/Electrum.app Electrum-ghost3.app
cp: /Users/vagrant/electrum/dist/Electrum.app/Contents/Resources/PyQt6/Qt6/lib/QtMultimediaQuick.framework/QtMultimediaQuick: No such file or directory
cp: /Users/vagrant/electrum/dist/Electrum.app/Contents/Resources/PyQt6/Qt6/lib/QtQuickTimeline.framework/QtQuickTimeline: No such file or directory
cp: /Users/vagrant/electrum/dist/Electrum.app/Contents/Resources/PyQt6/Qt6/lib/QtQuickControls2.framework/QtQuickControls2: No such file or directory
```
We were stripping out lots of datas/binaries from Qt from the mac build artifact, leaving behind dangling symlinks.
Instead of adding more hacks on top of the current hacks to also rm the dangling links, I tried to clean up this blacklisting.
There was no issue re the Windows build, no symlinks there, but I like to keep these two spec files in sync.
-----
Some numbers:
- mac:
- without any exclusions at all, the mac .dmg is 80 MiB.
- with these exclusions it is 57 MiB.
- win:
- (haven't built without exclusions.)
- with the previous stripping strategy, exes were 68M/68M/50M
- with these exclusions, exes are 66M/66M/50M
makes build not reproducible
random temporary paths leak into a compiled .so:
dist_ghost43/Electrum.app/Contents/Resources/propcache/_helpers_c.cpython-312-darwin.so
trezor==0.13.10 pulls in new dep "slip10", which relies on importlib magic
see 19561f0429/slip10/__init__.py (L6)
```
10.13 | E | plugins.trezor.trezor | error importing trezor plugin deps
Traceback (most recent call last):
File "importlib/metadata/__init__.py", line 397, in from_name
StopIteration
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "electrum/plugins/trezor/trezor.py", line 29, in <module>
from .clientbase import TrezorClientBase, RecoveryDeviceInputMethod
File "PyInstaller/loader/pyimod02_importers.py", line 450, in exec_module
File "electrum/plugins/trezor/clientbase.py", line 18, in <module>
import trezorlib.device
File "PyInstaller/loader/pyimod02_importers.py", line 450, in exec_module
File "trezorlib/device.py", line 27, in <module>
File "PyInstaller/loader/pyimod02_importers.py", line 450, in exec_module
File "slip10/__init__.py", line 6, in <module>
File "importlib/metadata/__init__.py", line 889, in version
File "importlib/metadata/__init__.py", line 862, in distribution
File "importlib/metadata/__init__.py", line 399, in from_name
importlib.metadata.PackageNotFoundError: No package metadata was found for slip10
```
note: 3.12 just transitioned to security-only status,
so can't bump win/mac binaries without switching to 3.13
(as we don't compile our own cpython for those)
note: some files have two versions in them, e.g.:
```
assert CffiRecipe._version == "1.15.1"
class CffiRecipePinned(util.InheritedRecipeMixin, CffiRecipe):
version = "1.17.1"
```
The assert is left there as I think it might be useful to get a failure if we rebase p4a
and the upstream recipe version changes. There might be substantial changes in the upstream
recipe that we need to adapt to. In the happy case, if we rebase p4a, we just have to manually
update these asserts to the new versions at that time.
