* Update make_libsecp256k1.sh
Avoid error when parent folder has spaces `./make_libsecp256k1.sh: line 31: cd: too many arguments`
* Avoid error when parent folder has spaces, fix for make_libsecp256k1.sh, make_zbar.sh and make_libusb.sh
Co-authored-by: ghost43 <somber.night@protonmail.com>
This reverts commit 0c2a885c66.
Reverting for now due to reproducibility issues:
```
error: /Users/vagrant/Downloads/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: can't open file: /tmp/electrum_compare_dmg/signed_app/Electrum.app/Contents/MacOS/libffi.8.dylib (No such file or directory)
```
`Electrum.app/Contents/MacOS/libffi.8.dylib` is included when building on one machine, but missing on the other...
Will have to investigate later.
related https://github.com/spesmilo/electrum/pull/7918
Instead of using pre-built binary wheels from PyPI.
We should tighten this more (re other requirements-*.txt files),
but there is no C compiler available inside the wine environment atm...
Just uncomment line 53 in make_apk, and you get a testnet apk that can co-exist with your mainnet install.
No need to do a clean rebuild of ".buildozer/" either.
- note: "make theming" is kivy-specific, and not needed for the qml gui apk
- note: "make theming" does not run automatically as part of the build scripts,
although it used to in the past. For reproducible builds, the
"electrum/gui/kivy/theming/atlas" git submodule contains the build
artefacts. However, the user is supposed to manually run "make theming"
when changing the atlas/images.
While attempting to reproducibly build the qml android apk, one of the differences
was due to the "frozenlist" dependency (pulled in by aiohttp) - the compiled C parts
were not deterministic. By setting this env var, we can opt-out [0] of all the C
accelerated parts and just use the pure-python implementation. We are already doing
the same for other aiohttp-related packages anyway.
[0]: c2794cac12/setup.py (L7)
note: unclear where to put these files... `contrib/build-wine/` and `contrib/osx/`
contain binary-building-related files. maybe we could have a `doc/` folder
if the need for more similar files arise.
atm there are these two, plus maybe `contrib/docker_notes.md`.
protobuf 4.x introduced breaking changes compared to 3.20.
To adapt, we would have to regenerate paymentrequest_pb2.py, using protoc>=3.19.0, however ubuntu does not have new enough protoc.
Also, unsure if newly generated paymentrequest_pb2.py would be supported by older versions of protobuf.
Best to just wait for things to settle.
```
electrum/__init__.py:20: in <module>
from .wallet import Wallet
electrum/wallet.py:70: in <module>
from . import transaction, bitcoin, coinchooser, paymentrequest, ecc, bip32
electrum/paymentrequest.py:37: in <module>
from . import paymentrequest_pb2 as pb2
electrum/paymentrequest_pb2.py:36: in <module>
_descriptor.FieldDescriptor(
.tox/py3/lib/python3.9/site-packages/google/protobuf/descriptor.py:560: in __new__
_message.Message._CheckCalledFromGeneratedFile()
E TypeError: Descriptors cannot not be created directly.
E If this call came from a _pb2.py file, your generated code is out of date and must be regenerated with protoc >= 3.19.0.
E If you cannot immediately regenerate your protos, some other possible workarounds are:
E 1. Downgrade the protobuf package to 3.20.x or lower.
E 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will use pure-Python parsing and will be much slower).
E
E More information: https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
```
ceaae1b6a3/CHANGES.txt (L47)