<clever>
duairc: the difference vs using the nix assert statement, is that nixos can report multiple errors at once
<clever>
duairc: nixos has a special "option" called assertions, it takes a list of { assertion = bool; message = "something"; }
<clever>
numkem: you want to either `import sources.nixpkgs { config = config.nixpkgs.config; }` to make it respect the option, ot you can `{ config.allowBroken = true; }` to have a 2nd copy of config
<clever>
numkem: when you re-import nixpkgs, it ignores nixpkgs.config, and instead obeys the config.nix in $HOME
<clever>
are you importing a 2nd nixpkgs?
<clever>
numkem: are you building it with nix-build, nix-env, or nixos-rebuild?
<clever>
you can either run nix-shell on that, or nix-build if you have a Makefile with a default target that produces an avr.bin
<clever>
o1lo01ol1o: there will be a second problem after you fix that
<clever>
TheSirC[m]: are you on a version of nixpkgs that includes the updates you want? check `nix-instantiate --find-file nixpkgs`
<clever>
o1lo01ol1o: when you do `type pg_restore`, and then run realpath on that path, what does it output?
<clever>
TheSirC[m]: they will update automatically when you update the channel and nixos-rebuild
<clever>
hazel[m]: my trick is to just `cd /etc/ ; cat hosts > hosts.temp ; rm hosts ; mv hosts.temp hosts`
<clever>
changing the permissions will break things in a worse way, it wont always be able to undo it
<clever>
jlv: you want to delete the symlink at /etc/hosts, and replace it with a normal file, with the contents you want (which can be a copy of the old one)
<clever>
jlv: thats worse
2020-07-18
<clever>
utf64: just `nix-build '<nixpkgs/nixos/release.nix>' -A netboot.x86_64-linux`
<clever>
utf64: there is an attribute for it in the main nixos/release.nix
<clever>
should be
<clever>
yeah, thats a work-around to make it boot without efi vars
<clever>
so if you delete the partition first, the efi var is permanently stuck, until you run out of space for efi vars
<clever>
i have also heard of some bios that wont let you delete an efi var if the partition is missing
<clever>
"it booted windows, ship it"
<clever>
fyuuri: i have seen some bios's that ignore all atempts to change the efi vars, and only boot the .efi file windows uses
<clever>
fyuuri: the `can touch efi vars` lets grub modify the efi vars, and `efiboormgr -v` just prints the efi vars
<clever>
fyuuri: normally, `efibootmgr -v` should show the partition uuid of the efi system partition, and the path to a .efi file within it
<clever>
LHurttila: if the entire change is in one commit on git, you can just add .patch to it
<clever>
or is the phrase, "special snowflake" i think?
<clever>
apple had to be a special sunflower, and make their nvme drive non-compatible
<clever>
LHurttila: the file i linked, was to fix a driver problem when running linux on mac hw
<clever>
LHurttila: you need to unpack the current linux source, and then checkout master for the above branch, and use `diff -ru` between the 2 dirs to generate a patch
<clever>
you just shove a set into boot.kernelPatches, which has a name and the path to a patch
<clever>
cap_sensitive: can you screenshot the error msg and the cmd that was ran?
<clever>
maybe you forgot the {} there too?
<clever>
cap_sensitive: is the command in irc further up, the exact one you ran?
<clever>
cap_sensitive: you forgot the {} at the end
<clever>
cap_sensitive: that should just work..., what happens if you run that expr in `nix repl` ?
<clever>
cap_sensitive: contents of package.nix?
<clever>
cap_sensitive: what are the contents of package.nix? is it part of nixpkgs or outside?
<clever>
gueorgui: linuxPackages_5_7 and boot.kernelPatches
2020-07-13
<clever>
bbl
<clever>
dansho: only the rustc in the nix store will work, and its being dumb and re-running the broken rustc's from ~/.rustup/ to "help you" with changing versions (which cant work on nix)
<clever>
dansho: its reading that same config file, and running the "wrong" rustc
<clever>
dansho: it feels like the rustc you ran ldd on, is working perfectly fine, but it then decides to run a totally different rustc, check `strace rustc --version` ?
<clever>
dansho: then why are you getting an error from /home/dansho/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc ?
<clever>
i mean, `which rustc`
<clever>
dansho: what does `which rustup` report?
<clever>
dansho: what does `LD_TRACE_LOADED_OBJECTS=1 rustc` report?
<clever>
> builtins.readFile
<clever>
patagonicus: thats just a helper, that sets buildCommand for you
<clever>
patagonicus: there is also `pkgs.runCommand "name" { buildInputs = []; } "script goes here"`
<clever>
patagonicus: if you set buildCommand, it skips all phases, and its unpackPhase that complains about $src
<clever>
Fare: there is builtins.match, but its not full regex
<clever>
> builtins.pathExists ./version.nix
<clever>
ixxie: and its relative to the path that ./foo exists within, not the file doing readFile
<clever>
ixxie: ./foo is relative to the dir the file is in
<clever>
424 print STDERR "reloading the following units: ", join(", ", sort(keys %unitsToReload)), "\n";
<clever>
so some just fail to update and keep working, others "successfully" but then brick itself, and wont work even if you do update with nix (you have to clear the right state)
<clever>
except the new ver isnt patchelf'd so it fails after the update, when it next launches
<clever>
ixxie: but i have seen that dropbox tries to put its update into something like ~/.dropbox/ and then the old ver runs the new ver automatically
<clever>
ixxie: some programs try to edit themselves in /nix/store, that will just hard fail
<clever>
systemd is about the simplest modern way to run something on startup
<clever>
yeah, it would be one-shot, so it only runs on login and wont stay running
<clever>
when nix parses that, it will turn into `gpg recv-keys /nix/store/hash-keys`
<clever>
raghavsood: i'm thinking a systemd-user service, that just runs `gpg recv-keys < ${./keys}`
<clever>
duairc: when updating /boot, the scripts will read whatever path you gave it, and copy the secret into the initrd
<clever>
duairc: i think you want to use deployment.keys to put the key on the machine, and set boot.initrd.network.ssh.hostKeys = "/path/on/remote/box"; to the path you told deployment.keys to use
<clever>
and you never notice that its not using the new shell.nix
<clever>
my problem with things like lorri, is that when you get such eval errors, it just silently uses the old env
<clever>
nabataeus: nixos-rebuild ignores config.nix by default
<clever>
raghavsood: so for root, its no longer the initial boot when you deploy things
<clever>
raghavsood: i think the problem with initialHashedPassword and nixops, is that the machine boots once before you deploy
<clever>
maralorn: not really, you would need to return a set that has both your pkg and the pkgs tree, or return an overlay and let something else assemble things
<clever>
colemickens: buildEnv and symlinkJoin are derivations
<clever>
> haskell.lib.dontCheck
<clever>
and `nix-instantiate '<nixpkgs/nixos>' -A system` will give the new drv based on current cfg
<clever>
chipb: `nix-store --query --deriver /run/current-system/` will give the drv for the currently running nixos
<clever>
chipb: run `nix-diff` on the before and after .drv files
<clever>
if you give nix-env -i a list or set, it will just install all of the things
<clever>
then you have the fun of figuring out which result you wanted
<clever>
colemickens: if you give nix-build a list or a set, it just barfs a ton of result-42 symlinks into the current dir
<clever>
moet: also, its using fetchzip, which matches up to `nix-prefetch-url --unpack`
<clever>
195 in self.callCabal2nix pkg (pkgs.fetchzip {
<clever>
,tofu moet
<clever>
colemickens: i tend to use buildEnv
<clever>
but often, the defaults are fine
<clever>
like callPackage ./foo.nix { withBar = true; }
<clever>
the {} at the end, is for an args the default.nix accepts on line 1
<clever>
moet: the standard {} that all callPackage things want
<clever>
so i think that would be: callHackageDirect { pkg = "doctest"; ver = "0.17"; sha256 = "hash"; } {}
<clever>
callHackageDirect = {pkg, ver, sha256}:
<clever>
s/calt/cant/
<clever>
you want to switch over to callHackageDirect, which needs a sha256 of the src
<clever>
but it can be out of date, and then you calt callHackage
<clever>
moet: nixpkgs has an all-cabal-hashes.tar file, that has every single .cabal file for every single version
<clever>
yep
<clever>
it uses an flock to determine if the thing is actually building or not, and those get released when the proc dies
<clever>
nope
<clever>
probably
<clever>
moet: they are some of the first things deleted by a GC, so `nix-collect-garbage --max-freed 1` will delete most of them, and then 1 random piece of garbage
<clever>
moet: those get created when a build starts, and an flock is held on it while building
2020-07-10
<clever>
and you often put overrides into an overlay
<clever>
an overlay can change how other packages see that package
<clever>
an override is used to change the package in some way
<clever>
so it also depends on the size of the store
<clever>
it just reads every single file in /nix/store and hashes them
<clever>
depends on disk io and cpu speed
<clever>
--repair will auto repair anything found to be wrong
<clever>
--verify alone, will just search for a whole dir thats missing
<clever>
bqv: `nix-store --verify --check-contents` will scan for corruption
<clever>
bqv: "unknown-deriver" can also happen if you simply garbage-collect
<clever>
you can then switch over to `mkForce ''your config here'';` and put newlines in it