Version 5.27.1 is the last version with working Ozone/Wayland support
but we'll have to update to a more recent version soon.
See [0] for more details.
[0]: https://github.com/NixOS/nixpkgs/pull/154003
A new symlink is required to fix the following error:
[3744707:0100/000000.911609:ERROR:egl_util.cc(74)] Failed to load GLES library: libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or directory
zsh: segmentation fault (core dumped) signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland
The GPU acceleration still fails (not sure if it worked before) but at least
"signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland"
launches again (without "--disable-gpu"):
[40492:0115/184719.611780:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40492:0115/184720.256775:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40492:0115/184720.892093:ERROR:gpu_process_host.cc(968)] GPU process exited unexpectedly: exit_code=139
[40620:0115/184721.033949:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.
[40620:0115/184721.069600:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[40620:0115/184721.133265:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[40620:0115/184721.158341:ERROR:gl_utils.cc(318)] [.RendererMainThread-0x227200113f00]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
(After three GPU process crashes Chromium should automatically fall back
to software rendering.)
Fix#155050 (it only fixes the crashes though, not the underlying
issue, but that's likely all we can do for the moment as other Linux
distributions are affected as well; Ozone/Wayland is just not stable yet)
Thanks to [0] we don't need the LD_PRELOAD hack anymore. Now, SQLCipher
will correctly get loaded without having to preload it. With version
5.23.1 this doesn't work (can be verified via the NixOS VM test).
[0]: 917a6f5cf8
This partially reverts commit 241c145226.
It embarrassingly included Signal-Desktop changes/tests that it
shouldn't and I somehow noticed it too late... :o Sorry!
This reverts commit 45bd7b39a4.
It's been three months now since the introduction of this hack so we can
finally drop it. All active users should have a re-encrypted DB by now
since Signal-Desktop builds expire after three months.
AFAIK this is the only reliable way for us to ensure SQLCipher will be
loaded instead of SQLite. It feels like a hack/workaround but according
to the SQLCipher developers [0] "this issue can and should be handled
downstream at the application level: 1. While it may feel like a
workaround, using LD_PRELOAD is a legitimate approach here because it
will substitute the system SQLite with SQLCipher which is the intended
usage model;".
This fixes#108772 for NixOS 20.09 users who upgrade to NixOS 21.05 and
replaces #117555.
For nixos-unstable users this will unfortunately break everything again
so we should add a script to ease the transition (in a separate commit
so that we can revert it for NixOS 21.05).
[0]: https://github.com/sqlcipher/sqlcipher/issues/385#issuecomment-802874340
