The latest release of appimagetool bundles a new enough version of
mksquashfs. We had been building a fork of mksquashfs but all the
relevant patches there had been upstreamed.
Note: we still need a wrapper when calling mksquashfs, as appimagetool
calls it with "-mkfs-time 0" and we have the SOURCE_DATE_EPOCH env var
set; and these two would conflict.
Two ways to fix: either unset SOURCE_DATE_EPOCH for that context, or
build a wrapper that removes the "-mkfs-time 0". The former would be
cleaner but for some reason I did not manage to build reproducibly
that way. The latter seems to work.
related:
- https://github.com/AppImage/AppImageKit/issues/929#issuecomment-580769875
> Now official squashfs 4.4 makes reproducible images by default
- https://github.com/AppImage/AppImageKit/pull/996
fixes#7198
We recently bumped the bundled version of PyQt (5.14.2->5.15.4).
It seems the new version has a lot more dynamic dependencies.
From https://doc.qt.io/qt-5/linux-requirements.html :
> From Qt 5.15 onwards, Qt does require libxcb 1.11. Also, the -qt-xcb
> configure option got removed that was bundling some of the libs below.
We are using the prebuilt wheels for PyQt5 from PyPI. Presumably those
had previously been built using the -qt-xcb option.
Ubuntu 20.04 needs `libxcb-xinerama.so.0`
and Debian 10 needs `libxcb-util.so.1` for the Qt `xcb` plugin.
-----
ported from 380f04a805
see https://github.com/Electron-Cash/Electron-Cash/issues/2196
-----
In particular, see this comment:
>> I confirmed that both Ubuntu 20.04 and Debian 10.8 clean install have an issue with the 4.2.4 AppImage.
>
> Any idea what broke it? I assume it used to work.
Yes, it did work in 4.2.3 which used PyQt5 5.13.2. I just had a look at the xcb plugin and it definitely has less dependencies:
```
ago@ubuntu2004vm:~/src/Electron-Cash/dist$ ldd squashfs-root/usr/lib/python3.6/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so|grep xcb
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f0ec9d07000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0ec9cdd000)
libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007f0ec6ead000)
```
compared to PyQt5 5.15.2 in 4.2.4:
```
ago@ubuntu2004vm:~/src/Electron-Cash/dist$ ldd squashfs-root/usr/lib/python3.8/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so|grep xcb
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007fcb5715f000)
libxcb-icccm.so.4 => /lib/x86_64-linux-gnu/libxcb-icccm.so.4 (0x00007fcb57158000)
libxcb-image.so.0 => /lib/x86_64-linux-gnu/libxcb-image.so.0 (0x00007fcb56f51000)
libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007fcb56f4c000)
libxcb-util.so.1 => /lib/x86_64-linux-gnu/libxcb-util.so.1 (0x00007fcb56d46000)
libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 (0x00007fcb56d41000)
libxcb-randr.so.0 => /lib/x86_64-linux-gnu/libxcb-randr.so.0 (0x00007fcb56d2e000)
libxcb-render-util.so.0 => /lib/x86_64-linux-gnu/libxcb-render-util.so.0 (0x00007fcb56d27000)
libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007fcb56d16000)
libxcb-shape.so.0 => /lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x00007fcb56d11000)
libxcb-sync.so.1 => /lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007fcb56d07000)
libxcb-xfixes.so.0 => /lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x00007fcb56cfd000)
libxcb-xinerama.so.0 => /lib/x86_64-linux-gnu/libxcb-xinerama.so.0 (0x00007fcb56cf8000)
libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007fcb56cda000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fcb56cae000)
```
The `git clean --dry-run` became redundant with "fresh clone" builds.
The new exclude in MANIFEST.in should not affect production builds (also due to fresh clone),
but they are nice when building from dirty local dir.
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.
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/
the one in apt refused to install certain package versions (that were pinned by hash!!)
and installed different versions instead... e.g.:
Collecting wheel==0.34.2 (from -r /opt/electrum/contrib/build-linux/sdist/../../../contrib/deterministic-build/requirements.txt (line 112))
Downloading 521c6dc7feb90b06dc1d0b805b51ae/wheel-0.34.2.tar.gz (58kB)
100% |████████████████████████████████| 61kB 3.8MB/s
Requested wheel==0.34.2 from 521c6dc7feb90b06dc1d0b805b51ae/wheel-0.34.2.tar.gz#sha256=8788e9155fe14f54164c1b9eb0a319d98ef02c160725587ad60f14ddc57b6f96 (from -r /opt/electrum/contrib/build-linux/sdist/../../../contrib/deterministic-build/requirements.txt (line 112)), but installing version 0.30.0
SomberNight
gruve-p
Thorsten Hempel
ThomasV
Axel Gembe
Jin Eguchi