2020-09-29

<clever> fzakaria: you can either change the name to nix-prefetch-url as you just did, or you can change the name to fetchTarball to source
<clever> fzakaria: basically, $out is based on the sha256 and the name
<clever> fzakaria: that is the default name as well
<clever> fzakaria: the name must be "source" for it to align correctly
<clever> fzakaria: and in nix, how did you try to fetch the same file?
<clever> fzakaria: what args did you run the fetch with?
<clever> evalexpr: builtins.toFile is as cheap as ./foo.txt, but cant have any dependencies
<clever> evalexpr: pkgs.writeText is a full derivation, so its more costly, having to fork out a child, setup a full sandbox, and possibly copy deps to a remote ARM machine
<clever> fzakaria: nix-pfetch-url is only for derivationx, builtins.fetchurl and builtins.fetchTarball arent derivations
<clever> maurer: does the firmware exist in /run/current-system/firmware ?
<clever> function and path actually
<clever> > :p [ import ./. ]
<clever> you must add () around the import and the path
<clever> that is a list with 2 functions
<clever> maurer: nixpkgs.overlays must be a list of overlays
<clever> maurer: and how did you add it to the system?
<clever> maurer: what is the content of iwlwifi-firmware-blocklist.nix, how did you add it?
<clever> pinpox: its a bit hidden, because environment.etc isnt meant to work like that, but it does work
<clever> pinpox: environment.etc."foo".target = "/path/to/real/secret";
<clever> maurer: then it will impact the default value and you dont need an mkForce
<clever> maurer: try instead doing an overlay, that sets `firmwareLinuxNonfree = super.firmwareLinuxNonfree.overrideAttrs (old: { postInstall = ''...''; });`
<clever> pinpox: `man configuration.nix` then `/wireguard`
<clever> pinpox: package options cant be listed easily, but module options can be
<clever> pinpox: `man configuration.nix` and search with `/`
<clever> then nix deals with the spread of different dirs, and you only have to copy secrets to one spot
<clever> pinpox: simplest option there is to put all of the secrets in one place, then have nix create symlinks to it, so /etc/wireguard/privatekey is a link to /etc/secrets/wg_priv for example
<clever> pinpox: the simplest option is to just copy secrets to the right path by hand, almost anything you do with nix gets copied to /nix/store and made world readable
<clever> __monty__: ah, 0x27 is '!
<clever> json always uses "
<clever> blame somebody for using a non-english layout :P
<clever> "name": "AMD\u0027s plpa_map.c License",
<clever> nix (Nix) 3.0pre20200829_f156513
<clever> __monty__: works perfectly fine on this end
<clever> [clever@amd-nixos:~/apps/rpi/rpi-open-firmware]$ nix-instantiate --eval -E 'builtins.fromJSON (builtins.readFile (builtins.fetchurl https://spdx.org/licenses/licenses.json))'
<clever> __monty__: can you pastebin the json?
<clever> __monty__: pipe the same json thru jq?
<clever> tobiasBora: it will take the entire $out and serialize it into a nar, then grep that nar stream for each input
<clever> tobiasBora: if you copy the file, then the path of the original wont be in the output
<clever> tobiasBora: nix tracks dependencies by seeing if you refer to a file in your output
<clever> tobiasBora: you can verify that with `nix-store --query --roots` and `nix why-depends /nix/store/a /bix/store/b`
<clever> tobiasBora: if you copy the script, then it should allow deleting it
<clever> but depending on the source of the module, writing may not have any effect
<clever> tobiasBora: each file in here matches one parameter in the module, and sometimes they are writable
<clever> [root@amd-nixos:~]# ls /sys/module/zfs/parameters/
<clever> tobiasBora: for some modules, you can manually change options after loading, but it depends on the module
<clever> tobiasBora: correct
<clever> tobiasBora: but some systemd services like wireguard will force a `modprobe wg` before starting the service
<clever> tobiasBora: nothing automated
<clever> tobiasBora: rebooting is the windows way of fixing it, just ignore how load things properly and reset it all!
<clever> tobiasBora: extraModprobeConfig only applies when a module loads, so you may need to unload and then re-load the module for it to take effect
<clever> tobiasBora: kernelModules only applies at boot, but you can manually modprobe to force it
<clever> eyJhb: i would usually prefer to build each src in its own derivation, and depend on the others like normal
<clever> eyJhb: they should all have a single common root dir, or it wont merge right
<clever> eyJhb: if you give it a list as srcs, it will just unpack all of them, and then try to guess what to cd into
<clever> and now your striping between 2 partitions on the same disk, causing it to seek constantly
<clever> zfs will try to stripe all writes between the vdev's
<clever> that would likely cause performance to tank
<clever> gchristensen: would that new vdev be a 2nd partition on the same EBS?
<clever> tobiasBora: go ahead, it all came from `man configuration.nix` anyways
<clever> Henson: heh, was about to ask if you used kexec!
<clever> tobiasBora: yeah
<clever> tobiasBora: then modprobe does the default args for you
<clever> Any additional configuration to be appended to the generated modprobe.conf. This is typically used to specify module options. See modprobe.d(5) for details.
<clever> boot.extraModprobeConfig
<clever> The set of kernel modules to be loaded in the second stage of the boot process. Note that modules that are needed to mount the root file system should be added to boot.initrd.availableKernelModules or boot.initrd.kernelModules.
<clever> boot.kernelModules
<clever> tobiasBora: boot.extraModulePackages just puts it into the search path for modprobe
<clever> betaboon: there is also `nix-build -Q`
<clever> betaboon: nix build -f '<my-nixpkgs-fork>' -I nixos-config=./my-configuration.nix config.system.build.toplevel
<clever> sneaktest: `nix-env -q` lists the names of the packages

