2020-10-14

<clever> dumbuser: yay!
<clever> gluonix: installing things like gcc and make with nix-env isnt supposed to work, and will only cause problems
<clever> ,libraries gluonix
<clever> gluonix: are you building in nix-shell? or nix-build?
<clever> and rebuild the whole system from configuration.nix
<clever> dumbuser: but if you did wipe /mnt/nix, it would re-download it all from the cache, and you would only loose the `nix-env -q` list and rollbacks
<clever> dumbuser: most of the data comes from /mnt/nix/store
<clever> dumbuser: because nixos-install is just a shell script to run nixos-rebuild inside a chroot
<clever> and only gcc
<clever> but i have seen gcc segfault before, when the battery in one of my laptops got really low
<clever> not sure how it could cause that though
<clever> and i'm not into abusing hardware like that :P
<clever> which makes it rather hard to find out which socket it is, you would have to kick/drop the pc a few times for it to come loose again
<clever> dumbuser: but just pushing the ram back into the socket all the way would fix it
<clever> dumbuser: the ram socket was bad, and the ram would sometimes come a bit loose
<clever> dumbuser: then it would be fine for years, until it receives a decent amount of vibration
<clever> dumbuser: ive gotten PC's from walmart before that would bluescreen constantly until you reseat the ram
<clever> dumbuser: have you ran a memtest recently?
<clever> pumpy: yeah, its case sensitive
<clever> dumbuser: yeah, you have to give it a device and name, like `cryptsetup open --type luks /dev/sda1 rootfs`
<clever> pumpy: did you mount a filesystem to /mnt/boot/ ?
<clever> dumbuser: cryptsetup open --type luks
<clever> pumpy: try doing `sudo -i` first
<clever> pumpy: thats just how bash and sudo work
<clever> pumpy: sudo doesnt affect >
<clever> dumbuser: if you mount your disk to /mnt, that will be your orignal config files
<clever> dumbuser: nope, nixos-install will use whatever is in /mnt/etc/nixos/
<clever> dumbuser: luksopen the device, mount it back to /mnt, and then nixos-install will rebuild it for you
<clever> dumbuser: nixos-install is just a script to run nixos-rebuild in a chroot for you
<clever> dumbuser: nope, just dont run any format commands
<clever> dumbuser: luksopen, same as when you first installed it
<clever> dumbuser: since you GC'd, there may be no simple way to undo things, the next simplest option is to just boot the installer again, mount your filesystems under /mnt like when installing, and re-run nixos-install, to rebuild it from a working system
<clever> dumbuser: it also needs --check-contents
<clever> dumbuser: try doing a `nix-store --verify --check-contents`
<clever> dumbuser: thats weird for even bash to be segfaulting
<clever> dumbuser: what does `coredumpctl | tail` say?
<clever> dumbuser: what error does nixos-rebuild give?
<clever> gluonix: not easily, since its basically just a hash of the input
<clever> dumbuser: you can also just pick an older version from the grub menu
<clever> dumbuser: nixos-rebuild --rollback will undo whatever you did last
<clever> dumbuser: just change the nix-channel back to 20.03, same way you changed it to 20.09

2020-10-13

<clever> nicolas[m]: the datadog package fails because the tests want apikeys, callHackage will re-create a duplicate of the package that is non-broken, then dontCheck fixes it
<clever> polytux: i think firefox ignores the list on the host, and uses its own internal list
<clever> > "/etc/nixos/spindeltax-ca.pem"
<clever> > "${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt"
<clever> but if its quoted and not a derivation, the sandbox will block acces to the file
<clever> polytux: "${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt" is already in /nix/store, so it still works
<clever> polytux: unquoted, its a path, so nix will copy it to /nix/store/ at eval time
<clever> polytux: try unquoted
<clever> polytux: is the path quoted or unquoted?
<clever> amercan: nope, they are still there, but only outside the sandbox
<clever> siraben: yeah, just pass that fetchFromGitHub to callCabal2nix instead, and you should be done
<clever> you can aim fetchFromGitHub to the branch
<clever> you can even just tell it "go fetch it yourself", self.callHackageDirect
<clever> haskell-language-server = self.callCabal2nix "haskell-language-server" (fetchzip { ... }) {}
<clever> siraben: you can give it a derivation too
<clever> siraben: then nix will auto-generate a new derivation from scratch, based on what the .cabal file wants
<clever> siraben: it can sometimes be simpler to just do `haskell-language-server = self.callCabal2nix "haskell-language-server" /path/to/src {};`
<clever> yeah
<clever> haskellPackages.mkDerivation is just a wrapper around stdenv.mkDerivation, that does some extra stuff to help haskell out
<clever> siraben: while overrideAttrs mutates the args going into stdenv.mkDerivation, after haskellPackages.mkDerivation has done some mutations
<clever> siraben: basically, overrideCabal lets you mutate the args that are going into the haskellPackages.mkDerivation function
<clever> siraben: lib.haskell.overrideCabal
<clever> to make it load that library, without a rebuild
<clever> you can use LD_LIBRARY_PATH to force the other stuff to look in a certain directory first
<clever> then you can just do the standard edit, make, ./run cycle
<clever> chpatrick: if you want to debug things, you want to instead build it interactively under nix-shell
<clever> chpatrick: nix strips all debug info by default
<clever> chpatrick: why do you need ccache in that package?
<clever> chpatrick: ccache cant function at all when using the sandbox

