It was failing with:
Traceback (most recent call last):
File "/nix/store/…-solfege-3.22.2/bin/.solfege-wrapped", line 55, in <module>
from solfege import presetup
File "/nix/store/…-solfege-3.22.2/share/solfege/solfege/presetup.py", line 22, in <module>
import gtk
ImportError: No module named gtk
The current algorithm creates attributes with null values for packages
with no source in a variant of MELPA. Though will satify dependencies
they produce no files, and though a build that transitively depends on
one them will be successful, Emacs won't find them and any code
depending on them won't work.
The solution with minimal code change would have been filtering the
list of results from melpaDerivation by comparing the value against
null, but that leads to an infinite recursion.
This commit also moves legacy renames from the shared to the unstable
set, as the corresponding null value elements won't exist in the
stable set anymore.
The test used for the problem was:
$ nix-build --show-trace ./default.nix -A emacs26Packages.melpaStablePackages.findr
error: expression does not evaluate to a derivation (or a set or list of those)
The expected output, obtained with this commit is:
$ nix-build --show-trace ./default.nix -A emacs26Packages.melpaStablePackages.findr
error: attribute 'findr' in selection path 'emacs26Packages.melpaStablePackages.findr' not found
This reverts commit 7cb100b683.
See also #83432.
This appears to break at least the `container`-backend of `nixops`: when
running `switch-to-configuration` within `nixos-container run`, the
running `systemd`-instance gets reloaded which appears to kill the
`systemd-run` command and causes `nixos-container run` to hang.
The full issue is reported in the original PR[1].
[1] https://github.com/NixOS/nixpkgs/pull/67332#issuecomment-604145869
(cherry picked from commit 7f1ba606ac632c50efd33c435aa59e69d4f58acc)
Maximilian Bosch