2020-09-27

<clever> if that was in the prompt, you would at least know when your nesting things
<clever> there is also this var, that gets incremented each time you launch a shell in a shell
<clever> [clever@amd-nixos:~]$ echo $SHLVL
<clever> 2
<clever> yep
<clever> then youll want the unpackPhase
<clever> also, if you do `--keep-failed`, and it fails for any reason (like a stray `exit 1`) it wlll leave the temp dir in /tmp
<clever> then you can see what it did
<clever> you can verify that by just setting `configurePhase = "find ; exit 1";`
<clever> yeah
<clever> and the default sourceRoot will then be source
<clever> all of them will be named source then, so youll just get each repo mashed together, all in source/
<clever> ah, that would be giving it directories rather then tars
<clever> and if you run `tar -tvf` on each tar, what do the paths start with?
<clever> mthst: what are you trying to get done?
<clever> mthst: that would probably not do what you want
<clever> and fail if it created multiple dirs
<clever> mthst: ah, it will just run unpackFile on each thing in $srcs, and then try to guess the $sourceRoot by seeing what dir it created
<clever> mthst: the .nix file that made that output is in the same dir, with the same name
<clever> the stdenv only deals with $src
<clever> those attributes just become env vars at build time
<clever> mkDerivation accepts anything as an attribute
<clever> yeah
<clever> mthst: the default only accepts a single path in $src
<clever> mthst: the default unpackPhase copies the $src to . and will chmod it
<clever> ,libraries flythief_
<clever> flythief_: you dont

2020-09-26

<clever> testonaut: if you delete ~/.xinitrc, does it behave differently?
<clever> testonaut: that might be the problem then, ive only ever used X with a display manager
<clever> testonaut: when at the login screen, you should also have an option to select between the different window managers
<clever> testonaut: you can also just services.xserver.windowManager.i3.enable = true;
<clever> testonaut: but using the ....displayManager.sessionCommands option, you can also inject your own things with configuration.nix
<clever> testonaut: line 87 is what will source ~/.xprofile, and line 95 will execute ~/.xsession, overriding the default actions down on 100
<clever> one sec
<clever> testonaut: yes
<clever> reptarmigan: probably the lower need to match your { and } up, just indent things right
<clever> testonaut: yes
<clever> reptarmigan: builtins.toJSON and your done!
<clever> reptarmigan: yaml is a superset of json, so anything that accepts yaml, can also accept json

2020-09-25

