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.
SomberNight
Sander van Grieken
Salvatore Ingala
ThomasV