fixes https://github.com/spesmilo/electrum/pull/9726/files#r2057787097 :
> The version of readlink installed on macOS does not support the -e flag:
> ```
> 💬 INFO: preparing electrum-locale.
> readlink: illegal option -- e
> usage: readlink [-fn] [file ...]
> ```
>
> On a mac you can install a version of readlink that argbash expects:
> Using homebrew, `brew install coreutils` will install `greadlink` which supports the `-e` flag.
I don't think we actually need to resolve symlinks here.
There are already some examples of similar usage with realpath vs grealpath. Let's just do that.
The Qt lupdate tool that extracts translatable strings from .qml files
writes paths relative to its output .ts file into the .ts file.
These paths are then retained as-is when converted to .pot format.
The last few commits moved around the working directory of the lupdate tool
(from electrum/locale to electrum/locale/build), which resulted in a change
of all relative paths in the final messages.pot we upload to crowdin.
E.g. from:
```
#: ../gui/qml/components/Addresses.qml:64
```
to:
```
#: ../../gui/qml/components/Addresses.qml:64
```
I think a change like this does not invalidate the translations. Still, it is annoying.
This commit adds an extra processing step to "fix" these strings to:
```
#: electrum/gui/qml/components/Addresses.qml:64
```
- this merges `contrib/deterministic-build/locale` and `electrum/locale`
- it is now once again possible have translations when running from a local git clone
- which was already possible in the past before crowdin removed their unauthenticated APIs
- see https://github.com/spesmilo/electrum/issues/9531
- however, the translations available are the often-old frozen strings from electrum-locale
- while previously one could just download the latest strings from crowdin
This removes support for Ledger HW.1 and "Nano" (non-S) devices.
These were manufactured/sold around 2015-2016, and are long unsupported by the upstream vendor.
We previously added a deprecation warning to the GUI [0] released in 4.3.3 (2023-01-02), to warn owners of these devices.
This PR now fully removes support.
As a consequence, the unmaintained btchip-python dependency can now be removed, which solves [1].
[0]: 9b82eb6d06
[1]: https://github.com/spesmilo/electrum/issues/9370#issuecomment-2593675364
note: these sdists are now reproducibly built.
Ideally the person updating the pinned hash should be different from the one who uploaded the dep to PyPI and reproduce and verify the hash. This prevents hiding a backdoor in just the sdist uploaded to PyPI.
but people can try to reproduce the PyPI sdists at any time and ring alarm bells if they can't
- debian 11 only has python 3.9, deb12 has py3.11
- pip install pip is no longer needed, atm apt has new enough pip
- and on deb12, started getting "error: externally-managed-environment"
- faketime does not seem to work properly on debian 12
(getting reproducibility issues for the tarball)
- so instead we untar, fix the timestamps manually, and re-tar
Haven't checked if electrum-ecc compiles libsecp reproducibly.
For now let's just keep the old flow.
(but if we spent time on making that compilation reproducible,
the appimage and the macos builds could use it directly)
setup exe used to install Electrum to `C:\Program Files (x86)\Electrum`,
but now as the binaries are amd64, we should install to `C:\Program Files\Electrum`.
With this change, based on my experiments, looks like if there is an existing install,
nsis will keep using that path, but if it's a fresh install, it will now use the 64-bit path.
follow-up fcc4e1d387
