2020-04-07

<clever> vika_nezrimaya: so only /nix can persist data
<clever> vika_nezrimaya: i think gchristensen has a setup, where it will use `zfs rollback` to revert / back to empty on every boot
<clever> bsima: `nix-shell -p python3`
<clever> bqv[m]: i'm guessing they mean deprecated, in terms of you should edit the code to not use it (immediately after you find the right hash)
<clever> srid: builtins.fetchGit returns an attrset, and the git rev is part of it
<clever> srid: patch/edit it to take a revision as a nix variable instead
<clever> srid: why exactly do you need the .git?
<clever> srid: or a sha256
<clever> srid: the builtins are in the nix repo, not nixpkgs
<clever> srid: thats pkgs.fetchgit
<clever> bqv[m]: seems a bit odd to be adding it into deprecated?
<clever> srid: pkgs.fetchgit has a keepDotGit = true; option
<clever> Hi-Angel: this will search, relative to where the git binary is
<clever> $ find $(dirname $(realpath $(which git)))/.. -name diff-highlight -type d
<clever> /nix/store/g8z167wz75247v7jxmnib1f1w4ky3h1m-git-2.23.0/bin/../share/git/contrib/diff-highlight
<clever> Hi-Angel: realpath is a program to turn a symlink into an absolute path, dirname is a program to give the dir that a file is in
<clever> it would even work when git has been installed to /usr/local/
<clever> Hi-Angel: i suspect this will work on both FHS distros and nixos
<clever> -r-xr-xr-x 1 root root 7342 Dec 31 1969 diff-highlight
<clever> $ ls -l $(dirname $(realpath $(which git)))/../share/git/contrib/diff-highlight
<clever> total 40
<clever> Hi-Angel: and the git binary itself is at /nix/store/g8z167wz75247v7jxmnib1f1w4ky3h1m-git-2.23.0/bin/git
<clever> Hi-Angel: /nix/store/g8z167wz75247v7jxmnib1f1w4ky3h1m-git-2.23.0/share/git/contrib/diff-highlight/diff-highlight
<clever> energizer: `nix cat-store` can work even if you `--store s3://bucket` or `--store ssh://host`
<clever> Amit[m]: ah, no idea then
<clever> Amit[m]: what if you run `nix-store --verify --check-contents` ?
<clever> Amit[m]: yeah, that is weird
<clever> Amit[m]: anything in dmesg?
<clever> Amit[m]: how much ram did you give it?

2020-04-06

