There was an issue where webbrowser.open would invoke a program like
kde-open5 that loaded the systems libQt5DBus, which was not satisfied
with the AppImage's libdbus. To fix this we fork the process, unset
LD_LIBRARY_PATH and then open the URL.
fixes#5425
-----
taken from Electron-Cash/Electron-Cash@00939aafd1c8e9c1cbf56615bcf9a18db1ff15c2
This slightly increases the AppImage size but allows us to be more
compatible with older distributions.
-----
taken from Electron-Cash/Electron-Cash@96644acd6fd66f866a86613974bb68bb99f00d8c
This suppresses the pip script location warnings, like we already
do for AppImage. It also disables the Wine debugging messages by
setting WINEDEBUG=-all.
-----
taken from Electron-Cash/Electron-Cash@d3685b038ef0dc3dc6a18345e51ff231c97623f5
It warns about scripts being installed in a location that is not on the
path, but that is inconsequential as they are not used.
-----
taken from Electron-Cash/Electron-Cash@9a29017c5d8906bb04f7e188bf483b0d3ff698f4
This seems to reduce anti-virus false positives.
based on:
Electron-Cash/Electron-Cash@1ac12e41114b509be90c75213829a73621f1610e
Electron-Cash/Electron-Cash@9726498e95166801ac1e6326ae5833b965df72e3
Electron-Cash/Electron-Cash@40b1139d67013b90b983dc3f9185a771d38e57ff
ran "appimagelint" and apparently icon file needs to be a square
(could have just created another copy, but I guess a square icon
might make sense in other cases too)
Triggering needs two consecutive scripthash status changes
in very quick succession. Client gets notification from server,
but then response to "blockchain.scripthash.get_history" will already contain
the changed-again history that has a different status.
20190627T101547.902638Z | INFO | synchronizer.[default_wallet] | receiving history mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL 1
20190627T101547.903262Z | INFO | synchronizer.[default_wallet] | error: status mismatch: mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL
jsondb takes a copy of the whole self.receiving_addresses
good for avoiding race conditions but horrible for performance...
this significantly speeds up at least
- synchronize_sequence, and
- is_beyond_limit (used by Qt AddressList)
see bitcoin/bitcoin@217208a36d210e7d51e405d0e531ac2b75a3a087
-----
A lot of time was wasted on this... over the years actually...
Some notes and rant here, for future reference.
During the initial effort to try to make binaries reproducible,
out of the three windows binaries being distributed (standalone, portable, setup),
only the first two were successfully made deterministic.
Later, we started to use Docker-based builds. At that point ThomasV and I
could reproducibly build the same setup/nsis exe but Travis kept building a different one.
Recently I have noticed that if I do two subsequent builds of the setup exe on
the same machine, adding a new file in contrib/build-wine/ between the builds,
then I get different binaries. Playing around with this a bit, it seems:
- other files that are in the same folder as contrib/build-wine/electrum.nsi affect the binary
- only files that are in exactly the same folder matter (not recursively)
- only filenames matter (not permission, owner, timestamps, or file contents)
To see the difference in the binaries, use vbindiff, and disable the compression done
by nsis (SetCompress off).
There is a ~48 byte diff near the very beginning of the "Uninstaller" section.
I am only guessing it is the uninstaller section based on the sizes of the sections
printed by nsis during the build.
I have downloaded the binary built by Travis, and the diff is consistent with this
(i.e. it's the same kind of diff that manifests if I change the filename of one of
the supposedly unrelated files).
Commenting out the "WriteUninstaller" line in .nsi fixes the issue. i.e. if no
uninstaller is created then the binary becomes deterministic.
Commenting out the "!define MUI_ICON" line in .nsi also fixes the issue.
At this point I remembered the above referenced commit by bluematt; which I had
thought we had already followed up on...
Replacing the .ico file fixes the issue.
Note that it's not actually clear what the exact requirements for the .ico file are.
Removing any of the layers in the image seems to introduce non-determinicity.
The new .ico file has layers with resolutions and properties the bitcoin.ico file has.
I guess NSIS must have strict requirements for the icon size, and if a given size icon is missing
it might be creating it itself?? And during the downscaling it uses a non-deterministic
algorithm that initialises some RNG from the directory listing (bauerj's guess somewhat adapted :D).
Just crazy.
When building in docker on macOS, python builds with .exe extension
because the case insensitive file system of macOS leaks into docker.
This causes the build to result in a different output on macOS compared
to Linux. We simply patch sysconfigdata to remove the extension.
Some more info: https://bugs.python.org/issue27631
SomberNight
Axel Gembe
ThomasV
nachunjae