Usuage: Add breakpointHook to your `buildInputs` like this:
stdenv.mkDerivation rec {
# ...
buildInputs = [ breakpointHook ];
});
When the build fails as show in this example:
pkgs.hello.overrideAttrs (old: {
buildInputs = [ breakpointHook ];
postPatch = ''
false
'';
});
It will halt execution printing the following message:
build failed in patchPhase with exit code 1
To attach to this build run the following command as root:
cntr attach -t command cntr-/nix/store/ynyb4n82x2r7sldd58pbb405jdqh5f00-hello-2.10
Installing cntr and running the command will provide shell access to the
build sandbox of failed build:
sudo cntr attach -t command cntr-/nix/store/ynyb4n82x2r7sldd58pbb405jdqh5f00-hello-2.10
WARNING: bad ownership on /nix/var/nix/profiles/per-user/root, should be 1000
[nixbld@localhost:/var/lib/cntr]$
At /var/lib/cntr the sandbox filesystem is mounted. All commands and
files of the system are still accessible within the shell.
To execute commands from the sandbox use the `cntr exec` subcommand.
'cloudflared' is a multi-purpose client-side tool for CloudFlare Argo
Tunnel, CloudFlare Access, as well as including a simple DNS-over-HTTP
(DoH) proxy tool as well.
However, 'cloudflared' is NOT available under an open source license.
Furthermore, the exact terms of redistribution (namely, if we are able
to redistribute binaries at all) are not entirely clear to me. As a
result, I have filed the following bug report concerning the terms of
redistribution for the source code and binaries:
https://github.com/cloudflare/cloudflared/issues/53
'cloudflared' does have source code available, however, and it
encourages users to use 'go install' in order to set it up, in fact (or
download their prebuilt, compiled binaries). So using the source seems
to be encouraged. Even then, I'm still not sure if Hydra can serve these
binaries.
In lieu of a more pointed answer regarding source/binary licensing, and
to avoid keeping this expression in my private tree, I've marked it as
'unfree' (to avoid Hydra serving it in any way) as well as compiled from
source (to avoid any 'redistribution allowed while unmodified' terms
that may crop up).
The dependencies for this build were generated using 'dep2nix'.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Rootston is just a reference compositor so it doesn't make that much
sense to have a module for it. Upstream doesn't really like it as well:
"Rootston will never be intended for downstream packages, it's an
internal thing we use for testing." - SirCmpwn [0]
Removing the package and the module shouldn't cause much problems
because it was marked as broken until
886131c243. If required the package can
still be accessed via wlroots.bin (could be useful for testing
purposes).
[0]: https://github.com/NixOS/nixpkgs/issues/38344#issuecomment-378449256
Nixpkgs' channel currently can't move forward so long as there is a
trace in evaluating the top-level arguments. Which means that it isn't
possible to add a warning message to warn users of future package
removal.
So the only way forward appears to be just removing the alias
altogether.
(cherry picked from commit b4133ebc17)
Even if infiniband support is enabled the option
is ignored by the configure script and no depencies
to libibverbs.so or librdmacm.so is contained in
the output.