2020-10-12

<clever> it started when the default ghc updated a few months back
<clever> __monty__: does pandoc still function for you on master? i recently found problems where it blows the haskell heap, no matter how big you make it
<clever> noonien: symlinks kind of mess with the ./foo logic in nix, it can wind up being relative to the wrong dir
<clever> noonien: you can also create a dummy configuration.nix with just `{ imports = [ /path/to/real/configuration.nix ]; }`
<clever> noonien: or use `nixos-rebuild switch -I nixos-config=/anywhere/you/want.nix` to just force it
<clever> noonien: so you can use nix.nixPath to point it anywhere you want
<clever> noonien: which defaults to /etc/nixos/configuration.nix
<clever> [clever@amd-nixos:~]$ echo $NIX_PATH
<clever> /home/clever/.nix-defexpr/channels:nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
<clever> noonien: by default, nixos-rebuild will try to load <nixos-config> from $NIX_PATH
<clever> the tarball, is to let you skip installing nix on the target, because your going to format it anyways
<clever> and you can nix-copy-closure it to wherever, and then just run it
<clever> then result will point to the final symlink, already in /nix/store
<clever> noonien: instead of building kexec_tarball, you build kexec_script
<clever> { object = config.system.build.kexec_script; symlink = "/kexec_nixos"; }
<clever> system.build.kexec_tarball = pkgs.callPackage <nixpkgs/nixos/lib/make-system-tarball.nix> {
<clever> noonien: oh, if your on nix, you dont want to create the tarball
<clever> noonien: possibly
<clever> rnhmjoj: thats more for building things on a remote machine, rather then just checking if it already has a built copy
<clever> zanc: the nix-daemon on that machine, is what did `ssh user@hostname` as root
<clever> zanc: on the machine where you ran `nix-env -i --substituters ssh://user@hostname`
<clever> zanc: put a private key in /root/.ssh/id_rsa, that lacks a password, and can get into user@hostname
<clever> zanc: nix-copy-closure ssh's from the current user, but `--substituters` will try to ssh from root, via the nix-daemon, which lacks your $SSH_AUTH_SOCK
<clever> yeah
<clever> eyJhb: if you go to the inputs tab on the build i linked, youll find a nixpkgs rev
<clever> eyJhb: did you test on the same rev of nixpkgs as hydra did?
<clever> eyJhb: nix-build '<nixpkgs/nixos/relese.nix>' -A nixos.manual.x86_64-linux
<clever> eyJhb: the `nixos.manual.x86_64-linux` in the job name, is the attribute path, within nixos/release.nix
<clever> eyJhb: first, go to the consituets tam, and find the job for just that
<clever> and not try to patch the existing file
<clever> i would just use systemd.services.foo.script
<clever> is it in a #! line?
<clever> so when your cross-compiling, you get the right one
<clever> this should always be a shell for the target
<clever> > pkgs.runtimeShell
<clever> so you can just pull up the hydra job for that branch, and look at how many jobs are pending vs complete
<clever> lightandlight: everything hydra builds is pushed to cache.nixos.org once the build finishes
<clever> zecnate: builtins.path { path = ./.; filter = ...; name = "anything"; }; is a variant of filterSource, that lets you rename
<clever> start with nothing, what fails? no Makefile/configure, add them, repeat
<clever> i tend to write my whitelist by following the errors
<clever> zecnate: this one is using a strict whitelist instead of blacklist, but it should still serve as a good example
<clever> i do have a more complex filter handy...
<clever> zecnate: throwing a `toString` on line 7 might fix it, but there should be cleaner ways, check the src of cleanSource
<clever> zecnate: and then your comparing the path to the original, and the path to the copy, which will never match
<clever> zecnate: lines 7-12 will create nix paths, which will then try to copy the entire .git into /nix/store
<clever> zecnate: and did you try lib.cleanSource ?
<clever> zecnate: what expr did you use?
<clever> aminechikhaoui: line 16 copies the output of a fetcher (in this case, one more like fetchzip), and then 19 applies the patches on 14
<clever> aminechikhaoui: one minute

2020-10-11

<clever> evalexpr: you need `_NIXOS_REBUILD_REEXEC=1` to let nixos-rebuild use the nix in $PATH
<clever> > pkgs.dtc
<clever> evalexpr: try using `_NIXOS_REBUILD_REEXEC=1 nixos-rebuild`
<clever> evalexpr: that might be the problem then
<clever> evalexpr: did you set nix.package in configuration.nix?
<clever> evalexpr: what does `which nix` say?
<clever> evalexpr: sounds like the nix binary in $PATH and/or nix.package is too old
<clever> octe: you can use nix-channel to change the current channel on the livecd
<clever> selfsymmetric: and `man nix-env` also shows the rollback arg
<clever> selfsymmetric: nix-env --profile /nix/var/nix/profiles/system --list-generations
<clever> it should list them, even if its just an env var
<clever> cinimod: run `nix-store --query --roots` on a given path, to see if its got roots or not
<clever> cinimod: it should be scanning /proc/*/environ to peek at env vars for every proc
<clever> cinimod: it shouldnt do that
<clever> zangi: xorg.overrideScope (xself: xsuper: { libX11 = xsuper.override ...; })
<clever> sometimes the GPU wont survive a kexec though, so youll need ssh to continue it
<clever> noonien: and this one lets you just reboot into the iso directly
<clever> noonien: this one basically just puts the entire ISO into /boot, and adds it to grub
<clever> noonien: thats where my kexec and recovery tools can help
<clever> cc3: nixos doesnt save that directory by default, so your only option is to use nix-diff to compare the drv files

2020-10-10

<clever> sid`: nix-prefetch-url can take a file:/// url
<clever> siraben: but nix doesnt have that problem, so just use $out/lib
<clever> siraben: they do that mess because /usr/lib is taken by host libraries
<clever> should be a simple matter to just look at the vc4 and avr examples, and see where 32 vs 16 shows up, and then insert some 8's instead
<clever> depends on whats in that dir
<clever> sometimes 24bit
<clever> siraben: the AVR toolchain is 16bit and sometimes 8bit
<clever> nix will generate a unique $out for that derivation
<clever> siraben: libraries must always be installed to $out/lib by a nix derivation
<clever> siraben: step 2, define a cross derivation, and let nix do its magic: https://github.com/cleverca22/thermostat_firmware/blob/master/default.nix
<clever> step 1: add the toolchain: https://github.com/NixOS/nixpkgs/pull/72657
<clever> and if you put that library in your buildInputs, it will just be compiled, like any other library would be under nix
<clever> you can use pkgsCross to just magically compile any library to z80
<clever> > pkgsCross.armv7l-hf-multiplatform.hello
<clever> to have it properly integrate into the cross-compile framework, it will be
<clever> siraben: ah, z80 isnt in nixpkgs yet, youll need to port the toolchain over first
<clever> what cpu is it for?
<clever> then things behave the same way for both host and cross
<clever> siraben: $out/lib for libraries, and use the cross-compile system in nixpkgs
<clever> siraben: nope, that dir doesnt even exist
<clever> systemd.services.foo.Environment.NIX_GHC = drv.NIX_GHC;
<clever> 2020-10-10 00:55:00 < clever> fresheyeball: find the vars that matter, and set them with systemd.services.foo.Environment
<clever> nix-shell isnt meant to be used like that
<clever> fresheyeball: those vars are all attributes on the derivation
<clever> correct
<clever> fresheyeball: find the vars that matter, and set them with systemd.services.foo.Environment
<clever> fresheyeball: nix-instantiate, nix-store -qR, nix-store -q --tree
<clever> fresheyeball: nix show-derivation on the .drv file
<clever> addcn: you want `nix-shell -p libusb1` to use it
<clever> addcn: `nix-shell '<nixpkgs>' -A libusb1` gives you a shell suitable for building libusb, not using libusb
<clever> v0|d: which package did you get lsusb from?
<clever> v0|d: lsusb for usb devices

2020-10-09

<clever> astk: add an `echo` to it temporarily, and confirm if the echo runs
<clever> exactly
<clever> astk: is it before or after any if statements?
<clever> yeah
<clever> astk: yeah, near the top
<clever> astk: you need the nix.sh line i pasted above
<clever> try editing the .bashrc on the remote machine, to set $PATH correctly
<clever> then your .bashrc needs more work
<clever> astk: you can test it with `ssh user@host nix --version`
<clever> astk: the installer tends to add it to the "wrong" file, and its only available for interactive shells
<clever> if [ -e /home/clever/.nix-profile/etc/profile.d/nix.sh ]; then . /home/clever/.nix-profile/etc/profile.d/nix.sh; fi # added by Nix installer
<clever> clever@c2d ~ $ cat .bashrc
<clever> asheshambasta: that says that you should have 2 caches in your nix.conf, one of them being there twice
<clever> asheshambasta: can you pastebin `nixos-option nix.binaryCaches ; nixos-option nix.extraOptions`?
<clever> Fuuzetsu: but you can `export NIX_REMOTE=daemon` to force it
<clever> Fuuzetsu: less overhead, it can just fork out the child workers directly, and modify /nix/store without using the RPC

2020-10-06

<clever> eyJhb: you may be able to put just /etc/NIXOS_LUSTRATE into the file, instead of a whole dir
<clever> if /etc itself was in NIXOS_LUSTRATE, then it wouldnt wipe /etc/NIXOS_LUSTRATE

2020-10-04

<clever> sphalerite: yeah, that looks like the example got encoded into json
<clever> sphalerite: on my end, the example value is proper nix
<clever> Example: [ { x = 1600; y = 1200; } { x = 1024; y = 786; } ]
<clever> dave8: sets must be key = value; pairs, not key : value,
<clever> wave goodbye to any data you might have had on there!
<clever> pjt_tmp: justdoit.nix itself, is a nixos module you would add to the ISO, then you simply boot, and run `justdoit` in a shell, and bam, /dev/sda has been wiped and installed
<clever> pjt_tmp: this script will run nixos-generate-config, then overwrite configuration.nix, and it assumes a generated.nix and hardware-configuration.nix are nearby
<clever> pjt_tmp: something like that
<clever> it will always use what configuration.nix said to install
<clever> whatever you install with `nixos-install` has no real connection to what was on the iso
<clever> pjt_tmp: anything you uninstall will just come back next time you boot from the iso, since the image is read-only

2020-10-03

<clever> Henson: i think one of these has the udev rules in it already
<clever> 30 udev.packages = [ pkgs.yubikey-personalization pkgs.libu2f-host ];
<clever> 28 services = {
<clever> just directly build and install in one step
<clever> dsal: nix-env -f yourthing.nix -iA yourthing
<clever> dsal: you can also skip a step
<clever> dsal: nix-env -i ./result

2020-10-02

<clever> jasom: not sure, id just ignore them until it gives an error
<clever> yeah, those are gc roots, and normally prevent it from deleting
<clever> which is why the whole `nixos-system-mutsumi` vanishes, and your $PATH would insta-break
<clever> jasom: nix will recursively delete anything depending on X, when you `nix-store --delete`
<clever> jasom: assuming that the system link isnt pointing to 99, you can just delete system-99-link
<clever> jasom: depends on where the root is, the --query will answer that first part
<clever> jasom: you should really use `nix-store --query --roots` to find out WHY its live, and make it non-live
<clever> jasom: `--ignore-liveness` can have crazy-bad side-effects, like $PATH now being invalid and you cant even rebot
<clever> then you dont have to worry about escaping a stray " in the string
<clever> nix will write foo to a file for you, and then $fooPath says where it got written
<clever> polarfire: passAsFile = [ "foo" ]; foo = ''big long string''; patchPhase = "cp $fooPath file";
<clever> polarfire: theres also passAsFile
<clever> polarfire: patchPhase = "shell code";
<clever> wheatdog: `nix show-config | grep sandbox`
<clever> nicolas[m]1: that one only works within a nix file
<clever> dsal: or use '<nixpkgs/nixos/release.nix>' to use the one in $NIX_PATH

2020-10-01

<clever> pikajude: what does the setup hook do? read its source
<clever> pikajude: manually `source ${foo}/nix-support/setup-hook` in some phase, but dont put it into buildInputs?
<clever> mysql does that for example
<clever> nh2[m]: so entrypoint can be a shell script to handle activation scripts, then run "$@" (what the user requested)
<clever> nh2[m]: entrypoint and cmd, basically, the command that gets ran when you start it, will be "${entrypoint} ${cmd}", and by default, the cmd you specify elsewhere replaces cmd
<clever> nh2[m]: i think it was entrypoint vs start? one of those lets you do these things
<clever> nh2[m]: grep can find it
<clever> [clever@amd-nixos:~]$ grep -r --color usr/bin/env apps/nixpkgs/nixos/
<clever> apps/nixpkgs/nixos/modules/system/activation/activation-script.nix: mv /usr/bin/.env.tmp /usr/bin/env # atomically replace /usr/bin/env
<clever> nh2[m]: its created by an activation script
<clever> ah, forgot to look into it more
<clever> siraben: there is also the kexec util i wrote

2020-09-30

<clever> its in fixup phase i think
<clever> radvendii: look at the setupHook (i think) in setup.sh
<clever> but if your refering to bintools, you dont save much
<clever> stdenvNoCC just saves you from having to copy a gcc over when building the wrapper
<clever> but you can always change it out
<clever> you may need to `inherit (stdenv.cc) bintools;` to get bintools
<clever> > stdenv.cc.bintools
<clever> radvendii: which binary are you trying to get?
<clever> radvendii: because that attribute isnt in pkgs
<clever> > pkgs.bintools
<clever> damjan: substituteAll has its own regex on what it considers a valid variable
<clever> radvendii: it will just use an env var thats in scope at the time, bash env vars
<clever> radvendii: substituteAll
<clever> gchristensen: some parts of the zfs stuff also duplicate amazon-image.nix, because ext3 and aws stuff are mixed together
<clever> gchristensen: yeah, that would be good
<clever> samueldr: but thanks to looking, i found your answer instead, lol
<clever> samueldr: that explains why i cant find it!
<clever> my pi boots directly to an htop, and i have to alt+f2 if i want a shell
<clever> numkem: correct, it replaces the login prompt
<clever> numkem: it should be possible to generate the same thing via systemd.services.htop
<clever> numkem: this is how i did something similar on a pi (non-nixos) https://gist.github.com/cleverca22/528f4a851d17444ed60ef7d609cdae6e
<clever> numkem: i skimmed the git log a bit, and couldnt find it there either
<clever> numkem: weird, i cant see how nixos is doing it...
<clever> numkem: one sec
<clever> gchristensen: MBR only having 8 bits for type codes made it rather difficult, when more then 256 filesystems came into existance, you cant give a unique id to each one anymore!
<clever> its just describing the type of the contents, not how unique it is
<clever> gchristensen: thats the same as how MBR has linux as type 0x83
<clever> gchristensen: if you try to do a legacy (non-efi) grub install onto gpt, you need a "bios boot partition"
<clever> gchristensen: part1 is "bios boot partition", part2 is "linux filesystem data" and part3 is "luks partition"
<clever> gchristensen: gpt partition type codes

2020-09-29

<clever> __monty__: i just piped it into less and search for \u, but the \ itself needs to be escaped
<clever> maurer: could just keep going backwards further?
<clever> yep
<clever> i just let the errors guide me
<clever> i keep forgetting about these things too, just look at my examples!
<clever> the `cp -r` preserves the readonly flag
<clever> maurer: chmod -R +w $out
<clever> maurer: so just doing "cp -r ${super.firmwareLinuxNonfree} $out" is enough to depend on it
<clever> maurer: nix will magically scan all strings passed to a derivation to find the deps
<clever> thats where you could put things like buildInputs, if you needed them
<clever> forgot the middle arg
<clever> maurer: oops, runCommand "name" {} "shellcode"
<clever> then you dont have to update the hash constantly
<clever> maurer: this would create a non-fixed derivation, that clones the original, then deletes things
<clever> a different way: firmwareLinuxNonfree = super.runCommand "${super.firmwareLinuxNonfree.name}-patched" "cp -r ${super.firmwareLinuxNonfree} $out ; rm ... ";
<clever> if you flip it back, it will use the old build
<clever> maurer: you must supply a new outputHash in your override, or override it a different way
<clever> maurer: its a fixed output derivation, so if nix already has a result for the given name&hash, it will never rebuild it, even when the build directions change
<clever> maurer: run `nix edit -f '<nixpkgs>' firmwareLinuxNonfree` line 20
<clever> maurer: oh, i found your problem
<clever> maurer: `nix-store --query --deriver /nix/store/v8yd6i0jly06xl0lly90i9jfc1bqdlv1-firmware-linux-nonfree-2020-05-19` ?
<clever> maurer: and also the system-170-link ?
<clever> maurer: the name of the derivation matches up too
<clever> > firmwareLinuxNonfree
<clever> maurer: what does `ls -l /run/current-system /nix/var/nix/profiles/system` report?
<clever> maurer: what does the symlink point to?