- Don't build with libsigsegv by default. The build apparently attempted
to link against it, but it never retained the reference anyway...
- Side effect: stdenv bootstrapping needs no libsigsegv anymore.
- Run checks, but only in the interactive gawk by default on Linux,
so that stdenv bootstrap isn't slowed down (by glibc locales, etc.).
- xz should be no longer needed in inputs, as we have it in stdenvs now.
The whole change was triggered by some used kernel versions still
breaking libsigsegv tests #28464.
- 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 505e94256ef247dc54250
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.
ccPath is only defined below, so this condition would never be true.
Worse, that's not quite true: what if somebody happend to have `/clang`
and no sandboxing. Boy, wouldn't that be annoying to debug!
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
Older bash version, like those in the bootstrap tools and on macOS,
currently confuse variables defined as an empty array with undefined
variables. `${foo+"${foo[@]}"}` will prevent `set -u` problems with
empty arrays and older without making a single '' in the empty case.
Care is taken to `set +u` when running hooks so as to not break existing
packages.
...just as we did for binutils. When the underlying issue is resolved
(probably with a configure script patch or lib/systems/parse.nix
change), this should be reverted.
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.
