2019-04-27

<clever> its just harder in nixos
<clever> nix-env --profile /path --rollback, will then undo it
<clever> both of those will set the current generation to a given storepath (creating a new generation if needed)
<clever> nix-env --profile /path --set /nix/store/foo and nix-env -f foo.nix -A foo --set --profile /path
<clever> nix-env --set and --rollback
<clever> ambro718: cant find the link, but i saw somebody saying to get rid of nix-env -i/-e, but to keep nix-env itself
<clever> ambro718: one min
<clever> ambro718: you may be able to get similar using the outputsToInstall entry, and split outputs
<clever> you would need to patch both the perl version to update systemPackages handling, and then patch the c++ version to fix nix-env, and the c++ one wont go public until the next nix release
<clever> that will just replace the entire profile with the given path, no buildEnv involved
<clever> basically, nix-env --profile /foo --set /nix/store/bar
<clever> but its not using -i, rather, its using --set
<clever> nixos-rebuild also uses nix-env
<clever> so the perl one is only used by systemPackages, and when you call pkgs.buildEnv directly
<clever> the builtin one still
<clever> nix-channel is just a wrapper to download the packages and "install" a channel to the profile
<clever> ambro718: its a normal nix-env profile, with generations, -i/-e support, and everything else
<clever> [root@system76:~]# nix-env --profile /nix/var/nix/profiles/per-user/root/channels --list-generations
<clever> [root@system76:~]# nix-env --profile /nix/var/nix/profiles/per-user/root/channels -q
<clever> behind the scenes, nix-channel runs nix-env -i -E "..." to install a channel into the channels profile
<clever> ambro718: because nix-channel needs it, before nixpkgs has been downloaded
<clever> ambro718: yeah
<clever> ambro718: pkgs.buildEnv is still the perl based one, only nix-env -i and nix-env -e uses the builtin buildenv
<clever> ambro718: nix-env itself then uses a duplicate buildenv to manage merging everything in the profile
<clever> ambro718: behind the scenes, nix-channel will just run nix-env -iE "...." to install a channel to the channels profile
<clever> but now its a builtin builder
<clever> then it was a c++ binary that was shipped with nix-env
<clever> originally, it was a copy of buildenv.pl
<clever> nix-env has a buildEnv baked into it, for nix-channel to use when downloading nixpkgs
<clever> ambro718: one min
<clever> memory usage will also be the same as a normal install
<clever> trfl: most of the time, you can just treat the usb stick like an internal hdd, partition, format, mount to /mnt, nixos-generate-config --root /mnt, nixos-install
<clever> which will add it to PATH, and give you the host version
<clever> ambro718: there is also nativeBuildInputs = [ pkgconfig ];
<clever> softinio: i think all of the optional things will be available by default, you would have to use .override to set them to null, to remove them
<clever> ambro718: runCommand "name" {} ''mkdir -pv $out/bin ; gcc ${./foo.c} -o $out/bin/foo''
<clever> neat
<clever> sphalerite: postFixup = "sed" ?
<clever> symphorien: nix sign-paths --help
<clever> /generate
<clever> symphorien: man nix-store
<clever> remote needs a secret key, local needs to trust that key (via the public)
<clever> did you setup secret-key-files like i said above?
<clever> having it as a substituter, would let the local nix know that the deps arent needed, and just fetch it directly
<clever> i have to rebuild it on a box that doesnt break things, then use --repair-path and --option substutiters to overwrite the broken one
<clever> which becomes a problem when an aarch64 poisons your cache with broken builds :P
<clever> it will copy the deps to the remote machine, then "instantly" build it, and copy the product back
<clever> gchristensen: that wont help if you decide to build something on X, but Y has a copy already built
<clever> that configures amd to sign things automatically
<clever> symphorien: [root@amd-nixos:~]$ nix show-config | grep secret
<clever> secret-key-files = /etc/nix/signing.sec
<clever> symphorien: you need to configure the remote end to sign things, and the local end to trust its keys
<clever> nh2: previously, i just used kexec -e, and i didnt plan on running the entire system from that env
<clever> weird
<clever> nh2: havent seen that before
<clever> then saves that new value as import
<clever> this creates an empty value, creates an empty set, then stores the application of the set onto scopedImport in the new value
<clever> which is why it says primop-app
<clever> infinisil: and behind the scenes, its actually import = scopedImport {}

