2021-01-07

<clever> eacameron: there is a replacement in nixpkgs itself now, let me see...

2021-01-06

<clever> fuzzypixelz: its probably in https://github.com/NixOS/nix somewhere
<clever> and (nearly) everything under builtins, is written in c++, and part of the nix binary itself
<clever> oh, but lib.filter, is just an alias to builtins.filter
<clever> > builtins.filter (x: x<5) [ 1 3 6 7 ]
<clever> fuzzypixelz: it also has a lot of util funtions
<clever> > builtins.foldl' (a: b: "${a}, ${b}") "first" ["second" "third"]
<clever> `nix repl <nixpkgs>`
<clever> its within nixpkgs
<clever> > lib.filter (x: x<5) [ 1 3 6 7 ]
<clever> but its also lazy, and will only parse if something tries to eval the `import ./foo.nix`
<clever> so each time you run `nix-build`, it has to parse every file once
<clever> the cache isnt saved to disk, so once the process doing the parsing exits, the cache is list
<clever> so if you import it again, you get the exact same value, and it doesnt re-parse it
<clever> import also assumes the file wont be changing, and will store that top-level value in a hashmap, keyed on the filename
<clever> which is invalid
<clever> so `let x = import ./bad.nix;` is basically saying `let x = (foo = 0; bar = 42;);`
<clever> the import function just returns whatever value you had in the file
<clever> correct, it must be a valid value, it has to parse it firt
<clever> key = value; is either part of a let block or a set
<clever> fuzzypixelz: it must be a valid value
<clever> this would be why
<clever> fuzzypixelz: if you forget a space when defining a function, it turns into a string!
<clever> > foo:bar
<clever> and then its just normal function application
<clever> > let or = "boo!"; f = a: b: a+b; in f or "bar"
<clever> when it follows anything else, it looks for the `or` variable in the current scope
<clever> `or` is only special if it follows something in the form of `set.key`
<clever> it sets a global var, that causes exceptions to also print a stack trace
<clever> KarlJoad: you can still `nix repl --show-trace`
<clever> KarlJoad: does --show-trace show anything?

2021-01-04

<clever> for that part, i'm not sure
<clever> it doesnt exist by default, you need to create it
<clever> typo, its config.nix
<clever> getting a link to the docs...
<clever> donofrio: there is no need to reinstall or remove anything, just define the changes you want in config.txt, and nix will rebuild anything that it affects

2021-01-03

<clever> HenryCH: #nixos-aarch64 is where all of the arm guys gather
<clever> ghasshee: try running the repl with `-L` ?

2021-01-02

