<clever>
jared-w: hydra may directly copy from remote -> s3://
<clever>
jared-w: and only when the build is done, will hydra copy the closure between the remote nix and the local nix, if its configured to self-host
<clever>
jared-w: hydra is a bit special, where hydra-queue-runner directly phones to the remote build machine, and initiates the build there, bypassing the local nix-daemon
<clever>
jared-w: normally, nix-daemon handles the remote build machines
<clever>
jared-w: for normal nix builds on the local machine, (and any time you lack write to /nix/store), you just phone out to nix-daemon, and have nix-daemon do the real work
<clever>
stat + event -> new-state
<clever>
jared-w: and the event handler is just `s -> BrickEvent n e -> EventM n (Next s)`
<clever>
jared-w: so you can then have a second haskell thread, that watches the nix protocol, and fires changes over the STM channel
<clever>
jared-w: that event loop can mutate the state, and the render function then just draws a state object
<clever>
jared-w: brick has an event loop, that will receive user input, but can also receive internal events on an STM channel
<clever>
jared-w: and see which jobs are done
<clever>
jared-w: you have N jobs running in parallel, you can scroll thru the logs for any of them, or tail one
<clever>
jared-w: more, along the style of the UI travis/buildkite would have in the browser
<clever>
jared-w: you could use something like brick to make a whole UI, sort of like travis/buildkite, which will also use the nix api, to initiate and monitor builds
<clever>
colemickens: a bit hacky, you can use `nix-build --dry-run` to see that tree, and the root drv file, then `nix build /nix/store/foo.drv` to actually build it
<clever>
colemickens: `nix log /nix/store/foo.drv` will show the logs for a given drv, after the build has ended (pass or fail)
<clever>
jared-w: and use ansii control codes to scroll up a few lines, and keep updating the N lines being displayed
<clever>
jared-w: one improvement i can think of over the current nix 2, which ive seen from yarn, is to output 1 line per building package
2020-03-22
<clever>
raboof: yeah
<clever>
> stdenv
<clever>
raboof: yep
<clever>
raboof: so `nix-shell` doesnt have to download gcc upon first boot
<clever>
raboof: it specially adds the stdenv to the tar, beside the toplevel nixos
<clever>
kraem: yarn isnt as complicated as nodejs
<clever>
kraem: you can use pkgs.yarn.overrideAttrs
<clever>
ottidmes: mkdir -pv root/{foo,bar}/baz
<clever>
kraem: if you just want the yarn/default.nix in nixpkgs, its already been callPackage'd and is at pkgs.yarn
<clever>
superbaloo: use nix-locate to see which package includes the man page
<clever>
kraem: path + "string" always results in a path
<clever>
kraem: stop using builtins.path, you almost never need it
<clever>
tmplt: you have to delete the problematic profile/generation from /nix/var/nix/profiles/
<clever>
jakobrs: thats what i would do as well
<clever>
tmplt: you have a : in the profile name, and : is not a valid part of a filename on fat32
<clever>
jakobrs: id prefer to build only one, and use stdenv.system to decide which one to build
<clever>
tmplt: i would expect that to work, what if you do `nixos-rebuild boot` again ?
<clever>
jakobrs: .so files should be in $out/lib/
<clever>
tmplt: `df -h /boot` ?
<clever>
tmplt: `mount | grep boot` ?
<clever>
tmplt: does dmesg say anything new after the above error happens?
<clever>
tmplt: what does dmesg say?
<clever>
linarcx: ah, they are identical
<clever>
16138 libuuid = if stdenv.isLinux
<clever>
16139 then utillinuxMinimal
<clever>
linarcx: add libuuid or utillinux to the buildInputs
<clever>
,locate mount.pc
<clever>
Orbstheorem: have you looked at the hardware-configuration that nixos-generate-config makes for that machine?
<clever>
Orbstheorem: is it a sata or usb disk?
<clever>
linarcx: tab-completed the wrong name, l and k are beside eachother
<clever>
shweta: what error is it giving?
<clever>
jdelstrother: and i dont see any obvious expression that could contain a sub-section of things
<clever>
jdelstrother: thats still not returning a set, thats returning the builderEnv
<clever>
kraem: there is also a shell.nix in daedalus, but all it does is provide node and yarn, and everything else is done impurely by yarn, as you would on any other distro
<clever>
kraem: yarn2nix does the entire `yarn build` under nix, so you dont need `nix-shell`
<clever>
kraem: ive been using yarn2nix with good success
<clever>
kraem: but you can fix it by adding nodejs_override to the buildInputs
<clever>
kraem: this is why i never install tools like nodejs, so they cant leak in unexpectedly
<clever>
kraem: then that default.nix isnt providing any nodejs at all, and you have a node installed elsewhere that is leaking in
<clever>
kraem: and if you exit the `nix-shell`, what does `type node` report?
<clever>
kraem: what does `type node` report?
<clever>
linarcx: oops
<clever>
kraem: it was already a path
<clever>
linarcx: dont use builtins.path on line 6
<clever>
kraem: that looks much better, does it work?
<clever>
then you could shell into any of those
<clever>
jdelstrother: you need your default.nix to return a set, not a derivation, and that set can then contain things like your-package, gems, and ruby
<clever>
kraem: read this file
<clever>
pkgs/development/web/nodejs/v13.nix
<clever>
kraem: thats not how buildNodejs is used
<clever>
kraem: pkgs.callPackage
<clever>
kraem: inherit (pkgs) openssl;
<clever>
jared-w: so you could add ../foo to it, to go to a sibling
<clever>
jared-w: also, bar only gets copied, when you later force that into a string
<clever>
jared-w: but, let foo = ./.; in foo + "/bar" will copy only bar, creating /nix/store/hash-bar
<clever>
jared-w: so if anything in . changes, everything rebuilds
<clever>
jared-w: let foo = ./.; in "${foo}/bar" will copy ./. in full, then generate /nix/store/hash-something/bar
<clever>
jared-w: mainly, when sources.nixpkgs is a local path, not a derivation
<clever>
kraem: yeah, you can also do `sources.nixpkgs + "/pkgs/development/web/nodejs/nodejs.nix")
<clever>
> pkgs.path
<clever>
kraem: exactly as the main nodejs package does
<clever>
kraem: just run callPackage on the path to nodejs.nix
<clever>
tilpner: you can also use `--option system ...` to change builtins.currentSystem, but that will lie to nix a bit too much, and then it thinks you can run the given arch, which will then fail
<clever>
avn: so you can generate a shell script that runs nix-shell ${hello.drvPath}
<clever>
> hello.drvPath
<clever>
avn: you can run nix-shell on a .drv file
<clever>
bbl
<clever>
then they are rooted, and normal nix-shell can reuse them
<clever>
avn: and then depend on that runCommand somewhere in /etc
<clever>
avn: you basically just want to `echo ${toString foo.buildInputs} > $out` under `runCommand`
<clever>
sleeping-: does `lspci` show a wifi card?
<clever>
jordandoyle: and is firefox-overlay.nix a list or a function?
<clever>
jordandoyle: what about firefox-overlays.nix ?
<clever>
jordandoyle: or you must do `nixpkgs.overlays = [ (import ./overlays) ];`
<clever>
jordandoyle: overlays/default.nix must return a list
<clever>
Avaq: yeah, its fairly low-level arm stuff
<clever>
Avaq: i think i need to copy and adapt this part of the official code