with wine 6.0.2 and 6.0.3, cpython 3.9.11 fails to install (but cpython 3.9.10 worked)
```
010c:err:virtual:virtual_setup_exception stack overflow 1220 bytes in thread 010c addr 0x7bc6713d stack 0x440b3c (0x440000-0x441000-0x640000)
🗯 ERROR: wine msiexec failed for dev.msi
🗯 ERROR: prepare-wine failed
```
-----
btw, related note:
After changing the Dockerfile, building the docker image from cache failed. Setting ELECBUILD_NOCACHE=1 fixed it:
```
E: Could not configure 'libc6:i386'.
E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
$ ELECBUILD_NOCACHE=1 ./contrib/build-wine/build.sh
```
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.
The .pyc files would get created when a .py module is imported,
which is done during the build for some source files by pyinstaller
(when it analyses imports).
I considered setting PYTHONDONTWRITEBYTECODE=1 in build_tools_util.sh,
to apply to all builds, but am not sure how it would affect the Android build,
where we actually want .pyc files included in the apk.
This commit ports the work of EchterAgo and cculianu from Electron-Cash,
to implement a new toolchain to scan qr codes.
Previously, on Linux and Win, we have been using zbar to access the camera
and read qrcodes; and on macOS we used CalinsQRReader (an objective-C
project by cculianu).
The new toolchain added here can use QtMultimedia to access the camera,
and then feed that image into zbar. When used this way, zbar needs
fewer dependencies and is easier to compile, in particular it can be
compiled for macOS.
The new toolchain works on all three platforms, with some caveats
(see code comments in related commits) -- so we also keep the end-to-end
zbar toolchain; but at least we can drop CalinsQRReader.
The related changes in Electron-Cash are spread over 50+ commits (several PRs and direct
pushes to master), but see in particular:
https://github.com/Electron-Cash/Electron-Cash/pull/1376
some other interesting links:
b2b737001c163224cf1f3b31e0fcb1eda015908ehttps://github.com/Electron-Cash/Electron-Cash/pull/1545052aa06c23
was exiting with non-zero error code due to trying to copy directory
```
9cf9cdda331b565dd95b105d3fe987beefa113ac2c594d83783998017ad52d70 dist/electrum-4.1.4-16-g648fac709-portable.exe
020ceacb3a6fc5986d3ec271985c22c8646d2bb534536b8e2ab774924b21d58f dist/electrum-4.1.4-16-g648fac709-setup.exe
e65dbbe24fe01e8635d4def088667e65d4e9763e2ab74cbc1aec616b3f2834bc dist/electrum-4.1.4-16-g648fac709.exe
💬 INFO: Done.
cp: -r not specified; omitting directory '/home/user/wspace/electrum/contrib/build-wine/../../contrib/build-wine/fresh_clone/electrum/contrib/build-wine/dist/electrum'
```
Had to also bump ubuntu version 18.04->20.04,
as was getting errors running the self-compiled pyinstaller otherwise (weird...):
```
from .utils.git import get_repo_revision
ModuleNotFoundError: No module named 'PyInstaller.utils'
```
(similar to https://github.com/pyinstaller/pyinstaller/issues/4403 )
-----
Note re appimage: when trying to compile python 3.8.x on ubuntu 16.04, I am getting:
./Modules/posixmodule.c: In function ‘os_copy_file_range_impl’:
./Modules/posixmodule.c:10351:15: error: implicit declaration of function ‘copy_file_range’ [-Werror=implicit-function-declaration]
ret = copy_file_range(src, p_offset_src, dst, p_offset_dst, count, flags);
This is because ubuntu 16.04 has too old glibc.
The "setup" Windows binary we distribute allows users to "install" Electrum
on their system. The distributable is created by NSIS. During
installation a bunch of files will get unpacked in %programfiles(x86)%/Electrum,
including an "inner" exe that will be the entrypoint for the user to start
the application. A shortcut is also created for the inner exe.
With this change, there will now be two inner EXEs. One the same as before,
the other with a "-debug" suffix in its name. The debug exe is built as a
"console" application (as opposed to a "windowed" application), so when
launched via double-click a black console window would appear; and also
importantly stdin/stdout are handled properly for it (unlike for "windowed"
programs). (see #2592)
There will not be a shortcut or similar for the debug exe; it would just
be there as a debugging option we can instruct users to use when needed.
In particular early crashes during startup are hard to debug without
stdout/stderr. (see e.g. #6601)
- our new key now supports both
- note that we don't bother to "dual sign" for both sha1 and sha2, as
Win7 upwards sha2 is supported (and we already don't support XP, Vista, etc anymore)
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/
SomberNight
bitromortac
Andrew Kozlik
Benoit Verret
Jin Eguchi