<clever> evanjs: can you pastebin the nix expr?
<clever> aforemny: that makes the known hosts system wide, and lets me pre-load hosts i know of into every system
<clever> aforemny: i prefer using programs.ssh.knownHosts
<clever> aforemny: --argstr system only has an effect if you accept an arg called system, at the top-level
<clever> aforemny: depends, does the default.nix your loading have a top-level { system }: function?
<clever> aforemny: when you import <nixpkgs> you must set system = "aarch64-linux";
<clever> ptival[m]: if you run `nix show-derivation` on the drv, does it have an installPhase?
<clever> jasom: when i wrote a nixos module for that, i skipped the perl layer entirely, so there is no way to specify textual config, the binary that parses it is never ran!
<clever> jasom: but neither of those even support its own config file, instead, tgt-admin (a perl script) parses the config, and runs tgtadm to configure the daemon!!
<clever> jasom: tgtd is the daemon itself, and tgtadm is a binary to control the daemon over an rpc
<clever> jasom: on that subject, i found tgtd to be rather weird, it has both tgtadm and tgt-admin
<clever> ive been using the gcc fork for vc4, and i'm wondering how different the llvm codegen would be
<clever> fzakaria: ive been wanting to try out the VC4 llvm fork, but have never gotten around to it

2020-09-24

<clever> roconnor: --include-outputs
<clever> roconnor: check the manpage of nix-copy-closure
<clever> lordcirth_: its not squid, but instead a custom haskell program, that is aware of the binary cache api, and has no cache expiry policy

2020-09-23

<clever> cole-h: the sandbox code still clears the var, so it wont leak into the build
<clever> cole-h: one handy trick, is that things like `sudo nix-build --option builders foo`, will let SSH_AUTH_SOCK leak a little, and then nix can ssh into foo via your agent
<clever> cole-h: yep
<clever> cole-h: no need to stop the daemon either, if your root, it wont use the daemon
<clever> i havent seen that before
<clever> mvnetbiz_: yeah, activate is just the module system concat'ing every activation script together
<clever> mvnetbiz_: i think the activate script is mostly auto-generated, while switch-to-configuration is static
<clever> mvnetbiz_: also, switch-to-configuration is whats responsible for restarting all of the changes systemd services, activate mostly just handles state like /etc/ updates
<clever> edef: thats config.system.build.installBootLoader being ran by switch-to-configuration, before activate gets ran
<clever> edef: those arent activation scripts
<clever> edef: which activation script?
<clever> cole-h: yeah, you need write access to most of /nix to do a build
<clever> switch and test, will also run activate
<clever> switch and boot, will then update the bootloader
<clever> it takes the normal boot|switch|test args, same as nixos-rebuild
<clever> you must usw the bin/switch-to-configuration script
<clever> ah, that wont update the bootloader at all
<clever> mvnetbiz_: how did you activate the new generation?
<clever> mvnetbiz_: systemd-boot has an anoying feature where you can hit a certain key at the boot menu, to lock it to a certain generation, and it wont boot the default anymore until you hit that key again
<clever> mvnetbiz_: you might need `NIXOS_INSTALL_BOOTLOADER=1 switch-to-configuration switch`, to update those things
<clever> mvnetbiz_: or how /boot is mounted?
<clever> mvnetbiz_: oh, did you change which bootloader your using?
<clever> mvnetbiz_: do you have a new symlink/generation in /nix/var/nix/profiles/? that is pointing to the new path?
<clever> but the example i was going to grab, got removed 17 days ago!, so you now have to refer to the red side of a diff! heh
<clever> esclear_m: the other method is to just use mkForce to set wantedBy to an empty list, then it wont be wanted by multi-user.target, so it wont run on boot
<clever> azazel: that might cause the .service file to not generate
<clever> esclear_m: one minute
<clever> evanjs: then result/bin/qemu_test2 to boot from the disk without the livecd
<clever> evanjs: nix-build simple-test.nix -A legacy_virtio then run result/bin/qemu_test1 to boot a livecd of sorts, justdoit will be pre-configured to install nixos to /dev/vda with zfs+mbr+grub, or install manually yourself
<clever> before you run <thatpath>/bin/switch-to-configuration switch
<clever> mvnetbiz_: nix-env --profile /nix/var/nix/profiles/system --set <thatpath>
<clever> evanjs: if you want that kind of testing, you need to run qemu on a disk image normally, and install nixos as normal
<clever> evanjs: the dynamically generated qemu vm that shares the host store, isnt really able to reinstall the bootloader
<clever> gchristensen: that allows fetching a tarball with a flake.nix, and building it
<clever> gchristensen: and systemd.services.amazon-shell-init is based on amazon-init.nix, but instead of you supplying a configuration.nix, you just supply a shell script in the userdata
<clever> gchristensen: you also need to include the zfs-runtime module in your configuration.nix, or the machine wont be able to boot anymore
<clever> i need to add dropbear to the initrd, make it hang, and then ssh into the initrd, to debug
<clever> the tricky part, is that each test, requires uploading a new 3gig ami to aws
<clever> nahamu: it just silently has no effect, but when ran manually after boot it works
<clever> gchristensen: thats a fragment of another flake.nix, that was depending on ops-lib/zfs/flake.nix
<clever> nahamu: already resizing the partition, and then running `zpool online -e`, but the pool itself doesnt expand
<clever> gchristensen: its in a flake now!, but auto-resize is still bugged
<clever> looks like some clouds are rolling in.....
<clever> evanjs: or use a more complete install that doesnt share the host store, and just functions normally
<clever> evanjs: you need to add qemu-vm.nix to the imports, its in nixpkgs
<clever> eyJhb: buildEnv

