<clever>
chpatrick: you need to use haskellPackages.mkDerivation, not shellFor i believe
<clever>
you need to change the configuration.nix option that installed it
<clever>
rindolf: then its installed via configuration.nix, not nix-env
<clever>
rindolf: what does `type khelpcenter` return?
<clever>
rindolf: kde is also not present there
<clever>
rindolf: qt isnt installed in nix-env, so it cant be removed
<clever>
that bug also broke the ability to rollback via the grub menu
<clever>
then all of the users with nixpkgs-unstable came out of the woodwork :P
<clever>
nixos-unstable correctly refused to update
<clever>
about a year ago, grub was broken, and corrupted the grub config file
<clever>
PyroLagus: and if you install nixos from nixpkgs-unstable, you risk breaking the install
<clever>
PyroLagus: yeah
<clever>
t
<clever>
PyroLagus: nixos-unstable only does linux testing, and tests more OS related things, to ensure nixos can still boo
<clever>
PyroLagus: thats nixpkgs-unstable, which is used outside of nixos (ubuntu, debian, darwin, and so on)
<clever>
rindolf: can you gist the output of `nix-store -qR ~/.nix-profile` ?
<clever>
rindolf: remove every package that depends on QT
<clever>
rindolf: only names listed in `nix-env -q` can be removed with `nix-env -e`
<clever>
but --delete said it had roots keeping in in-use
<clever>
which lead to confusion, nix-store --query --roots said a path had no roots
<clever>
manveru: nix1 did it, but silently didnt tell you about them
<clever>
rindolf: root is needed for -d to get rid of all unused paths
<clever>
cocreature: but Setup.hs will always use the library that the nix-shell provided, so its always perfect
<clever>
cocreature: id expect it to only break a few years down the road, when the cabal in nix-env has aged, and your using a much newer nixpkgs for the nix-shell
<clever>
cocreature: i have seen it break for others before, when they manually installed cabal-install with nix-env, and then tried to manually build in a shell
<clever>
cocreature: but if you ignore the Setup.hs entirely, and run `cabal configure` + `cabal build`, it may be the wrong version of cabal
<clever>
that can break things, because it wont be the same version as what the nix expressions want
<clever>
`runhaskell Setup.hs test`
<clever>
either `runhaskell Setup.hs configure` or compile it with ghc, then run it
<clever>
gchristensen: that only has the cabal library, not the binary, you need to run Setup.hs
<clever>
gchristensen: are you in a shell from haskellPackages.mkDerivation?
<clever>
mplayer too
<clever>
sphalerite: i think vlc can do it
<clever>
you need to partition, format, and mount everything under /mnt, then run nixos-generate-config --root /mnt, edit /mnt/etc/nixos/configuration.nix, and then nixos-install --root /mnt
<clever>
shapr: that has to be done manually
<clever>
shapr: id also recomend that the efi sys partition be at least 512mb, maybe 1gig
<clever>
but there is a removable option to get around it
<clever>
uefi is a pain like that
<clever>
so another machine will refuse to boot it by default
<clever>
it relies in the efi vars in the nvram being setup right
<clever>
if using uefi, then you can just entirely ignore the ubuntu drive, give nixos its own efi system partition and rootfs, and then youll have an option for both in the UEFI menu
<clever>
shapr: uefi or legacy booting?
<clever>
so it hard-coded itself to open the path "unknown" at runtime
<clever>
the nix sandbox had none of the options
<clever>
the package was testing for things like /etc/mtab, to detect what your distro is doing
<clever>
rotaerk: the problem was that the nix sandbox broke the package, and i had the sandbox off at the time
<clever>
rotaerk: it turns out, anything not in the cache worked, and anything in the cache failed, so the bisect just failed to locate the problem entirely
<clever>
rotaerk: i once did a bisect like that, and ran into all kinds of trouble
2018-07-09
<clever>
IN_NIX_SHELL=impure
<clever>
kalbasit: its meant to be edited manually
<clever>
Ralith: the entire config set is untyped and ignores any undefined options
<clever>
Ralith: overlays is its own attribute, beside config, not inside
<clever>
NoOneRules: and if you ls -l ~/.nix-profile/ ?
<clever>
and what did it output?
<clever>
NoOneRules: did you re-run nix-env after editing it?
<clever>
unknown
<clever>
jtojnar: so if you just ask pkgconfig to find its .pc file
<clever>
jtojnar: those packages should already be in scope
<clever>
jtojnar: it might help if pkgconfig has a fixup hook, that scans the requires fields, and populates the propagated-inputs under $out/nix-support/
<clever>
Ralith: so i always make my /boot pretty large, and i can also recover from almost any failure
<clever>
Ralith: it puts the entire nixos installer into /boot, at the cost of about 400mb
<clever>
you can also manually delete some kernels
<clever>
you have to GC some system generations, then nixos-rebuild
<clever>
Ralith: and /boot is only updated upon nixos-rebuild, even after a GC
<clever>
Ralith: from rebuilds prior to the last boot
<clever>
import ./foo.nix will be identical to just pasting the contents of foo.nix in at that location
<clever>
pretty much
<clever>
bpye: you can just make your own nix file containing a set { smtp_server = "foo"; } and then import it
2018-07-07
<clever>
Ralith: setup.sh i think is the only place
<clever>
you can grep nixpkgs for examples, and how it works
<clever>
illegalprime[m]: adding cmake to the buildInputs will automatically change the default configurePhase, and the new one obeys that var
<clever>
illegalprime[m]: that would go under cmakeConfigureFlags i believe
<clever>
illegalprime[m]: you can also set installFlags = [ "prefix=$out" ];
<clever>
illegalprime[m]: headers would be in $out/include/
<clever>
illegalprime[m]: it needs to install everything to $out
<clever>
fasdfadsfadasd: you can also nix-env -f foo.nix -iA attribute
<clever>
__monty__: ive tried, for avahi doesnt listen on that interface for me
<clever>
__monty__: then configure nginx to mux it out to the right LAN ip on the remote end
<clever>
__monty__: put a /etc/hosts entry to map many subdomains to the toxvpn ip
<clever>
socat can just blindly forward it, nginx can be setup as a reverse proxy and inspect the Host: header to redirect it inteligently
<clever>
__monty__: so port 80 on the toxvpn host redirects to 80 on the http server
<clever>
__monty__: you might also be able to use a tool like socat or nginx to create a transparent proxy
<clever>
__monty__: the other option is to run toxvpn on the http server
<clever>
__monty__: i have plans to get routing working over toxvpn, but havent gotten around to testing them
<clever>
__monty__: currently, you would need to run something like squid on the remote toxvpn machine, then use its tox ip to connect to the squid proxy
<clever>
mahagad: an override in config.nix
<clever>
so your better off with { pkgs ? <nixpkgs> }:
<clever>
gchristensen: oh, and line 2 re-imports a 2nd nixpkgs, and doesnt set system
<clever>
gchristensen: i think for nixpkgs itself, you just use system = "x86_64-darwin";, i'm not sure why nixos wants to call it something different
<clever>
gchristensen: i think localSystem is for native builds but platform is for cross-builds
<clever>
yeah
<clever>
without that, it knows localhost cant build, and has no choice
<clever>
jgt: because you used --option system, it assumed that localhost can build faster then nix-docker, so it just did that