10k staging builds are not yet finished on Hydra (mostly darwin),
but we now have a 20k jobs rebuilding directly on master, so we would
never get to merge this way...
Update physlock to a more current version which supports PAM and
systemd-logind. Amongst others, this should work now with the slim
login manager without any additional configuration, because it does
not rely on the utmp mechanism anymore.
This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
Additional CUPS drivers can be added via "services.printing.drivers" but
Gutenprint was an exception. It was possible to add a Gutenprint
derivation to that list and it would work at first but unlike the other
drivers Gutenprint requires a script to be run after each update or any
attempt to print something would simply fail and an error would show up
in the jobs queue (http://localhost:631/jobs/):
"The PPD version (5.2.11) is not compatible with Gutenprint 5.2.13.
Please run
`/nix/store/7762kpyhfkcgmr3q81v1bbyy0bjhym80-gutenprint-5.2.13/sbin/cups-genppdupdate'
as administrator."
This is due to state in "/var/lib/cups/ppd" and one would need to run
"/nix/store/.../bin/cups-genppdupdate -p /var/lib/cups/ppd" manually.
The alternative was to enable the following option:
"services.printing.gutenprint" but this had two disadvantages:
1) It is an exception that one could be unaware of or that could
potentially cause some confusion.
2) One couldn't use a customized Gutenprint derivation in
"services.printing.drivers" but would instead have to overwrite
"pkgs.gutenprint".
This new approach simply detects a Gutenprint derivation in
"services.printing.gutenprint" by checking if the meta set of a
derivation contains "isGutenprint = true". Therefore no special
exception for Gutenprint would be required and it could easily be
applied to other drivers if they would require such a script to be run.
- Now simply let the default `unpackPhase` unzip the vsix file. This
should allow users to retrieve the extension directly from github.
- Extensions now installed using their unique id as install folder.
- Extensions under `vscode-extensions` now use the unique id
as extension name.
