Chrome, Chromium, VSCode, Slack, Signal, Discord, element-desktop,
schildichat.
For the latter two, the feature flag useWayland was removed and a
wrapper script was provided.
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
Most prominently we don't use `phases` because of https://github.com/NixOS/nixpkgs/issues/28910.
This is also problematic when using wrapGAppsHook.
In order to use wrapGAppsHook's automatic wrapping
(this was done manually before because there was no fixupPhase)
we need to install signal at lib/Signal instead of just into libexec.
That's because it would try to wrap .so files.