2019-04-26

<clever> override works by saving the original args to callPackage, and same ting
<clever> overrideAttrs works by saving the original arguments to stdenv.mkDerivation, and calling it again after mutating them
<clever> overrideDerivation works by saving the original arguments to builtins.derivation, and calling it again after mutating them
<clever> correction
<clever> overrideAttrs works by saving the original arguments to builtins.derivation, and calling it again after mutating them
<clever> a/b are already computed, and wont be changed by things
<clever> thats basically { drvPath = a; outPath = b; } // { things = morethings; }
<clever> changing a, didnt change c, because c depends on the old a
<clever> > :p rec { a=1; b=2; c = a+b; } // { a = 42; }
<clever> > rec { a=1; b=2; c = a+b; } // { a = 42; }
<clever> ambro718: the // is just adding things to the attrset, the .outPath is based on the original arguments to builtins.derivation, which are unchanged
<clever> ambro718: this removes the type, causing nix repl to just expose all the details
<clever> > coreutils // { type = null; }
<clever> > coreutils.type
<clever> ambro718: derivations are just sets with an outPath
<clever> avn: any attribute set with a .outPath attr, can be cast to a string
<clever> > let x = { outPath = "foo"; } // { a=42; }; in "${x}"
<clever> > { outPath = "foo"; } // { a=42; }
<clever> i suspect it will even work when X isnt running (plain text mode)
<clever> this works for adjusting my screen brightness
<clever> [root@system76:/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight]# echo 100 > brightness
<clever> its also in /sys
<clever> this lets you nix-env -iA foo.hello
<clever> $ cat ~/.nix-defexpr/test/foo/default.nix
<clever> import /home/clever/apps/nixpkgs
<clever> xorAxAx: yes
<clever> tdeo: it checks both
<clever> tdeo: yeah, that might just work, it may not even need a reboot
<clever> > linuxPackages.acpi_call
<clever> aquarial: and if you `sudo modprobe acpi-call` ?
<clever> not-os is more of an overlay then a fork, it just uses bits of nixpkgs to create a bootable image, thats not nixos
<clever> so if you --include a lot, you need to go backwards thru profiles to piece together the full state
<clever> sadly, if you deploy with --include, the new generation will be partial
<clever> infinisil: within that profile, will be symlinks for each machine
<clever> a lot of build systems need a load detecting -j
<clever> infinisil: if you try to build 2 copies of X, with difference ghcs, then they dont have any deps in common, so building both versions at once lets it meet your -j even when they hit bottlenecks and both stall on 1 thing

2019-04-25

