Zoom wouldn't show the "Participants"
dialog box when used in a plasma environment;
precisely, the dialog box failed to show its content.
The problem doesn't exist in other
environments like Gnome or Xfce.
Experiments have shown that clearing the environment variable
`QML2_IMPORT_PATH` before calling Zoom fixes the issue.
I suspect the reason to be as follows:
While the zoom build recipe is called with
`libsForQt5xx.callPackage`, putting `qttools.dev` in zoom's
`PATH` is the only connection to nixpkgs' Qt ecosystem.
Zoom brings its own Qt libraries.
Hence it seems to be a good idea to shield
zoom from access to nixpkgs' Qt files to avoid
problems from version mismatch or similar troubles.
So the commit at hand expands zoom's wrapper script
to clear the Qt-related enviornemt variables
`QML2_IMPORT_PATH` and `QT_PLUGIN_PATH`.
Original issue report, with some discussion:
https://github.com/NixOS/nixpkgs/issues/107495#issuecomment-764538071
This is investigation I've done in support of
https://github.com/jruby/jruby/issues/6608 where I noticed some funky
issues with JRuby and module loading.
Looks like that JRuby expects JAVA_HOME to have a directory called
`jmod`, which is consistent with the Java Module system.
Unfortunately, the top level directory for the `jre` or `jdk` /nix/store
entry is not a valid JAVA_HOME since it is missing that directory.
Instead it's set within `lib/openjdk`, and there is a passthru variable
set accordingly.
This fixes JRuby and follows many other derivations.
A simple search in the code-base shows that there are many other
packages that suffer this same bug.
The previous bump to version 1.6.1 left the sha256 of the src attribute
unchanged, and as a consequence, it still built the old version.
But since the make config injected the version number, the binary still
self-reported as 1.6.1, even though it was built from 1.5.0.
PR #115603 / 8ad96b7786 introduced a
syntax error by introducing an '' inside an indented string and thus a
syntax error. Was merged despite the failing ofborg check.
Fix `lorri direnv` triggering an unconditional rebuild every time it is run.
After fixing up the build loop people suddenly started noticing that
lorri was evaluating every time something ran `lorri direnv`, which
could potentially be every time the user switched between buffers in
the editor.
This is not the intended behaviour, since we should run an
unconditional build only the first time the project is added to the
watcher, and after rely on the watcher to notify us of any file
changes (or the user running `lorri internal ping` to force a
rebuild).
Jörg Thalheim