There was no documentation for the "config" option, and it wasn't quite
clear whether it was supposed to be a file, a string, or what. This
commit removes that ambiguity.
- 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.
The installer tests are failing after 505e94256e
due to `nixos-rebuild switch` in the installed system trying to build
stdenvNoCC.
Seems that previously, stdenvNoCC wasn't in the installed
system either, but all the direct dependencies for the build were
(I don't really understand why, for that matter), so the building
actually went fine and everything worked.
But now gcc is also a direct build dependency due to allowedRequisites
containing gcc (even though it doesn't become a runtime dependency)
which doesn't get to the installed system.
All in all, let's ensure stdenvNoCC actually gets to the installed
system. It's after all necessary in almost any NixOS config build.
Ppx_derivers is a tiny package whose sole purpose is to allow ppx_deriving and
ppx_type_conv to inter-operate gracefully when linked as part of the same
ocaml-migrate-parsetree driver.
Homepage: https://github.com/diml/ppx_derivers
There were several fixes that make the exporter work with new unifi software
However there is not yet a release so I just updated to the latest master.
This updates canto-daemon to version 0.9.7 and canto-curses to version
0.9.9. I've tested building both and executing them (although without
very comprehensive tests) and they do work on my machine.
I haven't tested the NixOS service module however, but given that
@devhell is also the maintainer of these packages and the service
module, I trust that he's done testing by himself.
The build calls ar(1) in a way the tool doesn't like:
ar q cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi64.o src/x86/unix64.o src/x86/ffi.o src/x86/sysv.o
ar: creating cru
ar: .libs/libffi.a: No such file or directory
make[4]: *** [Makefile:717: libffi.la] Error 1
This may have become an issue after some recent binutils update; I'm not sure.
