<clever>
apostolis: "${pkgs.bash}/bin/bash" is the path to bash, but there is also "${stdenv.shell}" to just get a shell
<clever>
and then import "${that_derivation}/foo.nix"
<clever>
apostolis: just write a derivation that generates nix and stores it in $out (either as a file, or a directory containing files)
<clever>
apostolis: import from derivation could be used for that, if the program is pure
<clever>
oraclejdk also doesnt work on darwin, since it just patchelf's the linux binaries
<clever>
mitchty: there are both openjdk and oraclejdk derivations
<clever>
not sure about the specifics of darwin, maybe gchristensen or #nix-darwin know more?
<clever>
mpickering: is this on darwin or linux?
<clever>
jgt: the derivation for riskbook should also be in the stack2nix output
<clever>
mpickering: was that executable built within nix, or packaged and pre-compiled?
<clever>
mpickering: the gcc wrapper does that
<clever>
jgt: and you need to add .env if you are using nix-shell
<clever>
jgt: yeah, i believe thats the best use of it
<clever>
jgt: stack2nix generates a default.nix that returns a set containing many packages
<clever>
jgt: you need to use -A to select the package you want to open a shell for
<clever>
jgt: the shell.nix file you generated contains an entire haskell packages set
<clever>
it would default to the arch that the nix building it was built for
<clever>
ben: you could
<clever>
ben: the value of imports cant depend on the value of pkgs, which heavily limits what you can do
<clever>
ij: and when those strings are passed to builtins.derivation, it uses the context to figure out what the build-time deps of the new derivation are
<clever>
ij: all strings in nix have an array of context, that tracks what storepaths and derivations the string depends on
<clever>
ij: have you seen what context is within nix?
<clever>
ij: it also adds the path as context on the string
<clever>
ij: the value filterSource creates has dependencies on the storepath, but a quoted string does not
<clever>
it might also support just a bare package name+version and hackage lookups, never tried it though
<clever>
you can give cabal2nix a git url and a git revision
<clever>
so the entire package set is affected
<clever>
you would add it to the haskellPackages overrides
<clever>
and add them to the overrides
<clever>
yeah, you will probably want to run cabal2nix on those too, to force the version
<clever>
*doh*
<clever>
oddly, i cant find nomad in that cabal file
<clever>
what does its cabal file say?
<clever>
it also helps to keep the cabal2nix output in its own file, and just give callPackage the path
<clever>
i think you changed the cabal deps, and have to re-run cabal2nix
<clever>
ah, nomad-logger isnt in the nix file you linked
<clever>
yeah, it just disables all bounds
<clever>
that turns off the version limits in cabal
<clever>
haskell.lib.doJailbreak i think
<clever>
wait no
<clever>
you may need to run haskell.lib.dontCheck over that package
<clever>
but the same issue still comes up, because haskellPackages.override will set the overrides attribute, overwriting it
<clever>
similar to when you set config, you can also set import <nixpkgs> { overlays = [ ]; }, and give it a list of self: super: functions that act on the top-level pkgs set
<clever>
so they cant compose haskell overrides
<clever>
overlays only work at the nixpkgs level i believe
<clever>
jgt: yeah, i havent looked into how to fix that properly yet
<clever>
it uses the self: super: model, but doesnt allow composing
<clever>
yeah, i have been wanting a way to compose haskell overrides
<clever>
maybe, i havent played with extend much
<clever>
and 85 then uses it
<clever>
then line 75 will apply an override to that
<clever>
line 71 of this diff will select the right package set for the compiler you picked
<clever>
jgt: you can also remove it, but then you cant change compilers
<clever>
oops, 2 = 1 for the previous
<clever>
jgt: then haskellPackages2 = haskellPackages2.override ...
<clever>
jgt: you want to apply the override down near that if statement, so haskellPackages1 = if ...
<clever>
jgt: your doing an override against pkgs.haskellPackages, but then you ultimately use pkgs.haskell.packages.ghc822
<clever>
jgt: found the issue
<clever>
try disabling the 256 color changes you may have done to rxvt?
<clever>
psychic1: also try doing things under a different terminal emulator
<clever>
psychic1: that sounds more like $TERM is set wrong, so all readline based apps are broken
<clever>
yeah, you will need to add it to the librarySystemDepends i think
<clever>
and can sometimes be fixed by adding bashInteractive to the shell inputs
<clever>
it typically only happens when you run nix-shell inside nix-shell
<clever>
nix run doesnt change bash
<clever>
psychic1: nix-shell changes $SHELL to a simpler bash that lacks readline support, but it still runs the previous bash, so it only beocmes an issue when you nest shells
<clever>
also, id run `wpa_passphrase MYSSID passphrase > /etc/wpa_supplicant.conf` and then `systemctl start wpa_passphrase` to fix the 1st issue
<clever>
in configuration.nix
<clever>
eldad: for that 2nd one, services.xserver.desktopManager.xterm.enable = false;
2018-04-14
<clever>
so its a tricky choice
<clever>
but i also get anoyed by nix-env stuff not being updated automatically
<clever>
colonel_john_by: ive had issues with environment.systemPackages stuff blocking a minor OS config change, because package xyz doesnt build today
<clever>
colonel_john_by: mostly user preference
<clever>
zybell_: nix gives you reproducibility and immutability, systemd can easily add the isolation
2018-04-13
<clever>
i cant see why not
<clever>
it would save a few steps at install time
<clever>
i have plans to make a wrapper around makeSystemTarball, that pre-loads the db
<clever>
boomshroom: yeah, but that lacks a `db.sqlite`, so you have to manually run `nix-store --load-db < foo` on the remote machine, after you unpack
<clever>
`rip it out and mount!!` would let you turn a blank SD card into a fully working raspberry pi install, for example
<clever>
so you either need to mount it somehow (nfs?, sshfs?, rip it out and mount!!), or run nix on that remote machine
<clever>
it needs write access to whatever directory its copying to
<clever>
and if /mnt is a usb stick, you can now move whole closures between machines, with paths shared
<clever>
and then i think you just switch to --from to pull paths back out of /mnt
<clever>
and if any paths match up, it just reuses what was already in /mnt
<clever>
but with 2.0, you can `nix copy /nix/store/source --to local?root=/mnt/` to setup a normal /mnt/nix/store
<clever>
as an example, with the right flags, export can dump the entire closure, but there is no sharing between 2 exports, so it gets expensive to try and save 10 versions to a usb stick
<clever>
and you can just reverse the source/dest flags at the remote end to pull from it
<clever>
but with 2.0, you can also have an entire fully working store, that is just a chroot away from being a working system, if it has the right paths
<clever>
boomshroom: export/import generates multiple nar's and metadata about what they depend on
<clever>
boomshroom: dump/restore are raw nar files, and lack the name of the root element, so you can think of it like a feature-reduced tar
<clever>
nix-push (which has been replaced by a flag in nix copy) will generate a binary-cache directory, which has .nar and .narinfo files
<clever>
nix copy will share that metadata along with the nar
<clever>
the .nar is more like a .tar then a .deb
<clever>
boomshroom: though the .nar lacks information about what it depends on or what it is even called
<clever>
but if the sandbox is on, the impure method will just not find the file, forcing you to do it the right way
<clever>
if the sandbox is off, and you use a path the wrong way, it can allow impure access to that path, which causes fun bugs
<clever>
it also helps a lot to have the sandbox enabled
<clever>
bgamari: it also looks like you can combine flags, `nix path-info --sigs --size --closure-size` shows all 3 at once
<clever>
bgamari: same
<clever>
that trick can be used for any config file in /etc
<clever>
nixos-rebuild will then overwrite that file with a symlink at the next switch
<clever>
bgamari: the above will replace the symlink with a regular file, and edit it
<clever>
bgamari: another trick, cd /etc/nix ; cat nix.conf > new ; rm nix.conf ; mv new nix.conf ; vi nix.conf
<clever>
bgamari: ive also broken my machine by turning off a remote binary cache
<clever>
bgamari: looks like path-info only has 3 sub-commands
<clever>
the timestamps of such files are generally scattered all over the place, to make sure you cant just find those files in one area of `ls -ltrh` :P
<clever>
this problem only happens with nasty tar files that lack a common directory, and barf files all over your downloads folder
<clever>
or just sourceRoot = "src/";
<clever>
postUnpack = "sourceRoot=src/";
<clever>
both should work
<clever>
if you set sourceRoot, that error wont happen
<clever>
Myrl-saki: it has to build gcc, twice, before it can build anything else
<clever>
heh
<clever>
the same as when you where installing nixos
<clever>
fearlessKim[m]: yeah, and it has to be mounted to /mnt/boot/
<clever>
then nixos-rebuild boot should work
<clever>
and if your store is in its own fs, that has to also be mounted
<clever>
nixos-enter requires that you mount your root to /mnt and your boot to /mnt/boot
<clever>
fearlessKim[m]: also, you only want to use `nixos-rebuild boot` when doing that, and /boot has to be mounted
<clever>
fearlessKim[m]: nixos-install --chroot got turned into nixos-enter
<clever>
winsome: yep
<clever>
or do nixpkgs.packageOverrides = pkgs: { polybar = pkgs.polybar.override { githubSupport = true; }; };, which will change what pkgs.polybar refers to elsewhere
<clever>
you can either put (polybar.override { githubSupport = true; }) into systemPackages
<clever>
symlinks cant be chmod'd, so nixos will copy the file for you and chmod
<clever>
ah, there are some mode things in environment.etc you can use
<clever>
fearlessKim[m]: also, environment.etc can be used to make a symlink to do all of that
2018-04-09
<clever>
wilornel: yeah, check the nix-channel man page, and run it as root
<clever>
wilornel: try using the nixos-18.03 channel
<clever>
kreisys: there are non-free libraries that cant be put into the store
<clever>
kreisys: id recomend doing the initial work on linux, darwin is just weird
<clever>
it was probably started by something that has since quit
<clever>
kreisys: pid 1 or other?
<clever>
LnL: and that would be my desktop locking up once more, lol
<clever>
norfumpit: running the gnome settings daemon
<clever>
norfumpit: the xfce session settings include an option for ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
<clever>
kreisys: check pstree, what is the parent?
<clever>
the slave see's the lock there, assumes another thread is building it already, and waits
<clever>
then ssh's into the slave (itself) and says "build this!"
<clever>
nix gets a local lock on the storepath, because its being built
<clever>
zybell_: happens even with 1 thread
<clever>
zybell_: fourth, deal with nix deadlocking because its building something on localhost but has to wait for itself to finish before it can start
<clever>
yeah
<clever>
whatever the slave happens to be
<clever>
if you run the nix-build on the master with a, it will push a out to foo
<clever>
not sure how you can do that, other then turning remote building off entirely