or more like four:
```
$ pipdeptree
hatchling==1.11.1
- editables [required: >=0.3, installed: 0.3]
- packaging [required: >=21.3, installed: 21.3]
- pyparsing [required: >=2.0.2,!=3.0.5, installed: 3.0.9]
- pathspec [required: >=0.10.1, installed: 0.10.1]
- pluggy [required: >=1.0.0, installed: 1.0.0]
- tomli [required: >=1.2.2, installed: 2.0.1]
```
Let's monitor how the situation evolves, and whether other packages start requiring hatchling,
but for now I am not going to add four new packages into the trusted base set...
Pinning colorama to an older version for now.
related:
https://github.com/tartley/colorama/pull/338https://github.com/tartley/colorama/issues/349
note: python 3.9.x is now in source-only mode, so could not update to latest...
it is time to investigate upgrading to python 3.10 in the win and mac binaries
note: the extra copies in make_osx.sh are needed because of the CI caching
(pyinstaller needs to see the .dylib's inside electrum/, e.g. when importing electrum during Analysis)
The google play store will require 31, starting 2022-11 (next month).
A few commits are cherry-picked onto our forks of p4a and buildozer
from upstream, but the forks are not rebased.
Note that the compileSdkVersion is kept at 30,
only the targetSdkVersion is bumped 30->31.
closes https://github.com/spesmilo/electrum/pull/8010
I am trying to upstream some relevant p4a and buildozer changes
in e.g. https://github.com/kivy/python-for-android/pull/2686
The current system python in the docker baseimage is py3.9, while the
targetpython and hostpython built by p4a are py3.8, and this was causing
linker issues in the pyqt5 build.
It is also cleaner IMHO to have p4a handle what is needed for a recipe
instead of assuming it is available in the system. (and I think this is
how other existing recipes work)
fixes https://github.com/spesmilo/electrum/issues/8016
fixes https://github.com/spesmilo/electrum/issues/8011
> Upgraded from Appimage 4.1.5 to 4.3.2 on MX-Linux 19.
> The new version fails to start with:
>
> ```
> $ electrum
> qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
> This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may > fix this problem.
>
> Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.
>
> Aborted (core dumped)
> ```
debian 10 only distributes libxcb-util0.
debian 11 distributes libxcb-util1.
our base image atm is debian 10, so we build the package from source.
see https://snapshot.debian.org/
> To access snapshots of suites using Valid-Until that are older than a dozen days, it is necessary to ignore the Valid-Until header within Release files, in order to prevent apt from disregarding snapshot entries ("Release file expired"). Use aptitude -o Acquire::Check-Valid-Until=false update or apt-get -o Acquire::Check-Valid-Until=false update for this purpose.
(thanks to Axel Gembe for pointing this out)
ThomasV had libffi installed via brew, and this side-effected the built electrum dmg.
`('libffi.8.dylib', '/usr/local/opt/libffi/lib/libffi.8.dylib', 'BINARY')`
this was the cause of 019d213325
based on 907e5e7009
This way users get more feedback from the OS when they attempt to launch the app on old macOS.
Co-authored-by: Calin Culianu <calin.culianu@gmail.com>
note: newer versions of pyinstaller (4.4+ ?) want to sign the bundle
themselves, in which case modifying the Info.plist file after
pyinstaller returns invalidates the sig.
SomberNight
Salvatore Ingala
Sander van Grieken
ThomasV