<clever> hoplaahei: yeah, an override against firefox is likely best
<clever> leons: objcopy also defines these 2 symbols, which tell you where the file exists in ram
<clever> leons: this takes the arm_chainloader.bin file, and jams it into the .data section of arm_chainloader.o, and labels it as being for vc4
<clever> leons: there also another fun trick i'm doing...
<clever> leons: and for mixing arches, the vc4 stuff expects a arm_chainloader/build dir, so line 86 symlinks in the product from the cross-arm
<clever> leons: and then 197-217 pulls select packages out of each cross env, to expose them for normal use
<clever> leons: lines 10-13 applies that overlay, to a range of cross environments
<clever> leons: and line 58 can just add self.common to buildInputs, and it just works
<clever> nix will seamlessly rebuild common any time ./common/ changes
<clever> leons: and common just has a $out/lib/libcommon.a, that you can just -lcommon like any other library
<clever> leons: common, is designed to be able to cross-compile to both arm and vc4, depending on which pkgsCross you get it from
<clever> leons: in here, i wrote a nixpkgs overlay, that defines several libraries and programs
<clever> «derivation /nix/store/c24hf4j0j0bl07crxrp37j482c4hxjan-riscv32-none-elf-binutils-2.31.1.drv»
<clever> leons: you can probably use this
<clever> nix-repl> pkgsCross.riscv32-embedded.buildPackages.binutils-unwrapped
<clever> leons: so i compile the arm stuff with the cross arm, then i pass the product to the cross-vc4 package
<clever> leons: i ran into similar issues in rpi-open-firmware, i choose to split the arm and vc4 stuff into seperate derivations
<clever> leons: pkgsCross.riscv32-embedded.stdenv.mkDerivation { name = "something"; } in your shell.nix
<clever> leons: the correct way, is to use the right stdenv.mkDerivation, from the cross-compile env
<clever> wedens[m]: thats just a design problem in nixos-rebuild, it cant use the config until after its done building
<clever> energizer: `nix-copy-closure /nix/store/foo.drv --to host` then `nix-store -r /nix/store/foo.drv`
<clever> energizer: you would need to copy the drv over, and start building it under something like screen
<clever> LnL: yeah, those are some relatively new features,
<clever> LnL: yeah, nixos-rebuild just builds nix from <nixpkgs> then uses that to do the above
<clever> for nixos, it would be more like: nix-env -p /nix/var/nix/profiles/system -f '<nixpkgs/nixos>' -A system --set
<clever> nix-env -p /nix/var/nix/profiles/per-user/root/rpi3-netboot -f not-os/release.nix -A rpi_image -I nixpkgs=./nixpkgs/ --set
<clever> you can use nix-env instead of nix-build
<clever> wedens[m]: once it has done a rebuild switch, it will update /etc/nix/nix.conf and /etc/nix/machines, and respect your configuration.nix
<clever> wedens[m]: and nixos-rebuild will transparently turn it back into a symlink at the next switch (or reboot)
<clever> wedens[m]: if you delete the /etc/nix/nix.conf symlink, you can replace it with a normal file, and freely edit it
<clever> wedens[m]: also, you dont need to use NIX_CONF_DIR
<clever> not sure
<clever> wedens[m]: nixos-rebuid will run nix-build twice, once to build nix, then it uses that nix to build nixos
<clever> you need to copy it to /root/.ssh/config
<clever> energizer: since nix-daemon runs as root
<clever> energizer: yeah, but if nix-daemon is at play, ~ is /root/
<clever> energizer: your telling nix-daemon to ssh into foo, so it uses /root/.ssh/config
<clever> energizer: its root that does the connection though
<clever> pjt_0141: how are you importing it?
<clever> evertedsphere: yeah, that can work
<clever> evertedsphere: and then the <nixpkgs> in nixops fails, until you `-I nixpkgs=...`
<clever> evertedsphere: you would instead do mypkgs=/run/current-system/nixpkgs
<clever> usually in addition to nixpkgs, but you can just break things if you want
<clever> evertedsphere: some people also use <unstable> and <nixos1903> for example
<clever> so you have to actively choose to use it
<clever> nothing can find it by default, because the name is "wrong"
<clever> then just `nix repl '<mypkgs>'`
<clever> evertedsphere: you can always name it something else like <mypkgs>
<clever> evertedsphere: it only breaks using <nixpkgs>
<clever> evertedsphere: `nix.nixPath = []` might do it
<clever> direnv could also be used, to set NIX_PATH=nixpkgs=<URL>
<clever> evertedsphere: so if you always use a shell script to create it, you cant forget
<clever> evertedsphere: i believe it also works at `nixops cretae deployment.nix -I nixpkgs=...`
<clever> evertedsphere: unset $NIX_PATH globally, thats about all you can do
<clever> evertedsphere: and use the same `-I nixpkgs=...` in future deploys
<clever> evertedsphere: if you run `nixops modify deployment.nix -I nixpkgs=...` then nixops will remember it
<clever> evertedsphere: nixpkgs=https://github.com/nixos/nixpkgs/archive/${REV}.tar.gz
<clever> pjt_0141: the env command prints all env vars

2020-04-05