<clever> clime: `nix-store --generate-binary-cache-key` violates that
<clever> clime: just an extra \n at the start
<clever> [clever@amd-nixos:~]$ echo "$PS1"
<clever> \n\[\033[1;32m\][\[\e]0;\u@\h: \w\a\]\u@\h:\w]\$\[\033[0m\]
<clever> clime: i mostly get it when i run cat on files that have just a single string and no newline
<clever> clime: without that, your prompt gets appended to the last line of output sometimes
<clever> clime: yes, its to deal with programs that dont have a \n at the end
<clever> the nix sandbox automatically restricts everything to the required deps, and disables network
<clever> energizer: this runs a chunk of bash, which itself is running some haskell binaries compiled earlier, and puts all results in $out
<clever> energizer: it can be simpler to just have nix do the sandbox for you
<clever> energizer: -qR will show the runtime deps, but not the buildtime deps
<clever> enless you run nix-store --delete or GC, it wont delete any of the deps
<clever> abathur: symlinks to every result link, sorted in the order they got made
<clever> abathur: ls -ltrh /nix/var/nix/gcroots/auto/

2020-12-31

<clever> nh2: the same default.nix you would have `nix-shell -A env`'d against
<clever> nh2: the shell.nix can just (import ./.).env
<clever> and dont use --force

2020-12-28

<clever> DanC: the docs could maybe do with some more work
<clever> DanC: further down in the file you linked, where it says `nixops create`
<clever> pushqrdx: niv can only update a sources.json file, so you need to write some nix to override the .src from sources.nix
<clever> DanC: the config you deploy must have the bootloader/filesystem/network stuff setup right, or the machine wont boot
<clever> DanC: `nixops create -d name trivial-nixos.nix` and then `nixops deploy -d name`
<clever> pushqrdx: run `niv init` and then `niv add owner/repo`, and then you can `sources = import ./nix/sources.nix` and `sources.repo`
<clever> probably niv, and run `niv update foo` to update it
<clever> pushqrdx: and if you set rev = "master"; it will randomly break next time master is pushed, but only if you dont have old master cached
<clever> pushqrdx: the hash is required or nix wont give git network access
<clever> Gaelan: does --dirty change things?
<clever> cole-h: it worked when i used it a few days ago
<clever> Heffalump: that will create a result in the current dir, and then another symlink under auto, that points to result
<clever> Heffalump: nix-store -r foo --add-root result --indirect
<clever> gobject-introspection is the .name, but you must refer to it as gobjectIntrospection in a nix expr
<clever> > gobjectIntrospection.name
<clever> ,locate libgirepository
<clever> nlyy: boot.kernelPackages = pkgs.linuxPackages_latest;
<clever> nlyy: unstable is still 5.4 by default
<clever> nixos-unstable is the unstable channel
<clever> but 20.09 is the newest stable channel
<clever> you want to use nix-channel to change channels
<clever> nlyy: did you read the comment beside it?
<clever> nlyy: dont change stateVersion

2020-12-27

<clever> veleiro: that bash is optional
<clever> veleiro: you could just do `NIX_PATH= nix-shell ...drv`, to skip building that bash
<clever> veleiro: and `nix-instantiate --find-file nixpkgs` ?
<clever> veleiro: you need to either wipe $NIX_PATH so it cant, or provide it a <nixpkgs> that can build successfully
<clever> veleiro: i think nix-shell is trying to grab bash from <nixpkgs> to add to $PATH
<clever> veleiro: can you pastebin the full output from nix-shell?
<clever> nasirhm: check the default.nix in github.com/cleverca22/thermostat_firmware
<clever> stu_[m]: check this in the nixos docs
<clever> 99 security = {
<clever> 100 pam = {
<clever> 101 loginLimits = [
<clever> veleiro: and what error does it print when you run nix-shell on that?
<clever> veleiro: which .drv did you run nix-shell on?
<clever> veleiro: you can just run nix-shell on a .drv

2020-12-23

<clever> but that wouldnt be pure!!
<clever> yeah
<clever> pushqrdx: once nix-build completes, and your happy with it, you can always nix-env -i ./result
<clever> pushqrdx: it wont properly track the dependencies when you do that
<clever> pushqrdx: lorri adds gc roots for each dir, so you cant gc the things, even when the nix-shell is closed
<clever> pushqrdx: direnv is basically just automatic nix-shell
<clever> pushqrdx: correct
<clever> esotericnonsense: what about this one?
<clever> esotericnonsense: NIXOS_INSTALL_BOOTLOADER=1 /nix/var/nix/profiles/system/bin/switch-to-configuration boot
<clever> esotericnonsense: and thats when it was ran with --install-bootloader?
<clever> esotericnonsense: what did nixos-rebuild output?
<clever> esotericnonsense: is efi enabled in configuration.nix?
<clever> pushqrdx: 2020-12-23 18:27:28 < clever> some also lack a .dev
<clever> pushqrdx: yeah
<clever> esotericnonsense: nixos-rebuild --install-bootloader
<clever> stdenv.mkDerivation automates thatf for you, but overrideDerivation happens too late
<clever> some also lack a .dev
<clever> pushqrdx: just .out and .dev, no need for the one without a suffix, i think
<clever> add both .out and .dev to buildInputs, and then see what happens
<clever> this is why overrideDerivation is deprecated
<clever> and self.wayland.out as well
<clever> you want self.wayland.dev i believe
<clever> i also just realized, overrideDerivation breaks split output stuff
<clever> yes
<clever> pushqrdx: self.pkgs is redundant, try self.pkgs.pkgs.pkgs.wayland! :D
<clever> pushqrdx: read the readme on the link i gave
<clever> pushqrdx: 2020-12-23 17:53:46 < clever> pushqrdx: nix-build creates a result symlink, so you can result/bin/wine foo.exe, and it overwrites result each time, so GC will only keep the last build around
<clever> infinisil: except when its wine-wow, that abomination breaks all the rules, lol
<clever> pushqrdx: nix-build '<nixpkgs>' -A nix-du ; result/bin/nix-du ...
<clever> pushqrdx: you can use nix-build instead
<clever> pushqrdx: which lock file?
<clever> pushqrdx: or just run `ncdu -x /nix`, what is the fattest path?
<clever> pushqrdx: nix-du
<clever> pushqrdx: if it has root, then it can also delete GC roots for nixos and root's nix-env
<clever> pushqrdx: permissions only matter if you use -d (delete all generations) or ----delete-older-than
<clever> pushqrdx: without args, permissions for gc dont matter
<clever> > 2020 / 5
<clever> pushqrdx: having a nix-shell open on the project also counts
<clever> 2020-12-23 18:01:36 < clever> pushqrdx: if you gc while building, you cant delete things the build needs
<clever> pushqrdx: also, `nix-collect-garbage --max-freed 10g` will only delete 10g of stuff
<clever> pushqrdx: if you gc while building, you cant delete things the build needs
<clever> pushqrdx: nix-end --delete-generation 42, if you want to remove a single root
<clever> a single non-wow build is 258mb
<clever> some of them may be in multiple, if you installed other things
<clever> pushqrdx: this will show the storepath for wine, in each generation
<clever> ls -l /nix/var/nix/profiles/per-user/clever/profile*/bin/wine
<clever> nix-channel is also a wrapper around nix-env!
<clever> nixos-rebuild is a wrapper around nix-env!
<clever> rollbacks ONLY apply to nix-env
<clever> nix-env --list-generations
<clever> thats how rollbacks work
<clever> but it keeps the old version as well, incase you decide to nix-env --rollback
<clever> its creating a new copy of your profile, where foo has been replaced
<clever> pushqrdx: when nix-env successfully builds it, a gc root is added, so that build cant be deleted
<clever> pushqrdx: nix-build creates a result symlink, so you can result/bin/wine foo.exe, and it overwrites result each time, so GC will only keep the last build around
<clever> pushqrdx: nix-env will install whatever it built into ~/.nix-profile, and add gc roots, so youll eventually wind up with 20 copies of wine that you cant gc with the default flags
<clever> pushqrdx: nix-shell, nix-env, and nix-build will all load your overlays.nix by default
<clever> pushqrdx: nix-build '<nixpkgs>' -A wine
<clever> pushqrdx: also, if your testing, build with nix-build, not nix-env
<clever> pushqrdx: that could just be the dependencies within the makefile
<clever> pushqrdx: it looks pretty ugly, it runs 2 full builds (each with its own configure, build, install), in the same derivation
<clever> pushqrdx: `nix show-config | grep cores` ?
<clever> pushqrdx: its passing you the old value of every attr, so you can do old.buildInputs ++ []
<clever> pushqrdx: thats what the old: is for
<clever> pushqrdx: append to buildInputs like normal
<clever> :D
<clever> pushqrdx: because it didnt have a #!
<clever> the builder is already set to bash
<clever> pushqrdx: args = [ "-e" ./my-local-copy.sh ];
<clever> pushqrdx: overrideDerivation happens later, this is why its deprecated :P
<clever> pushqrdx: stdenv.mkDerivation mangles the builder, and turns it into args!!
<clever> pushqrdx: oh, no, you want args!
<clever> pushqrdx: you need to +x the file
<clever> pushqrdx: yeah
<clever> pushqrdx: you can just set builder, since your already using overrideDerivation
<clever> pushqrdx: the overrides must be done in the right order, the result of overrideDerivation lacks a .override
<clever> pushqrdx: either .override buildScript, or .overrideDerivation builder
<clever> but overrideDerivation happens after that, so you have to override builder instead
<clever> pushqrdx: base.nix puts it into builder
<clever> 15 stdenv.mkDerivation ((lib.optionalAttrs (buildScript != null) {
<clever> 16 builder = buildScript;
<clever> pushqrdx: it would create a $buildScript env var, that does nothing
<clever> veleiro: `programs.*` is just a collection of nixos options, some of them may create config in /etc or add a package to systemPackages for you
<clever> pushqrdx: youll need to edit a copy of builder-wow.sh, and then override the buildScript attr, with .override i think
<clever> pkgs/misc/emulators/wine/packages.nix: buildScript = ./builder-wow.sh;
<clever> pushqrdx: yeah, this derivation is just nasty
<clever> thats why you never use builder, lol
<clever> pushqrdx: the builder script overrides the flags, right before it runs configurePhase, so you can never change them
<clever> 15 configurePhase
<clever> 14 configureFlags="--enable-win64"
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ vi pkgs/misc/emulators/wine/builder-wow.sh
<clever> pushqrdx: and theres your problem
<clever> then check if the configureFlags are what you expected
<clever> pushqrdx: run that on your final .drv file, after the override, `nix-instantiate '<nixpkgs>' -A wine`
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ nix show-derivation /nix/store/93q3f3mgm1rjmn0iy802lcb0x33cfkaz-wine-wow-5.22-staging.drv
<clever> ,callPackage matthewcroughan
<clever> hodapp: i think it will use pam and your main login pw, to try to unlock gnome keyrings
<clever> hodapp: `security.pam.services.gdm.enableGnomeKeyring` just messes with pam config files, but doesnt add things to dbus
<clever> maybe
<clever> hodapp: i think an app that provides that service, must be listed in services.dbus.packages
<clever> lol
<clever> :D
<clever> ,locate
<clever> pushqrdx: copy/paste from a terminal window
<clever> pushqrdx: so you must override postPatch = "";
<clever> pushqrdx: staging ignores the patches array, and starts adding its own patches using postPatch!
<clever> 17 cp -r ${patch}/patches .
<clever> 15 postPatch = self.postPatch or "" + ''
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ vi pkgs/misc/emulators/wine/staging.nix
<clever> pushqrdx: can you pastebin the entire output?
<clever> 2020-12-23 15:51:08 < clever> pushqrdx: staging uses the older overrideDerivation, which deletes the newer overrideAttrs
<clever> pushqrdx: so you must instead set the old name attr
<clever> pushqrdx: overrideDerivation happens later, and doesnt support pname/version
<clever> pushqrdx: thats to be expected
<clever> so you still have access to the original wine
<clever> but you could name it wine-staging-wayland
<clever> you named it wine, so nix-env -iA nixos.wine
<clever> pushqrdx: the name on the left of the = is what you install
<clever> you also dont need rec on that
<clever> yep
<clever> pushqrdx: try just wineWowPackages.staging.overrideDerivation (old: { src = ...; });
<clever> pushqrdx: staging uses the older overrideDerivation, which deletes the newer overrideAttrs
<clever> 10 (stdenv.lib.overrideDerivation wineUnstable (self: {
<clever> [clever@amd-nixos:~/apps/nixpkgs-hasura]$ vi pkgs/misc/emulators/wine/staging.nix
<clever> pushqrdx: aha, found the problem
<clever> pushqrdx: try using this one, without .override
<clever> nix-repl> wineWowPackages.staging.overrideDerivation
<clever> «lambda @ /home/clever/apps/nixpkgs-hasura/lib/customisation.nix:84:32»
<clever> 28544 wineWowPackages = recurseIntoAttrs (winePackagesFor "wineWow");
<clever> 28546 wine = winePackages.full;
<clever> 28534 winePackagesFor = wineBuild: lib.makeExtensible (self: with self; {
<clever> *looks*
<clever> it fails when i set those attrs...
<clever> oh, interesting
<clever> pushqrdx: can you pastebin the entire overlays.nix?
<clever> pushqrdx: do you have other overlays, that are also changing wine? how is this overlay loaded? what is the exact error?
<clever> joko: nope
<clever> nix-repl> (wine.overrideAttrs (old: {})).overrideAttrs (old: {})
<clever> «derivation /nix/store/gppp531i6xk1pfsq5890nz144v0w45q2-wine-5.0.drv»
<clever> > (wine.override {}).overrideAttrs (old: {})
<clever> pushqrdx: you need to swap .override and overrideAttrs
<clever> in this case, its vc4/vpu assembly
<clever> it gets ran thru binutils as, to turn it into binary
<clever> .S is just assembly
<clever> .S files are raw assembly code
<clever> matthewcroughan: this is the first opcode to run, that i can control, so all execution of the open firmware starts there
<clever> and some low level arm config registers, to allow floating point and mutexes
<clever> then fix a gpio bug involving the reset pin of the usb hub
<clever> i had to add initrd support to the bootloader, and then replace the missing device-tree files
<clever> matthewcroughan: and thats what i'm doing, it already boots on pi2 and pi3
<clever> matthewcroughan: because the whole point is to get rid of the closed-source blobs :P
<clever> matthewcroughan: the blobs are not involved at any stage in the boot
<clever> matthewcroughan: the firmware i'm using doesnt even support config.txt
<clever> matthewcroughan: this thread shows the commands to build most of it, and links to the github
<clever> yeah
<clever> its not even reaching /init in the initrd
<clever> its failing during boot, it cant have used more then 20mb of ram
<clever> i have never gotten it to work on a pi1 with the open firmware
<clever> matthewcroughan: already using that fork, but with a custom .config file
<clever> matthewcroughan: ive got it working on pi2 and pi3 without too much trouble, but pi1 is still giving troubles
<clever> matthewcroughan: rpi1, with custom firmware and kernel
<clever> program counter
<clever> [ 2.498077] PC is at bpf_prog_alloc+0x94/0xdc
<clever> [ 2.465971] Unable to handle kernel NULL pointer dereference at virtual address 0000003c
<clever> matthewcroughan: got any clue about this error? heh
<clever> [ 0.210464] pagealloc: memory corruption
<clever> [ 0.214480] (ptrval): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
<clever> youll need to either patchelf or buildfhsenv
<clever> matthewcroughan: and /lib64/ld-linux-x86-64.so.2 doesnt exist, so attempting to run parsecd will report "file not found"
<clever> matthewcroughan: what does `file` say when ran on it?
<clever> matthewcroughan: because /lib doesnt even exist
<clever> matthewcroughan: some of those are in the wayland package, just pop wayland into the buildInputs
<clever> ,locate libwayland-cursor
<clever> ,locate libGLES_CM.so
<clever> lordcirth: and the default is 2.7 still...
<clever> > python
<clever> sphalerite: toss it into a let block and accept that youll need a ? or an if?
<clever> v0|d: i find `iptables-save` to be a lot more readable
<clever> i dont think there are any closer constants
<clever> ehhh, half there
<clever> > python.pythonVersion
<clever> v0|d: but if the service is dynamically mutating chains at runtime, thats a more complex issue...
<clever> > python3.isPy2
<clever> sphalerite: is that good enough?
<clever> > python3.isPy3
<clever> you can abuse `nix-store --dump foo > foo.nar` and `nix-store --restore foo < foo.nar` as a tar replacement
<clever> qyliss: nix uses nar instead of tar, which just lacks timestamp support
<clever> qyliss: it will also have last-mod timestamps on all the files, ruining the reproducability
<clever> j4m3s__: it will serialize the entire directory (nix-store --dump /var/empty/ | hexdump -C) and then hash the serialized form
<clever> there are settings in steam itself, to allow using proton with games that arent in the whitelist of "known working"
<clever> for me, i just run steam, and proton is fully automatic

2020-12-21

<clever> and it will only work with <nixpkgs/nixos>
<clever> and foo isnt a valid root key, only config/imports/options are valid root keys
<clever> once you set config.bar, config isnt missing
<clever> 2020-12-21 16:21:52 < clever> if both options and config are missing, your module gets wrapped in config automatically
<clever> and everything blows up :P
<clever> so you set { foo = 42; config.bar = 24; }
<clever> then you see some places refering to config.bar
<clever> that also tripped me up, because when you do { foo = 42; } it works
<clever> so if a module returns { foo = 42; }, the module system will behave as-if you had done { config = { foo = 42; }; }
<clever> if both options and config are missing, your module gets wrapped in config automatically