<clever>
zfs automatically limits itself to using a max of 50% of your ram
<clever>
i use zfs on my laptop
<clever>
SuaveDandy: nix doesnt make snapshots, it just has a list of packages that act as versions for a given thing, and you can delete anything thats not used
<clever>
SuaveDandy: you can make /nix a seperate dataset without zfs snapshots
<clever>
that is required for the rootfs and /nix
<clever>
iqubic: nixos can only mount (via fstab and fileSystems) zfs if mountpoint=none
<clever>
inkbottle: --upgrade just gets the latest for your current channel, you need to change the channel first
<clever>
sonercirit[m]: when you build things that you want to have obey master
<clever>
sonercirit[m]: you dont have to change the channel, just git clone master, and use `-I nixpkgs=/foo` to point things to the checkout
<clever>
inkbottle: `sudo nix-channel --list` ?
<clever>
that will tell you what kernel your going to be getting
<clever>
inkbottle: `nix repl '<nixpkgs>'` then eval `linux`
<clever>
inkbottle: try running it again, its probably just a random error
<clever>
so you need to be aware of those changes, and manually migrate the state before you change the stateVersion
<clever>
yes
<clever>
V: upgrading involves dumping the entire db to .sql format while the old daemon runs, then switching the daemon out, and re-importing the entire db
<clever>
V: then you would have to ship 2 versions of the postgres binary to the end machine, and somehow swap which one is in the global $PATH based on the file
<clever>
V: it has to be done from your configuration.nix, because you might be building for another machine (nixops)
<clever>
inkbottle: because the new version cant read the old db files, and upgrading would break postgresql hard
<clever>
inkbottle: the only case i can think of where it stops things from upgrading is the postgresql version
<clever>
it should just be left at the previous value
<clever>
so it continues to work as before
<clever>
inkbottle: thats what stateVersion is for, to minimize the breakage when you upgrade without reading the release notes
<clever>
inkbottle: and youll only know the state has changed if you read the nixos release notes closely
<clever>
inkbottle: you need to specify it if your using things where the state has changed, such as the ssh hostkey type, or the default postgres master user
<clever>
DamienCassou: you cant repair that path until you close those 4 PID's and delete generation 16 from your profile
<clever>
nefix: mount --bind something to ~/.nix-defexpr/
<clever>
nefix: it needs to be created before home becomes read-only
<clever>
nefix: ~/.nix-defexpr could be a symlink to a mutable place
<clever>
DamienCassou: run it on one of the broken paths
<clever>
DamienCassou: nix-store -q --roots?
<clever>
DamienCassou: then `nix-store --repair-path` on each one and see what happens?
<clever>
DamienCassou: try using `nix-store --delete` on each, but dont force things
<clever>
last time i used it, it would only print if you dont ask to --repair
<clever>
thats new, last time i delt with this, you couldnt delete until you removed all roots
2020-08-30
<clever>
so i thought it was on my end
<clever>
i was also having cache.nixos.org problems, but ipv6 was acting up due to other stuff at the time
<clever>
oh
<clever>
it has already recovered for me
<clever>
i was just having issues reaching the rpi forums, but it was between cloudflare (newark) and the backend servers
<clever>
jlv: and if you set substituters to "", then it has no caches to consult
<clever>
jlv: `--option` can be used to dynamically change anything in nix.conf
<clever>
setting the remote to daemon causes it to go via nix-daemon, which uses /tmp/
<clever>
NobbZ[m]: if ran as root, it will spawn the builds directly, and respect $TMPDIR, which can break some things
<clever>
jackdk: what happens if you use `NIX_REMOTE=daemon nix-build ...` ?
<clever>
jackdk: are you running the build as root or a normal user?
<clever>
jackdk: is /tmp on its own fs?
<clever>
omasanori[m]: nix should be able to do all of those easily
<clever>
omasanori[m]: which cpu arch are you targetting?
<clever>
omasanori[m]: with nix, its not recommended to install any compiler with nix-env, just use nix-shell to load an env with that compiler
2020-08-29
<clever>
jackdk: its in `nix eval --help`
<clever>
To evaluate a Nix expression given on the command line:
<clever>
$ nix eval --expr '1 + 2'
<clever>
symphorien[m]: many config options may also be unset, and will throw if you try to read them
<clever>
symphorien[m]: config also contains the entire pkgs tree, including lib
<clever>
wpcarro: you can either use nix-copy-closure to copy that path between machines, or `nix-store --delete` to remove it from the cache
<clever>
wpcarro: nix-store --query --binding out /nix/store/f70hw0g9rd2hkcfyivxivg3nrlczip3n-source.drv
<clever>
wpcarro: what derivation is failing?
<clever>
wpcarro: but one machine has it cached
<clever>
wpcarro: its possible that the website the file came from has simply deleted it
<clever>
wpcarro: or modifying the package to not do network, and use pkgs.fetchurl to pre-fetch things
<clever>
wpcarro: by declaring the hash of $out upfront in the nix expression
<clever>
wpcarro: network should never work during a build, if it is working, then the sandbox was off and not doing its job
<clever>
wpcarro: is the sandbox on? what is the actual error?
<clever>
if you make them match up, and get the same .drv from both machines, does have the same outcome on both?
<clever>
wpcarro: depends on what the build is then doing with that elisp
<clever>
wpcarro: ah, now run `diff -r` on those 2 paths, nix-copy-closure already copied them over too
<clever>
wpcarro: what difference did it find?
<clever>
flox: trying to build master locally to confirm what is happening
<clever>
wpcarro: nix-diff will reveal exactly what differs, and then it should be a lot more obvious what the cause is
<clever>
wpcarro: if you dont force `overlays = [];` then nixpkgs will load the user overlays from the path immae gave
<clever>
wpcarro: what does nix-diff say the difference is?
<clever>
wpcarro: use nix-copy-closure to get both drv's onto the same machine, then use nix-diff to compare the 2 drv files
<clever>
flox: yep, i can reproduce the mbuffer fault locally
<clever>
wpcarro: does `nix-instantiate` give the identical .drv for both machines?
<clever>
can you pastebin your expression?
<clever>
flox: is configure trying to do both x86 and aarch64 builds, for utils used at build-time?
<clever>
flox: nix will automatically point that towards the right version for the current target
<clever>
aarch64-unknown-linux-gnu-objdump
<clever>
[nix-shell:~]$ echo $OBJDUMP
<clever>
[clever@amd-nixos:~]$ nix-shell '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello
<clever>
flox: you want to use $OBJDUMP when cross-compiling
<clever>
if you used -q, then you wont see any http errors
<clever>
jackdk: what did wget print when it fetched that file? any http status codes?
<clever>
only lines 4/5 get some changes
<clever>
jackdk: the only change nix does to those lines, is the '' will strip 2 spaces from the start of each
<clever>
jackdk: but there is no ${ in that line, so nix doesnt make any real changes to it
<clever>
that looks like its entirely in the bash area, not nix
<clever>
grep
<clever>
peelz: i just read the source for them in nixpkgs, and look for examples of how they are used
<clever>
peelz: yeah, patchShebangs will replace #!/usr/bin/env with the output of $(which env)
<clever>
c4rc4s: they might be using qt5.callPackage
2020-08-28
<clever>
that runs all phases, and deals with var vs function
<clever>
arianvp: the simplest way to do everything, is to just run genericBuild
<clever>
arianvp: you need to eval "$configurePhase" (the override from the expr) not run configurePhase (the bash function of the same name, which is the default)
<clever>
arianvp: oh, right, i see your problem
<clever>
arianvp: when you run configurePhase, what directory are you in?
<clever>
arianvp: what does `echo $phases` say?
<clever>
arianvp: after unpackPhase, you must `cd $sourceRoot`
<clever>
redmp: yep
<clever>
or use pkgs.fetchzip, it works on tar files
<clever>
redmp: so when you try to run what i gave, it winds up giving you a shell suitable to build: stdenv.mkDerivation { name = "shell"; buildInputs = [ (import ./.) ]; }
<clever>
redmp: `-p` will generate a derivation for you, and shove each argument into the buildInputs
<clever>
or `nix-shell -p '(import ./.)'` which will dynamically generate one
<clever>
redmp: you want default.nix to return a derivation that has buildEnv in the buildInputs
<clever>
redmp: that gives you a shell suitable for building the buildEnv, not for using it
2020-08-26
<clever>
cole-h: so ./. is already in the store to begin with
<clever>
cole-h: i think its because nix copied the flake into the store before parsing the nix
<clever>
ah, then you want to `unstable = import <nixos-unstable> { inherit config; overlays = [ (self: super: { qtquickcontrols = master.qtquickcontrols; }) ]; };`
<clever>
so the main nixpkgs (that the overlay is added to) gets that one pkg from unstable
<clever>
hazel[m]: it would make qtquickcontrols be the version from unstable
<clever>
qtquickcontrols = self.unstable.qtquickcontrols; in the overlay
2020-08-25
<clever>
dminuoso: lib.recursiveUpdate can behave weirdly with derivations, // is safer
<clever>
dminuoso: then you need to do { haskell.packages = super.haskell.packages // { ghc865 = super.haskell.packages.865.extend ...; }; }
<clever>
dminuoso: you dont have the name the new thing the same way, you can just { myHsPackages = super.haskell.packages.865.extend ...; }
<clever>
Extends: ./. doesnt end in a / so `./. + "foo.txt" in a bar dir, winds up pointing to /path/to/barfoo.txt
<clever>
check my github, nixos-configs/netboot_server.nix
<clever>
i just edit the main dhcp server directly
<clever>
such as fstab creating and other things
<clever>
various tasks that get ran on nixos
<clever>
pie_: dont have that part memorized, and chrome is currently not responding
2020-08-24
<clever>
hexagoxel: ah, i'll have to look at that later, it never works for me either in xterm
<clever>
liminal18_: you can just set services.mongodb.extraConfig to populate that