2020-03-23

<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> you will then get a `AppEvent e` to the handler (which accepts `BrickEvent n e`s)
<clever> jared-w: and the 3rd argument here, is a BChan e, to inject internal events into the brick event loop
<clever> jared-w: the e in `BrickEvent n e` is a custom sum-type that you will feed over the BChan
<clever> jared-w: BChan is just a thin wrapper around an STM chan, so you dont have to directly depend on STM
<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> 14 symlink = "/sbin/init";
<clever> 13 object = config.system.build.toplevel + "/init";
<clever> 16 ] ++ (pkgs2storeContents [ pkgs.stdenv ]);
<clever> 8 system.build.tarball = lib.mkForce (pkgs.callPackage <nixpkgs/nixos/lib/make-system-tarball.nix> {
<clever> 11 storeContents = [
<clever> $ vi nixos-generators/share/nixos-generator/formats/lxc.nix
<clever> ,locate bin/nixos-generate
<clever> that would affect pkgs.lib
<clever> kalbasit: you could use an overlay to just change lib
<clever> raboof: unpack the tar somewhere, and just `grep -r gh9a48qcwzw588vy4w72w93kad0mhhi8` to see what depends on it
<clever> oops, swap the 2 paths around
<clever> raboof: find the root storepath (the one with /init) and then run `nix why-depends /nix/store/path-gcc /nix/store/root-path`
<clever> yep
<clever> pie_[bnc]: basically, for every attr in the `-A foo.bar.baz`, nix will try to call it with all --arg and --argstr
<clever> pie_[bnc]: have you seen the whackyness of what --arg can do?
<clever> pie_[bnc]: are you expecting the pkgs argument to be a set (of all packages) or a path (to nixpkgs) ?
<clever> pie_[bnc]: nix-build will call it with {}, and the defaults may work
<clever> ,callPackage pie_[bnc]
<clever> ZoomZoomZoom: did you run nixos-rebuild as root?
<clever> > "${dunst}"
<clever> kraem: and pkgs.nodejs is an alias to pkgs.nodejs-10_x
<clever> 4680 nodejs = hiPrio nodejs-10_x;
<clever> kraem: the input param is called nodejs
<clever> 1 { stdenv, nodejs, fetchzip }:
<clever> 7552 yarn = callPackage ../development/tools/yarn { };
<clever> the function it calls, then runs stdenv.mkDerivation, which returns a derivation, that has a .overrideAttrs
<clever> kraem: you can then use .override to change those inputs
<clever> kraem: basically, callPackage takes a file that defines a function, and calls it with everything in pkgs, then adds a .override
<clever> kraem: .override is much simpler, when the things you want to change are at that level
<clever> kraem: if you use overrideAttrs, you have to either re-create the buildInputs list, or filter things out, then add things back in
<clever> linarcx: pkgs.glibcLocales
<clever> kraem: nice
<clever> kraem: .overrideAttrs (old: { version="1.21.1"; src=....});
<clever> kraem: overrideAttrs takes a function
<clever> kraem: just set src and version
<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> 4 buildNodejs = callPackage ./nodejs.nix { inherit openssl icu; };
<clever> the whole src attr will need to be overriden
<clever> tilpner: yeah
<clever> you must also override the sha256 under src as well
<clever> kraem: you want .overrideAttrs
<clever> kraem: version is not an argument to nodejs, so .override cant change it
<clever> kraem: builtInputs = [ (yarn.override { nodejs = nodejs-13_x; }) ];
<clever> jluttine: writeText and toJSON should be fairly unique words in the manual
<clever> jluttine: writeText i would expect to find in the nixpkgs manual, and toJSON in the nix manual
<clever> they sometimes have a comment nearby with the type
<clever> jluttine: for builtins.toJSON, check primops.cc in the nix source
<clever> jluttine: for anything in pkgs, use this function to find the location the attr was defined at
<clever> > builtins.unsafeGetAttrPos "writeText" pkgs
<clever> jluttine: i tend to just look at the source
<clever> 3 nodejs = nodejs-12_x;
<clever> kraem: you can just override the nodejs that yarn is using
<clever> 9 yarn = pkgs.yarn.override { inherit nodejs; };
<clever> and all of the other generation management commands like delete and rollback work
<clever> [root@amd-nixos:~]# nix-env --profile /nix/var/nix/profiles/system --list-generations
<clever> nix-env can also read that profile
<clever> ottidmes: about the only place youll find generation numbers, is the bootloader scripts
<clever> MichaelRaskin: if the 2nd switch matches the 1st, it wont do anything
<clever> MichaelRaskin: definitely non-adjacent, you have to switch 3 times, with the 1st and 3rd having identical output
<clever> might be a bug to file on the patchelf repo
<clever> weird
<clever> jakobrs: sounds like the program relies on something in its debug info
<clever> leonardp: maybe #nixos-aarch64 can help more?
<clever> not sure what the solution is
<clever> leonardp: yes
<clever> also fails the same way on nixos-unstable
<clever> not sure what would cause that
<clever> 8450 targetLlvmLibraries = targetPackages.llvmPackages_7.libraries;
<clever> > pkgsCross.aarch64-multiplatform.firefox

2020-03-21

<clever> tilpner: :D
<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
<clever> Avaq: 3 of the cores just sit here and never recover
<clever> Avaq: ive also not tried to enable SMP, so its limited to 1 core, but that is likely an easy problem
<clever> Avaq: hdmi and composite video dont work currently
<clever> Avaq: yeah
<clever> Avaq: currently, its only confirmed to work on the rpi2 and rpi3, and no video modes work
<clever> ,-A hio
<clever> hio: you want ni-env -iA nixos.jdk11
<clever> and the source in firmware/ and arm_chainloader/ is how it boots
<clever> nixos.nix defines everything about the nixos that boots
<clever> Avaq: i just `nixops deploy` and `nixops reboot`, and the pi boots nixos with custom firmware
<clever> Avaq: yeah
<clever> Avaq: and my custom bootloader, will compile all of the rpi firmware from source, and copy it to /boot, along with the kernel and initrd
<clever> Avaq: then my nixos config, line 27 forces a cross-compile to arm, 59 enables my custom bootloader, the rest is pretty standard stuff
<clever> Avaq: first, i have a pretty standard nixops deployment file
<clever> Avaq: ive been experimenting with custom firmware and nixops on my rpi's
<clever> Avaq: you can usually delete all of the initrd's, and it will recover
<clever> Avaq: so you have to delete generations, then switch, and successfully copy all kernels in
<clever> Avaq: nixos-rebuild switch will delete things from /boot after it has copied new things in, based on what generations exist
<clever> Avaq: what are you using your rpi for?
<clever> jluttine: there is similar problems with the nix binary cache config, adding one binary cache causes cache.nixos.org to vanish
<clever> jluttine: i think it will overwrite all of the defaults
<clever> Avaq: so you may need to manually free up some space firt
<clever> Avaq: it deletes the extra ones after it copies the required 5 in
<clever> hio: also, libraries you "install" wont be visible to any program, nix doesnt work like that
<clever> Avaq: try 5 or 10
<clever> Avaq: depends on how often your kernel and initrd are changing
<clever> Avaq: that limits how many generations get copied to /boot/
<clever> Avaq: https://nixos.org/nixos/options.html#boot.loader.ras and look at the configurationLimit
<clever> avn: for c++/go/haskell/rust, you want to stick to nix-shell
<clever> avn: for wine, you just need to append to PATH and set WINEPREFIX
<clever> Avaq: which `boot.loader.*.enable` do you have set?
<clever> Avaq: which bootloader do you have enabled?
<clever> avn: just use stdenv.mkDerivation
<clever> avn: id just ignore mkShell
<clever> das-g[m]: so compilers wont really work under `nix run`
<clever> das-g[m]: also, `nix run` only adds things to PATH, while `nix-shell` will deal with the stdenv and running with setup hooks
<clever> jluttine: nixpkgs/nixos/modules/misc/ids.nix
<clever> jluttine: you can never use adduser/useradd to mutate things
<clever> jluttine: mutableUsers=false just means that all users must be defined in the config
<clever> das-g[m]: that might be a limit of `nix run`, try `nix-shell` instead?
<clever> avn: ${pkgs.glibc}/lib/ld-linux-x86-64.so.2 will fail on other arches
<clever> avn: also, you want to use "${stdenv.cc.bintools.dynamicLinker}" or "$(cat $NIX_CC/nix-support/dynamic-linker)"
<clever> hio: you must use nix-copy-closure, to copy everything the binary depends on
<clever> hio: and if its build by `nix-build`, then nix is aware of what its using
<clever> hio: the compilers used by nix, patch things automatically
<clever> hio: and the one i linked, is identical to what you have manually created, so why not just use dotnet-sdk?
<clever> hio: your better off with a nix package, that runs patchelf for you
<clever> hio: any update that removes gcc-8.3.0
<clever> hio: thats why its better to write a nix package
<clever> hio: yeah, next time things get updated, that will stop working, and you have to find the new path
<clever> Avaq: thats a common problem on pi's, since they lack an RTC
<clever> Avaq: then the SSL certs arent valid yet, or your clock is wrong
<clever> Avaq: what does `date` say on the pi ?
<clever> hio: the real location of ld.so
<clever> hio: you fix that by using patchelf --set-interpreter
<clever> [nix-shell:~]# patchelf --help
<clever> syntax: patchelf [--set-interpreter FILENAME]
<clever> hio: and that is what does not exist
<clever> hio: the interpreter of dotnet is /lib/ld.so or similar
<clever> hio: normal binaries will fail, because both /usr/lib and /lib are missing
<clever> hio: patchelf is explained in the nixpkgs manual
<clever> hio: /lib doesnt exist, so all binaries must be patched to work
<clever> hio: that is why you should write packages for things
<clever> hio: and those binaries will break next time nix upgrades things
<clever> hio: then you need to patchelf all of the binaries
<clever> hio: dotnet is already in nixpkgs
<clever> hio: is it an ELF binary? a shell script?
<clever> hio: it can be confusing as to when .bashrc is ran and when .bash_profile is ran
<clever> avn: yeah, i could see that being a useful option
<clever> avn: try this on the pid of nix-daemon
<clever> [root@amd-nixos:~]# xargs -n1 -0 echo < /proc/17117/environ
<clever> avn: thats showing what is in the .service file, but not the final env vars
<clever> avn: how are you checking nix-daemon's env vars?
<clever> jakobrs: controls nix-env recursion when searching
<clever> jakobrs: you usually dont need it
<clever> jakobrs: it turns a string into a path
<clever> hio: check the nix expression to see how its built
<clever> avn: try systemd.services.nix-daemon.environment
<clever> Avaq, avn: but nix.envVars are also passed on to the environment.sessionVariables, so they become global
<clever> Avaq: line 428 will merge those in first
<clever> Avaq: you can also use nix.envVars like avn just showed
<clever> Avaq: and nixos will automatically merge it in
<clever> Avaq: you can just directly set systemd.services.nix-daemon.environment.NIX_SSL_CERT_FILE
<clever> hio: yeah
<clever> hio: those will need to be properly packaged
<clever> hio: environment.systemPackages = with pkgs; [ chromium vim ];
<clever> Avaq: ah, then youll want to use configuration.nix and nixos-rebuild switch to make it apply
<clever> Avaq: are you on nixos or another distro?
<clever> Avaq: you can only change systemd services by editing configuration.nix
<clever> hio: you havent set a password for that user yet
<clever> hio: are you trying to login as root?
<clever> hio: its probably booting in legacy mode then, so you need to follow the bios directions
<clever> hio: the install CD
<clever> hio: did you boot the CD via efi or legacy?
<clever> hio: did you re-run nixos-install?
<clever> linarcx: it doesnt matter what channel you use, it will build the exact same binaries as i build
<clever> linarcx: then the project will always use that version, and just work for any user with nix
<clever> linarcx: instead of using <nixpkgs> i use this
<clever> linarcx: its better to use either nix-channel, or pin a specific revision
<clever> linarcx: main issue with using a branch like that, is that it will randomly update without any warning, and things may break for you
<clever> hio: what about boot.loader.grub.efiSupport = true?
<clever> hio: was efi.canTouchEfiVariables = true set?
<clever> linarcx: oh, and its nixos-19.09, not release-19.09
<clever> linarcx: your having network problems
<clever> hio: you can just boot the installer again, mount everything to the right place, and resume from step 2.3
<clever> jakobrs: the default for efi.efiSysMountPoint is already /boot
<clever> hio: how is it too late?
<clever> hio: its just named confusingly
<clever> hio: systemd-boot has nothing to do with systemd
<clever> hio: thats if you want to use systemd-boot instead of grub
<clever> hio: 2020-03-21 08:25:46 < clever> hio: it must be set to "nodev" when doing EFI
<clever> hio: what is boot.loader.grub.device set to?
<clever> hio: it must be set to "nodev" when doing EFI