<clever> stepcut_: you can test it with `ssh user@host nix-store --version`
<clever> stepcut_: thats a common problem when ssh'ing into a remote machine
<clever> stepcut_: if you `strace -p <pid> -f -e execve` on the pid of the queue-runner, what commands is it starting?
<clever> stepcut_: localhost has a special case, dont rmember the exact rules
<clever> stepcut_: does the hydra have build slaves?
<clever> callPackage ./foo { inherit (lib) bar; }; but thats yucky :P
<clever> pie_: let inherit (lib) foo; in ...
<clever> Shouou: -A gives a shell suitable for building something, rather then using it, so that could be the issue
<clever> everything ive checked says it needs the file to be a single extent on disk, which most FS's dont do
<clever> you may want to look into how ubuntu made it work then, what command was it running from the initrd?
<clever> sindrip1: i dont think hibernation works with swap files
<clever> but 2 different sets of directions can produce the same file
<clever> kandinski: the hash of $out is the hash over the build directions (and app deps's build directions)
<clever> NemesisD: yep
<clever> its only a build-time thing, for other things that depend on X
<clever> propagatedBuildInputs doesnt even affect nix-env

2019-04-24

<clever> joebobjoe: how did you previously upgrade?
<clever> pie_: windows loads dlls from PATH, the dir of the exe, and the current dir, dont remember the exact order
<clever> sphalerite: yeah
<clever> andi-: non-root users can now manage the same cache, in their own home
<clever> andi-: you can just blow the cache away with rm, nix will remake the DB's
<clever> andi-: ~/.cache/nix/binary-cache-v* as root
<clever> ambro718: yes
<clever> parsnip: that gets ran after creating /nix/store/hash-system-path/, and updates any indexes within it, which then lands at /run/current-system/sw/
<clever> ambro718: systemd provides udev, and a lot of graphical stuff ties into udev to detect what gpu you have
<clever> systemPackages does
<clever> nix-env doesnt support generating any special index after merging all packages into one dir
<clever> parsnip: create a derivation that contains a $out/share/info, and then install it with nix-env -i
<clever> pie_: its more an issue of if the build succeeds, but did rng, so each user gets something diff
<clever> simpson: then i realized, the build will never finish :P
<clever> simpson: my initial thought, is what is the chance of pure random bytes being a valid ELF file
<clever> simpson: 0%, the cat will never end, until you run out of disk space :P
<clever> simpson: what are the chances it will build a working executable? :D
<clever> simpson: cat /dev/urandom > $out/bin/foo
<clever> tilpner: thats for graphical editors
<clever> yeah, that makes sense
<clever> slabity: yeah, im surprised its missing
<clever> ambro718: i think having yum target a chroot dir is the only meaningfull way yum can work on nixos
<clever> ,locate bin/yum
<clever> > yum.meta.description
<clever> slabity: the result wont work right until you somehow map /mnt/ to /, via either chroot, containers, or booting it as /
<clever> slabity: nix-copy-closure --to local?root=/mnt/ /nix/store/foo, lets you copy things to /mnt/nix/store/, including the entire closure
<clever> nixos-container is just a wrapper arround systemd-nspawn
<clever> azazel: did you use fonts.fonts ?
<clever> exarkun: probably written with MBR in mind
<clever> pie_: hardware.opengl.driSupport32Bit
<clever> gchristensen: still cant repro...
<clever> > :p lib.fix (self: { foo = map (x: self.${x}) [ "foo"]; })
<clever> > :p lib.fix (self: { foo = map lib.id self.foo; })
<clever> > lib.fix (self: { foo = map lib.id self.foo; })
<clever> yeah
<clever> --show-trace should still help
<clever> and the error itself, is thrown by a black-hole, so c++ tried to eval a thunk from its own call stack
<clever> gchristensen: undefined position usually means c++ calling back into nix
<clever> pie_: ah, thats more difficult
<clever> pie_: extraPostFetch?
<clever> Orbstheorem: wrapProgram and/or makeWrapper
<clever> which should align to path-info
<clever> du has a --aparrent-size
<clever> zfs compression?
<clever> infinisil: mine depends on clang via youcompleteme
<clever> yuken: thats why it cant find them
<clever> yuken: did you open a nix-shell with the right libraries in its arguments?
<clever> yeah, thats the one
<clever> ,libraries yuken
<clever> ah, might have been ,libraries
<clever> ,nix-shell yuken
<clever> matthewbauer: nice

2019-04-23

<clever> pie_: the chain of errors when a build fails tells you what needed it

2019-04-22

<clever> gchristensen: false means the nixops->target is "slower" then cache->target
<clever> gchristensen: true means that the link between nixops and target is "fast", dont try to use a binary cache on the slow uplink
<clever> ah, per-machine, not deployment wide
<clever> gchristensen: https://nixos.org/nixops/manual/#opt-deployment.hasFastConnection
<clever> gchristensen: that is a deployment wide option i think, something about fast connection
<clever> gchristensen: that also means that a copy will initially hang and not say what its copying, because the remote machine is checking the binary cache, to see what has to copy
<clever> gchristensen: if you use --use-substitutes, the remote machine will check its own cache settings
<clever> :D
<clever> tofu only works if the first hash is invalid
<clever> yeah, i set my editor to replace mode, and then replace a few digits with 0's
<clever> lordcirth: if you leave the sha256 the same, thats claiming that the src is unchanged, so nix uses the old src

2019-04-21

<clever> xorAxAx: the GC will never delete something that is currently in use
<clever> having 2 channels may double the usgae
<clever> xorAxAx: -vvvvv
<clever> xorAxAx: you may have infinite recursion in our expr
<clever> its a bug within nixos-rebuild
<clever> you can safely ignore that error
<clever> thats because it doesnt exist when nixos-rebuild is building nix, only nixos
<clever> sindrip: its in qemu-vm.nix, which is only included when you run build-vm
<clever> sindrip: so its missing from the normal docs
<clever> Orbstheorem: simpler to make it a list of sets, then map ({ a, b }: a * b)
<clever> Orbstheorem: that work?
<clever> > builtins.foldl' (a: b: a // b) {} [ {a=1;} {b=2;} {c=3;} ]
<clever> Orbstheorem: one min...
<clever> > :p [ {a=1;} {b=2;} {c=3;} ]
<clever> sindrip: `virtualisation.memorySize = 2048;` add that to the configuration.nix
<clever> sindrip: within the guest, how does ram usage look?, `free -m`, what about cpu? `top`
<clever> then it should be running as fast as the hardware allows
<clever> group doesnt matter much if the last part is +rw
<clever> while the vm is running, check `ps aux | grep qemu`, and look for a `-enable-kvm` in its args
<clever> then it should automtically use kvm and run faster
<clever> mine is 666
<clever> crw-rw-rw- 1 root kvm 10, 232 Apr 12 08:32 /dev/kvm
<clever> [root@system76:~]# ls -l /dev/kvm
<clever> and what are the permissions on it?
<clever> yeah
<clever> sindrip: does /dev/kvm exist?
<clever> lionello: depends on what your doing, you can sometimes use unpackPhase in runCommand, but mkDerivation is usually what you want
<clever> but if you use stdenv and src=, it will copy that to . and make it writable, and then it will just work
<clever> lionello: i think your problem is that you are trying to build directly from the fetchgit output, which is read-onl
<clever> lionello: yeah
<clever> lionello: patches goes into the stdenv.mkDerivation of anthing with a src=
<clever> lionello: you can still use the patches array to apply patches
<clever> and you could mix methods
<clever> infinisil: yeah, which method you use depends heavily on what type of fault you want to recover from
<clever> i have seen somebody brick the machine by doing network in the activtions scripts, so systemd never ran
<clever> grub runs linux, linux then runs stage-1 in the initrd, stage-1 then runs stage-2, and stage-2 runs systemd AFTER the activation scripts
<clever> infinisil: ah, that only works if the machine is still online, and can rollback itself
<clever> it would also be more flexible and you could program in custom rollback logic
<clever> then you can ssh in and choose an option
<clever> one idea ive wanted to work on, is to replace the boot menu, with a custom kernel+initrd pair, that brings up sshd, and waits 15 seconds
<clever> yeah, you would need some watchdog thing to verify its 100% working, before claiming so in grub
<clever> X-1 could then also flag X-1-1 as the default (within grub)
<clever> if things go wrong, and you somehow reboot the machine, it will boot X-1 instead
<clever> then when X comes online fully, it modifies grubenv to make X the default again
<clever> the idea, would be to modify the default entry, so when booting generation X, it flags X-1 as the default
<clever> reading grub.cfg, i can see that it loads the grubenv file, and there is a comment explaining grub-reboot
<clever> infinisil: untested, but grub has options to change the default entry both at grub-time and normal runtime
<clever> so the documentation just goes away, without having to edit any packages
<clever> setting documentation.man.enable = false;, means systemPackages wont include the $man output from packages
<clever> split output stuff allows for magic like this
<clever> the `getBin pkg` you pasted above, will read .bin if it exiss, and .out if bin is missing
<clever> executables in $out or $bin, depending on preference
<clever> dynamic libs can either be in $out or $lib, depending on your preference
<clever> so dev can depend on out, but then out cant depend back on dev
<clever> the outputs can depend on eachother, but no cycles allowed
<clever> (and add it to outputs)
<clever> dev stuff could be in $dev if you want that
<clever> then you must put files into `$out` and `$man` when in the installPhase
<clever> in your derivation, you can set `outputs = [ "out" "man" ];`
<clever> is it in nixpkgs, or a custom one?
<clever> the nix expression for the package has to be modified
<clever> or the -man output
<clever> (and it if doesnt, create one)
<clever> man pages should be in the -doc output, if it has one
<clever> aha
<clever> why does foo depend on bar?
<clever> nix why-depends /nix/store/foo /nix/store/bar
<clever> lionello: it also works with raw storepaths
<clever> yep
<clever> what does check say?
<clever> only shell.nix needs .nv
<clever> default.nix shouldnt use .env, that will break nix-build
<clever> ghc-pkg list | grep -i cabal
<clever> what does `type ghc` return?
<clever> are you in the .env shell?
<clever> what about `runhaskell Setup.hs build` and then test?
<clever> because your not supposed to be building your own deps
<clever> and then that fails, because nix-shell didnt provide the deps of your deps
<clever> they tend to ignore the versions nix provides, download their own source, and build things directly
<clever> Alling: the cabal new- family of commands have issues under nix
<clever> but the haskell.nix stuff still needs some things ironed one, recently found that nix-shell support isnt working at all
<clever> __monty__: we are currently switching over from stack2nix to haskell.nix, since it adds cross-compile support
<clever> Alling: foo = haskellPackages.callCabal2nix "name" ./name {};
<clever> Alling: if you refer to the .env of a cabal2nix'd derivation, you basically dont need developPackage
<clever> and if you use nix-shell, add a .env at the env
<clever> Alling: basically all developPackage does, is run callCabal2nix for you!
<clever> ive not used developPackage before
<clever> you can also use overrides in the nix file to force a version for just one thing
<clever> the ghc version will be cached, but it will likely have to rebuild eveyr single haskell package
<clever> Alling: if you want nix to respect the version bounds, then you need something like stack2nix, and then youll have to recompile nearly all haskell packages
<clever> Alling: nixpkgs will just provide any version of hspec, so whatever is in nixpkgs
<clever> Ralith: i just run tzselect in a shell
<clever> gchristensen: --delete-older-then will delete the booted profile, but booted-system itself is a root, so it cant actually GC it after deleting the generation

2019-04-20

<clever> and it checks for more before after creating each file
<clever> xorAxAx: the min-free based GC will pause downloading things and run a GC when space gets low
<clever> it also has per-component builds, so each library, executable, and testcase, is its own derivation
<clever> cabal2nix and stack2nix cant do that
<clever> so if you only need Win32 on windows, nix will correctly only give it for windows cross-compile
<clever> it turns all conditionals in the cabal file, into nix conditionals
<clever> iohk uses it to handle cross-compiling
<clever> pie_: and #haskell.nix on irc too
<clever> pie_: yep
<clever> gchristensen: and if random maintainer C has some malware on his box...
<clever> infinisil: yeah, thats the only time you really need to validate
<clever> infinisil: my thought, is that if you know the sha256 is over something signed, the signature itself doesnt matter
<clever> heading out for lunch now
<clever> i would expect a normal build to still work
<clever> nh2: the override is only needed to make menuconfig work
<clever> that expectation breaks when using nix-shell
<clever> infinisil: unpackPhase expects nix to have already dropped things into the temp dir /build/
<clever> nh2: unpackPhase looks at the difference in `ls` before and after the unpack
<clever> nh2: you must run it in a directory that doesnt contain a linux-4.19.36 dir
<clever> y
<clever> nh2: its working normall
<clever> `make`
<clever> [nix-shell:~/linux-4.19.33]$ cat /proc/config.gz | gunzip > .config