2020-09-22

<clever> cole-h: --arg is a lot more complicated then it seems
<clever> cole-h: --arg config '{allowUnfree = true; }'
<clever> Taneb: that happens if qemu cant connect to the guest, fire up tcpdump within the guest to see why
<clever> so you must wrap it with another ()
<clever> > [ ((pkgs.haskell.packages.ghc882.extend (self: super: {})).ghc.withPackages (ps: [])) ]
<clever> ghasshee: BUT, if you ever put that into a list, its 2 functions!
<clever> > [ (pkgs.haskell.packages.ghc882.extend (self: super: {})).ghc.withPackages (ps: []) ]
<clever> so if evalled normally, its a derivation that gives you ghc
<clever> > (pkgs.haskell.packages.ghc882.extend (self: super: {})).ghc.withPackages (ps: [])
<clever> oh wait, the withPackages
<clever> if evalled normally, it gives a set of every haskell package
<clever> > (pkgs.haskell.packages.ghc882.override (self: super: {})).ghc.withPackages (ps: [])
<clever> > (pkgs.haskell.packages.ghc882.override (self: super: {})).ghc.withPackages (ps: [...])
<clever> ghasshee: just stick another ( at the front, and a ) at the very end
<clever> the main downside to extend, is that it deletes override
<clever> maralorn: there is a way to do it with .override (old: { overrides ... }) but then you have to merge the overlays yourself, and it gets ugly
<clever> maralorn: but .override cant chain, so if you .override again, you replace the old overrides, and loose that overlay
<clever> maralorn: override changes the args callPackage is supplying, one of which is overrides, so you can do `pkgs.haskell.packages.ghc882.override { overrides = overlay; }`
<clever> maralorn: extend takes an overlay, and you can keep chaining it, so you can do `(pkgs.haskell.packages.ghc882.extend overlay1).extend overlay2`
<clever> ghasshee: you may need to wrap it with another () if its inside a list
<clever> Taneb: you can also build it more easily with `nix-build '<nixpkgs/nixos>' --arg configuration ./configuration.nix -A vm`
<clever> Taneb: i forget the exact option, but you need to use something like: qemu.networkingOptions = [ "-net" "user,hostfwd=tcp:127.0.0.2:2222-:22" "-net" "nic" ];
<clever> Taneb: one sec
<clever> instead of `import <nixpgks> {}`
<clever> you can also edit the pkgs.nix that is doing the callPackage, to fetch it with fetchTarball
<clever> and it will use that version for <nixpkgs>
<clever> then add `-I nixpkgs=https://github.com/nixos/nixpkgs/archive/e80d29221325f056f47ef4bfc0a11772b65cba54.tar.gz`
<clever> or fix osgEarth to work on 3.8.1
<clever> then youll need to either find a 3.8.0 geos in nixpkgs history, or override geos to 3.8.0
<clever> ahh
<clever> first, do `nix eval -f '<nixpkgs>' lib.version` on the ubuntu machine
<clever> simplest option is to use the same nixpkgs
<clever> and on ubuntu it builds?
<clever> eyJhb: thats why i said "on both"
<clever> eyJhb: what is the output to a successful build?
<clever> but if its the same verison on both, it should be fine...
<clever> 27 | # warning "HINT: #include geos_c.h"
<clever> 26 | # warning "The GEOS C++ API is unstable, please use the C API instead"
<clever> but what version does it give, on both?
<clever> eyJhb: does `nix-build '<nixpkgs>' -A geos` give the same version on both?
<clever> eyJhb: it refers to geos in the nix store
<clever> eyJhb: the error may depend on which version <nixpkgs> maps to
<clever> eyJhb: is perl in the buildInputs ?
<clever> eyJhb: what is it trying to run? the word after /usr/bin/env
<clever> eyJhb: yes
<clever> eyJhb: postPatch = "patchShebangs bin";
<clever> default also depends on osgearth, so youll only get that if you use pkgs.nix
<clever> nix-env -f pkgs.nix -iA omnetpp
<clever> pkgs.nix is already doing callPackage for you
<clever> ah, id use sed then
<clever> though, only if its in a #!
<clever> zecnate: that feels like something patchShebangs should already support