<clever> evertedsphere: and callCabal2nix solves that anoyance entirely!
<clever> evertedsphere: you can also just run cabal2nix yourself, any time the cabal file changes, and then use callPackage
<clever> evertedsphere: using it within nixpkgs isnt allowed, because it harms the performance of `nix-env -i` and such, but your free to use it within your own stuff, and nixpkgs does contain code to help with it (like callCabal2nix)
<clever> evertedsphere: its sort of like template haskell
<clever> ,ifd evertedsphere
<clever> evertedsphere: callCabal2nix will run cabal2nix for you, then run callPackage on the resulting file, using IFD
<clever> zeta_0: oh, line 4 sorta does that now
<clever> zeta_0: add cabal2nix-file somewhere, like in the buildInputs list
<clever> evertedsphere: then `haskellPackages.callCabal<tab><tab>`
<clever> evertedsphere: `nix repl '<nixpkgs>'`
<clever> evertedsphere: try tab completing haskellPackages.callCabal in nix repl
<clever> infinisil: out of order execution!!! lol
<clever> evertedsphere: weird, the bot didnt print it, but your casing is off, its nix, not Nix
<clever> > true
<clever> > haskellPackages.callCabal2nix
<clever> > haskellPackages.callCabal2Nix
<clever> zeta_0: then reference the variable somewhere
<clever> evertedsphere: how did you run it?
<clever> zeta_0: absolutely nothing in that references the cabal2nix-file variable, so you can just delete line 2
<clever> kraem: this helper handles the empty-string case
<clever> > lib.optionalString false "foo"
<clever> > lib.optionalString true "foo"
<clever> zeta_0: you can only put a `key = value;` inside a let block or a set
<clever> kraem: pkgs/os-specific/linux/usbip/default.nix: patches = lib.optionals (lib.versionAtLeast "5.4" kernel.version) [
<clever> kraem: about the only other way to do it, would be to conditionally add a .patch file to the patches list
<clever> mdash: there goes my plans to update everything, lol
<clever> evertedsphere: and the line right after that, maps <nixpkgs> to whatever nixpkgs was used to build the current nixos
<clever> evertedsphere: by default, nixos-rebuild uses <nixos-config> to find configuration.nix, this line remaps it to a file that causes errors, so it never even looks in /etc/nixos
<clever> evertedsphere: and that is your entry-point and pin
<clever> evertedsphere: then `nixops deploy -I nixpkgs=...` or `nixops modify deployment.nix -I nixpkgs=...`
<clever> evertedsphere: if your not using those, it will just use whatever $NIX_PATH pointed <nixpkgs> to
<clever> evertedsphere: you still have to tell nixos-rebuild which nixpkgs to get nixpkgs/nixos/default.nix from
<clever> numkem: ive not used node2nix much, only yarn2nix
<clever> evertedsphere: just delete lines 5 and 9
<clever> evertedsphere: its better to leave nixpkgs.pkgs as-is, and let it come from whatever nixpkgs you got nixpkgs/nixos/default.nix from
<clever> evertedsphere: which can lead to weird bugs, because the services and packages are out of sync
<clever> evertedsphere: line 9 doesnt fully do what you want, it changes the nixpkgs used by nixos, but it doesnt change the nixos modules used by nixos
<clever> numkem: npm wants to download stuff while building, thats what yarn2nix and friends solve
<clever> evertedsphere: can you pastebin the whole nix file?
<clever> evertedsphere: ls -l /run/current-system/sw/bin/sleep
<clever> evertedsphere: maybe you just hadnt downloaded them before?
<clever> evertedsphere: substituteAllInPlace is a variant that doesnt do that
<clever> evertedsphere: i forgot, substituteAll takes 2 params, the input path and output path
<clever> evertedsphere: it helps if you say so, you made it sound like the @xinput@ wasnt being replaced
<clever> evertedsphere: does it give an error, or do nothing?
<clever> jakobrs: otherwise, use a channel, the channels only update when things pass
<clever> jakobrs: read hydra, pick a rev, and paste that into the nix code
<clever> jakobrs: but if you pick a single rev of nixpkgs, you only have to build once
<clever> jakobrs: and you may need to recompile every time you run nixos-rebuild, because master may have changed
<clever> jakobrs: yeah, fetchTarball would work there
<clever> jakobrs: and it could break at any time with no warning
<clever> jakobrs: you can also point it to a revision of nixpkgs when doing the above
<clever> ,unstable jakobrs
<clever> rnhmjoj: i'm mixing a custom stage-1.nix with the nixos kernel.nix, so i can see how you would never predict such failures
<clever> rnhmjoj: https://github.com/cleverca22/not-os/pull/11 should fix it
<clever> rnhmjoj: it breaks not-os, which is reusing kernel.nix outside of nixos
<clever> rnhmjoj: oh, that PR
<clever> rnhmjoj: the `with import <nixpkgs> {};` breaks the channel: evaluation aborted with the following error message: 'Illegal use of <nixpkgs> in Nixpkgs.'
<clever> evertedsphere: do you have an @xinput@ in your script?
<clever> vika_nezrimaya: i'm already editing it to add the dummy option
<clever> asbachb: also, are the idle machines of the same cpu arch?
<clever> asbachb: dont count the machines with a line thru the name
<clever> jakobrs: when all of the tests in https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents turn green, nixos-unstable will update
<clever> numkem: use `strace -f -e trace=execve ....` to see what its trying to run
<clever> numkem: npm sometimes downloads binaries along with the JS
<clever> numkem: that happens any time something downloads a pre-compiled ELF, you must patchelf all the things
<clever> evertedsphere: thats where substituteAll comes into play, and the @token@ patterns
<clever> vika_nezrimaya: looks like a new option got added to nixos/modules/system/boot/kernel.nix, and not-os doesnt support it
<clever> Merge pull request #80114 from rnhmjoj/initrd
<clever> nixos/boot: add option to disable initrd
<clever>
<clever> vika_nezrimaya: it can also generate a diff of nixpkgs, for that range
<clever> vika_nezrimaya: its configured to check nixpkgs master every 10 minutes, so that will be a pretty narrow range
<clever> vika_nezrimaya: and this tells you the first rev that failed
<clever> vika_nezrimaya: https://hydra.angeldsis.com/eval/1319865#tabs-inputs this page tells you which revision of nixpkgs last worked
<clever> vika_nezrimaya: looks like it last worked on march 16th, and has been failing hard since then
<clever> evertedsphere: it does not recurse, you must point it to the dir the scripts are in
<clever> evertedsphere: https://github.com/cleverca22/nixos-configs/blob/master/util.nix#L19-L23 is a very simple example
<clever> evertedsphere: its better to just patch them fully, and not use nix-shell at runtime
<clever> evertedsphere: then youll want to drop the mkdir
<clever> evertedsphere: but if $out/bin does exist, it will keep the hashed name, as a child of bin
<clever> evertedsphere: if $out/bin doesnt exist, it will rename the dir as it copies
<clever> numkem: add zlib to buildInputs
<clever> evertedsphere: the `cp -r` preserved the read-only flag, so it doesnt have permission to patch things
<clever> evertedsphere: oh right, you need to insert a `chmod -R +w $out` in there
<clever> Shell: and that will fix it ^
<clever> infinisil: ahh, yeah
<clever> evertedsphere: yep, just assign it to some attr
<clever> evertedsphere: pkgs.runCommand "scripts" {} "mkdir $out ; cp -r ${../scripts} $out/bin ; patchShebangs $out/bin"
<clever> evertedsphere: paths are copied automatically, you can just do maschinen-scripts = ../scripts;
<clever> evertedsphere: `patchShebangs $out/bin` will patch everything in $out/bin
<clever> yes
<clever> evertedsphere: then do `f "foo" ./foo.sh`
<clever> evertedsphere: f = name: path: pkgs.runCommand name {} mkdir -pv $out/bin ; cp ${path} $out/bin/${name} ; patchShebangs $out/bin'';
<clever> evertedsphere: or you can write a nix function, that takes the name of something, and calls runCommand, inserting ${something}s everywhere
<clever> evertedsphere: you can copy several scripts in a single runCommand
<clever> evertedsphere: mkdir -pv $out/bin ; cp ${./foo.sh} $out/bin/foo ; patchShebangs $out/bin
<clever> evertedsphere: pkgs.runCommand "name" { buildInputs = []; } ''
<clever> patchShebangs will look for anything using env, and patch them to use an absolute path instead
<clever> evertedsphere: you can also use `#!/usr/bin/env bash` and then run patchShebangs
<clever> evertedsphere: and now its a #!
<clever> > "#!${stdenv.shell}"
<clever> > stdenv.shell
<clever> vika_nezrimaya: this also exists
<clever> > stdenv.shell
<clever> evertedsphere: which makes no sense at all, your running env on a dir
<clever> evertedsphere: that would turn into `#!/usr/bin/env /nix/store/hash-bash/`
<clever> evertedsphere: nix will automatically download foo for you
<clever> evertedsphere: i would just import the default.nix properly, and let it build when you nixos-rebuild
<clever> evertedsphere: whenever all of the tests in https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents go green
<clever> asbachb: and it does look like its also a very new failure, it wasnt in any of the previous fails, tarball used to be green
<clever> basically, it was the fastest thing to fail, 2 other failures are still pending a retry
<clever> asbachb: it may not be the problem that has been going for the last 8 days, but it is one of the problems in the latest eval
<clever> evaluation aborted with the following error message: 'Illegal use of <nixpkgs> in Nixpkgs.'
<clever> vika_nezrimaya: so no user will actually see k3s!
<clever> vika_nezrimaya: k3s entirely broke all unstable channels
<clever> you can also get small 1 line changes, that entirely grind a channel to a halt
<clever> arianvp: you can always manually run the nix-daemon after you install it
<clever> Shell: that would be the problem
<clever> with import <nixpkgs> {};
<clever> wut??
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ head pkgs/applications/networking/cluster/k3s/default.nix
<clever> evaluation aborted with the following error message: 'Illegal use of <nixpkgs> in Nixpkgs.'
<clever> error: while querying the derivation named 'k3s':
<clever> Shell: click on the `hydra job for tests` for unstable, under https://status.nixos.org/
<clever> morgrimm: cp is part of the stdenv, and will always be available
<clever> morgrimm: propogatedBuildInputs only works right if you run the fixupPhase, buildInputs works normally
<clever> morgrimm: yeah
<clever> learnday20: add `./xmonad.nix` to the imports list, and nixos will merge it in for you
<clever> morgrimm: here, i use runCommand, i set patches, and then i run patchPhase to apply everything in patches
<clever> morgrimm: and it can still run phases as well
<clever> morgrimm: the attrset that runCommand takes, can accept meta and other stuff
<clever> learnday20: line 163, `with lib;` is not a `key = expression;` pair
<clever> learnday20: line 7 is the start of an attribute set, which must only contain `key = expression;` pairs
<clever> learnday20: yep, line 163 is the problem
<clever> learnday20: is the pastebin xmonad.nix or configuration.nix ?
<clever> learnday20: the error says you have a problem on line 163, but that pastebin is only 95 lines long, where is 163?
<clever> learnday20: can you put the whole file into a pastebin, its hard to see what exactly is wrong here
<clever> munksgaard: patchelf --set-rpath ${gmp}/lib, will have nix build gmp, and insert the path for you
<clever> munksgaard: you can already build things in the shellHook
<clever> munksgaard: i would just just run nix-build outside of the nix-shell
<clever> chloekek: yeah, then youll want to delete the channels after the install is done, though, nix itself must be in roots profile, or nix will try to delete nix
<clever> learnday20: what is the code around line 163?
<clever> morgrimm: i think there is stuff in place, to take a requirements.txt and auto-generate the nix to do that
<clever> chloekek: the problem, is that nix needs to modify the $HOME for a non-root user, and things may start to malfunction down the road if you bypass it
<clever> morgrimm: do it!
<clever> jluttine: yeah, i would use `nix-shell -p ghc cabal-install` for that first run
<clever> yourfate: yeah
<clever> jluttine: `cabal init` can automate that i believe
<clever> jluttine: lines 5 and 6 load a machotool.cabal and a macho.cabal into nix, then you can just `nix-build -A machotool` to build it, or `nix-shell -A machotool.env` to get a shell with the deps
<clever> yourfate: my prefered method is to point `services.nginx.virtualHosts.<name>.root` to a derivation, probably pkgs.runCommand, so everything is in the nix store
<clever> munksgaard: this one is a bit complex, but the selected area will run `yarn install`, then overwrite several of the pre-compiled binaries with symlinks to pre-patched ones nix provides
<clever> munksgaard: you may also want to use a shell.nix file with a shellHook, to patch things, since youll need to repeat that every time npm re-downloads the binary
<clever> munksgaard: when ran like that, nix will default to the same arch that nix-build itself was compiled with
<clever> munksgaard: ask nix for it, `nix-build '<nixpkgs>' -A gmp`
<clever> munksgaard: file confirms that
<clever> /nix/store/h5j89q8sf64079zgwqg4fqmw7hfzq43z-gmp-6.2.0/lib/libgmp.so.10.4.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
<clever> munksgaard: you gave it a 32bit gmp, not a 64bit gmp
<clever> munksgaard: so, you want to add `--set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker)` to the cmd
<clever> munksgaard: this env var tells you where it is
<clever> $ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/qb6k4hp7gk331x9fydw0w7qj4dv09bwz-glibc-2.27/lib/ld-linux-x86-64.so.2
<clever> munksgaard: you must also fix the interpreter, again with patchelf
<clever> munksgaard: what does `file /path/to/elm-format` report?
<clever> munksgaard: its already in the DT_NEEDED field, you must set the rpath
<clever> munksgaard: youll need to patchelf the binary after npm downloads it
<clever> munksgaard: is npm building elm-format, or downloading a pre-made .so file?
<clever> jluttine: i also prefer doing everything with a shell.nix, and just ignore nix-env
<clever> jluttine: the haskell stuff would be in the nixpkgs docs, not the nixos docs
<clever> jluttine: you want cabal-install
<clever> jluttine: haskellPackages.cabal is the cabal library, not the cabal binary
<clever> jluttine: this for example, returns a set containing all haskell packages, plus 2 extra
<clever> jluttine: use pkgs.haskellPackages.callCabal2nix and plain old `cabal build` (via `runHaskell Setup.hs build`)
<clever> jluttine: personally, i just avoid stack and `cabal new-build` like the modern plague :P
<clever> morgrimm: the nixpkgs manual should explain the phases better
<clever> morgrimm: which will make your job a lot harder
<clever> morgrimm: setting the builder like that, means buildInputs and a lot of other things wont actually work
<clever> morgrimm: installPhase for ex
<clever> morgrimm: you almost always want to use either a phase, or buildCommand (runCommand uses buildCommand for you)

2020-04-04

<clever> ornxka: you can even swap in aarch64-linux or x86_64-darwin, to see what it would need for those platforms
<clever> ornxka: nix-build --dry-run '<nixpkgs>' -A hello --argstr system i686-linux
<clever> ornxka: nix.buildMachines in the nixos manual
<clever> nix manual explains most of it, nixos then has a config option to generate the cfg for you
<clever> both nix and nixos manuals
<clever> mudri: but, the files your copying, may refer to the original $dev, not the new $dev
<clever> mudri: and then just make sure to populate both $out and $dev
<clever> mudri: by default, it has only 1 output, but you can do `runCommand "name" { outputs = [ "out" "dev" ]; }` like any other derivation
<clever> __monty__: ive seen people putting haskell type signatures in comments, but its purely just to help the user understand things, nix ignores it all
<clever> mudri: the changes your doing must still be pure, but you wont have to recompile, so you can iterate faster
<clever> mudri: that makes a new package, which will copy an old package, then overwrite one file
<clever> mudri: something like: pkgs.runCommand "name" {} "cp -vir ${oldPkg} $out; cp ${./foo} $out/bin/foo"
<clever> mudri: you can also use pkgs.runCommand
<clever> [ ({ original = pkgs.openssl; replacement = pkgs.callPackage /path/to/openssl { }; }) ]
<clever> Example:
<clever> List of packages to override without doing a full rebuild. The original derivation and replacement derivation must have the same name length, and ideally should have close-to-identical directory layout.