2020-09-21

<clever> you can run nix repl on the file, and then just eval any attr
<clever> zecnate: lib.commitIdFromGitRepo can also do it
<clever> zecnate: builtins.fetchGit ./. will return a set containing the git rev
<clever> zecnate: https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh#L952 is the default way configure gets ran
<clever> zecnate: nixpkgs manual
<clever> zecnate: configureFlags = [ "--foo" ];
<clever> /lib
<clever> i think you want ${glib.out}
<clever> if you `echo $LD_LIBRARY_PATH`, what is the path for glib?
<clever> what other files are in that directory?
<clever> what is the name of that file?
<clever> the one in env/lib/python3.6/site-pack....
<clever> what is the filename?
<clever> https://usercontent.irccloud-cdn.com/file/flgpH0Xf/1600674116.JPG what is the filename on the bottom of the backtrace?
<clever> but the opencv nix gives you, will just work
<clever> i suspect that the opencv you got from virtualenv is "broken" and wont work with nix
<clever> add that to the python.withPackages ?
<clever> what other stuff?
<clever> have you tried not doing `source env/bin/activate` when you open the shell?
<clever> how is it importing it?
<clever> it needs which file?
<clever> what is the problematic line doing?
<clever> run the ldd command on that path
<clever> if you run ldd on that library, what does it say?
<clever> (the image cut the filename off)
<clever> and what is line ?? of ?? doing ?
<clever> Peter_Storm: what is the error?
<clever> you forgot the export keyword
<clever> you may need to set LD_LIBRARY_PATH=${glib}/lib in the shellHook then
<clever> ,libraries Peter_Storm
<clever> did you add glib to the buildInputs ?
<clever> Peter_Storm: installing it wont make it available to everything, try `nix-shell -p glib`
<clever> Peter_Storm: its in glib
<clever> ,locate libgthread
<clever> zecnate: yeah
<clever> that would be in the nixpkgs manual
<clever> it also adds helpers like overrideAttrs to that derivation
<clever> stdenv.mkDerivation is a function that takes a set of attributes, and makes a derivation
<clever> it will be in the nixpkgs manual
<clever> matthewcroughan: stdenv.mkDerivation adds it to every single package
<clever> in `nix repl '<nixpkgs>'` do `dolphinEmuMaster.<tab><tab>`
<clever> and that
<clever> > builtins.attrNames dolphinEmuMaster
<clever> tab completion, docs
<clever> you give it another function, which takes a set, and returns the things to change
<clever> a function, to override the attributes of dolphinEmuMaster
<clever> thats not the src you wanted, and because of pkgs.src exists, it leaked in and covered the scr mistake
<clever> > :p let scr = "something important"; in { src = src; }
<clever> > let scr = "something important"; in { src = src; }
<clever> for example, there is a package called "src", so if you try to do `src = src;` and then mistype src in the let block
<clever> > pkgs.src.meta.description
<clever> > src
<clever> if you mis-spell a variable from the let block, and such a variable happens to be a valid package, you get the wrong thing, instead of an error
<clever> with pkgs; let foo = "foo"; in fop
<clever> the `with` problem is more about this:
<clever> matthewcroughan: it is functional, its just a function, that takes an arg
<clever> you wont know until you give it an x, and the answer can differ, depending on what x is
<clever> but now there is a with, so b might be in x
<clever> [root@amd-nixos:~]# nix-instantiate --parse -E 'x: with x; { a=b; }'
<clever> (x: (with x; { a = b; }))
<clever> matthewcroughan: there was no with statement, so it knew that b doesnt exist, without even knowing what x was
<clever> 1| x: { a=b; }
<clever> UndefinedVarError
<clever> [root@amd-nixos:~]# nix-instantiate --parse -E 'x: { a=b; }'
<clever> rec slightly complicates the parsing, and i think defers things to eval time