2020-05-10

<clever> energizer: nixpkgs-unstable tests fewer things, and doesnt test if grub does wonky things like not boot
<clever> energizer: for non-nixos machines, you can use nixpkgs-unstable
<clever> pie_: it does the same thing as extend
<clever> > gnome3.overrideScope'
<clever> mpiechotka: can you pastebin the whole configuration.nix file?
<clever> mpiechotka: which stable?
<clever> mpiechotka: which channel are you on?
<clever> mpiechotka: overrideScope got the args backwards, super: self: {, so overrideScope' was added to fix the order
<clever> mpiechotka: it is deliberate
<clever> mpiechotka: that will replace pkgs.gnome3, with the result of applying a "gnome overlay" to gnome3
<clever> mpiechotka: so you want to do, self: super: { gnome3 = super.overrideScope' (gself: gsuper: { mutter = gsuper.mutter ....; }); }
<clever> mpiechotka: for my laptop, its /etc/wpa_supplicant.conf
<clever> mpiechotka: mutter is at gnome3.mutter
<clever> ,locate bin mutter
<clever> matthewcroughan: and "opting in" as well
<clever> matthewcroughan: read the "opting out" section of that page
<clever> matthewcroughan: if you dont, you risk getting stuck unable to nixos-rebuild because you need wifi to get wifi
<clever> matthewcroughan: then you need to tell nixos to symlink /etc/wpa_supplicant.conf to your mutable directory
<clever> matthewcroughan: its just a regular file in /etc/
<clever> matthewcroughan: nixos wont delete it
<clever> matthewcroughan: the pw is already in /etc/wpa_supplicant.conf
<clever> matthewcroughan: so i have to edit and maintain /etc/wpa_supplicant.conf manually, outside of configuration.nix
<clever> matthewcroughan: i enable wpa_supplicant, but i dont give configuration.nix the pw
<clever> mpiechotka: did pkgs.mutter work before you added the overlay?
<clever> matthewcroughan: i prefer nixos to not manage wpa_supplicant.conf, so i can change the pw without having wifi working
<clever> mpiechotka: it doesnt exist at that name
<clever> > pkgs.mutter
<clever> mpiechotka: it will only build if you then do pkgs.package somewhere,with the same name you did against the override
<clever> mpiechotka: oops, ^^^
<clever> morgrimm: nixpkgs.overlays = [ (self: super: { package = super.package.overrideAttrs (old: { ... }); }) ];
<clever> energizer: the mst you could do, is check what the root device is, against your config, and then stop before you continue
<clever> energizer: not easily, because you have to boot the real hw and format things to test it all
<clever> energizer: nope
<clever> energizer: which is included in the kexec image, but you need to configure it righ before you make the tar
<clever> energizer: justdoit.nix
<clever> morgrimm: more a question of how much non-free code you want to pull in and never actually use
<clever> morgrimm: you can also be cheap and manually put only firmwareLinuxNonfree into hardware.firmware, if you dont want the rest
<clever> morgrimm: both enableAllFirmware and enableRedistributableFirmware will include that
<clever> energizer: but once you format the disk, there is no hope of it booting on its own until you complete the nixos-install without any mistakes
<clever> energizer: kexec itself is relatively low risk, it rarely crashes, and even if you lock yourself out, the default config will reboot the machine at the end of the hour, restoring the original OS
<clever> morgrimm: then just search nixpkgs for that name
<clever> morgrimm: if you run ls -lh on the firmware from an old generation, youll get the derivation name
<clever> morgrimm: if you know which file you need, you can also add it to hardware.firmware with the right pkg
<clever> morgrimm: try one of these options like enableAllFirmware and see what happens
<clever> ,stateVersion EdLin
<clever> EdLin: `sudo nix-channel --list` to see which channel your on, and
<clever> EdLin: yeah
<clever> matthewcroughan: whichever process is trying to read /proc/self/
<clever> EdLin: that will update to whatever is latest for your channel, but not change the channel
<clever> morgrimm: check older generations to see if they have the file you need
<clever> morgrimm: if you look in /nix/var/nix/profiles/system-42-link/firmware you can also see how the firmware looked in past generations
<clever> morgrimm: do you see the firmware in /run/current-system/firmware ?
<clever> matthewcroughan: and /proc/self/fd/3 is a magic symlink, that results to the 3rd open file for the current process
<clever> matthewcroughan: /proc/self is a magic symlink, that always resolves to /proc/<pid> for the pid doing the read
<clever> dont bother writing it to a file
<clever> matthewcroughan: if you want to see the contents, just `foo` by itself
<clever> ex-parrot: you may also want "$(foo)" or newlines and spaces get messed up
<clever> matthewcroughan: `ls -lh <(echo foo)`
<clever> ex-parrot: try with ls -lh!
<clever> matthewcroughan: wpa_passphrase 'SSID' 'key' | sudo tee -a /etc/wpa_supplicant.conf ; sudo wpa_supplicant -B -i interface -c /etc/wpa_supplicant.conf
<clever> matthewcroughan: write the thing to a normal file first, and then just give it the filename
<clever> case sensitive
<clever> dxtr: fetchFromGitHub
<clever> and it didnt get both, so it omited the name
<clever> you left out the version in the example
<clever> ah
<clever> your nixpkgs version claims to be 210d8624ac4, but i cant find that in git
<clever> maybe buildGoModule is diff
<clever> dxtr: so it basically didnt have any name=
<clever> dxtr: sounds like your nixpkgs is too old to automate `name = "${pname}-${version}";`
<clever> dxtr: can you pastebin the nix file after your changes?
<clever> dxtr: what does `nix eval nixpkgs.lib.version` say?
<clever> that does extra go related things
<clever> dxtr: buildGoModule is a wrapper around stdenv.mkDerivation
<clever> dxtr: what do you have in the nix file?
<clever> dxtr: did you call stdenv.mkDerivation without a name="name"; ?
<clever> dxtr: and you need to remove the old line 1 that had things like { lib }:
<clever> infinisil: in this case, i would just add `with import <nixpkgs> {};` to the file, to not need callPackage anymore
<clever> cole-h: the help text got changed to be a bit less helpful
<clever> dxtr: you can either use -E like that, or you can put `with import <nixpkgs> {};` on the 1st line of your default.nix
<clever> dxtr: `nix-build` with no args, will load default.nix from the cwd by default

2020-05-09

<clever> c4rc4s: i see it right in the top-level, so try `nix-build '<nixpkgs>' -A obs-v4l2sink` ?
<clever> pkgs/top-level/all-packages.nix: obs-v4l2sink = libsForQt5.callPackage ../applications/video/obs-studio/v4l2sink.nix { };
<clever> c4rc4s: id say start by greping nixpkgs, to see what is loading it
<clever> qcow is the name you want, to get qcow2
<clever> numkem: ah, was it saying something about how qcow2 in search path does not exist?
<clever> file*
<clever> numkem: no, it should be pointing to a dir under formats
<clever> numkem: it should be doing -I format-config= for you
<clever> numkem: likely one of the files under formats
<clever> numkem: and thats just inserted into the modules on line 20, so it must point to a nixos module
<clever> numkem: yep, its doing <format-config>
<clever> numkem: something is doing <format-config> somewhere, and it probably wants you do `-I format-config=./something`
<clever> balsoft: hydra will also try to build it for all platforms, that are enabled within hydra
<clever> balsoft: nixpkgs will automatically block trying to build a package on an OS where meta.platforms doesnt list it
<clever> exarkun: weird
<clever> WoC: there is also `nix search something`
<clever> WoC: but i'm on unstable, so my cmd listed the exact url you want
<clever> [root@amd-nixos:~]# nix-channel --list
<clever> probably
<clever> spinlock[m]: thats the setuid wrapper that is missing
<clever> home-manager is limited to your home folder
<clever> spinlock[m]: home-manager cant touch the system dbus config
<clever> spinlock[m]: it also configures other things, like a setuid binary
<clever> spinlock[m]: services.gnome3.gnome-keyring.enable = true; would do that for you
<clever> 32 config = mkIf config.services.gnome3.gnome-keyring.enable {
<clever> /home/clever/apps/nixpkgs/nixos/modules/services/desktops/gnome3/gnome-keyring.nix: services.dbus.packages = [ pkgs.gnome3.gnome-keyring pkgs.gcr ];
<clever> when you do programs.foo.enable = true;
<clever> spinlock[m]: the nixos module for the app should be doing it
<clever> hexa-: usually, anything that is offering some kind of service via dbus
<clever> yeah
<clever> exarkun: what does `nix-store --verify --check-contents` say?
<clever> exarkun: every time you run nix-build, it will hash ./. and copy it into /nix/store/
<clever> exarkun: everything points towards you just having not ran nix-build...
<clever> exarkun: in postCheck in your expr, try to cat the .py file, do you see the right version?
<clever> exarkun: are the tests actually being ran by nix?
<clever> exarkun: try adding postUnpack = "exit 1"; to the derivation, then build it with --keep-failed, and diff the src in the /tmp dir to the original
<clever> exarkun: how are you checking that its older?
<clever> monokrome: which files are out of date?
<clever> exarkun: can you pastebin the expr?
<clever> monokrome: one min...
<clever> monokrome: yeah
<clever> monokrome: the motherboard also came with hdmi out onboard, so its also acting as a plex frontend
<clever> monokrome: my nas is just a random x86 motherboard in a case, with a heap of sata disks in it
<clever> monokrome: if using a backend, you basically just set `deployment.targetEnv = "ec2";` and then give nixops some keys (many ways), and your done
<clever> monokrome: but if you use another backend like ec2, it can launch machines for you
<clever> monokrome: this is the "none" backend that uses pre-existing hw
<clever> if you want to keep things simple, just treat nas.nix like a configuration.nix file, and your done
<clever> monokrome: nixops will ssh into every machine (IP's on lines 12 and 16), and force it to run a new build of nixos, which comes from nas.nix and router.nix
<clever> monokrome: run `nixops create -d house deployments/house.nix` to make a deployment, then `nixops deploy -d house` to deploy it
<clever> monokrome: its pretty simple
<clever> monokrome: so it will always double in disk usage on the first deploy, and likely need a reboot to update the kernel
<clever> monokrome: my problem with the official nixos AMI, is that it is never the same nixpkgs rev that i am deploying with nixops
<clever> monokrome: slightly modified to get ssh keys from the aws api
<clever> monokrome: for aws, i was thinking you just generate an AMI with the same kernel/initrd and grub
<clever> monokrome: in this case, the kexec tar contains the entire os, and a single shell command will reboot into it
<clever> monokrome: it could be modified to do that
<clever> monokrome: the entire config is baked into the tar file
<clever> monokrome: my kexec script also includes the justdoit script, which can install your entire os in 1 command, once configured right
<clever> monokrome: kexec doesnt need kvm
<clever> monokrome: yeah
<clever> monokrome: kexec can be tricky to use when the server cant dhcp, and if you make any mistakes during the install, it can leave the server unable to boot
<clever> monokrome: and once your in that nixos ramdisk, you can just format the disk and install as normal
<clever> monokrome: correct
<clever> monokrome: but with kexec, you just upload a tar, and run 2 shell commands, and boom, its now running nixos from a ramdisk
<clever> monokrome: nixos-infect is limited to using the existing fs and partition layout, and the old OS lands in /old-root/ after reboot
<clever> monokrome: nixos-infect works differently, and has some limitations
<clever> monokrome: i have a nix expr, that will let you launch nixos with kexec
<clever> Raito_Bezarius: chmod -R
<clever> monokrome: it replaces the live kernel
<clever> monokrome: have you tried kexec?
<clever> all of my dns is static and i need a `nixops deploy` to update
<clever> ah, ive not bothered with them
<clever> ex-parrot: dynamic updates?
<clever> ex-parrot: systemd also has chroot-like isolation built into it
<clever> ex-parrot: ive been fine using just plain old bind
<clever> perfect!
<clever> ex-parrot: this would let you disable the copy in nixpkgs, then use a copy from your /etc/nixos dir
<clever> ex-parrot: simplest option then is to edit the module
<clever> dxtr: use a different sha256
<clever> dxtr: if you claim the sha256 is the same, it will believe you, and not bother to re-download the file
<clever> dxtr: how did it fail?
<clever> cole-h: :D
<clever> ,tofu
<clever> dxtr: simplest option is to just have nix generate it

2020-05-08

<clever> T0pH4t: you can then use cp on that to put it at a more normal place, or just set an env var to it
<clever> T0pH4t: so youll wind up with a `/nix/store/hash-foo.bin` in the string where you did that
<clever> T0pH4t: when you do `${./foo.bin}` in a nix expr, nix will copy it to /nix/store for you, and replace it with a storepath
<clever> but requireFile will at least give a nice error if you dont
<clever> the last 2 options require you to manually download it before the build
<clever> T0pH4t: or perhaps use pkgs.requireFile to give an error msg saying to dl it manually, like oracle java does
<clever> T0pH4t: the only other option, is to pre-download the thing, and then just do `cp ${./foo.bin} foo.bin` in your nix expression
<clever> with world-read permissions
<clever> T0pH4t: for a private bucket, you would need to use a custom fixed-output derivation, and your keys would wind up in /nix/store/
<clever> Raito_Bezarius: shouldnt be any issue
<clever> Raito_Bezarius: yeah
<clever> Raito_Bezarius: you would need to enable the initrd ssh stuff
<clever> T0pH4t: only the inputs you declared in the nix file can be used and nothing else
<clever> T0pH4t: nix also chroot's the whole build
<clever> T0pH4t: it ensures that the package rebuilds properly when inputs change
<clever> T0pH4t: the correct solution is to have nix download things for you, using things like pkgs.fetchurl, and to copy it to the right place
<clever> T0pH4t: nix always disables all network access at build time
<clever> Raito_Bezarius: possibly
<clever> Raito_Bezarius: get your stdenv from pkgsi686Linux too
<clever> then everything will be 32bit
<clever> Raito_Bezarius: use pkgs.pkgsi686Linux instead of plain pkgs
<clever> Raito_Bezarius: you need to use a 32bit stdenv and kgs tree
<clever> energizer: you can just use import and one of the fetch functions
<clever> Raito_Bezarius: thats a 64bit ld-linux
<clever> Raito_Bezarius: what does file say about the binary?
<clever> simpson: that would fetch a tar, import the default.nix within it, then shove it into the buildInputs of another dummy drv, and shell into that dummy
<clever> simpson: nix-shell -p '(import (builtins.fetchTarball "URL") {})'
<clever> Raito_Bezarius: the kernel has it enabled, and you can easily request nix itself to fetch/build 32bit binarie
<clever> simpson: nix-shell -A will give a shell suitable for building a thing, not using a thing
<clever> simpson: you cant mix -E and a file
<clever> simpson: internally, -p just generates a nix expr and evals it with -E
<clever> not sure then
<clever> where does ldd find it?
<clever> ghkbrew: what path is libstdc++ at?
<clever> niso: it cant be in imports normally (enless its got some config added in), because it messes with fileSystems."/"
<clever> niso: just add kexec.nix to the imports list, and you should get that
<clever> niso: that file within nixpkgs provides the service
<clever> system.build.kexec_tarball = pkgs.callPackage <nixpkgs/nixos/lib/make-system-tarball.nix> {
<clever> niso: the tarball stuff is already in nixpkgs, i was just reusing it
<clever> niso: it would fail at runtime
<clever> niso: i think kexec was broken in nixpkgs at one point, due to gcc hardening flags
<clever> niso: the required changes are likely in 20.03 and probably 19.09 as well now
<clever> niso: which readme?
<clever> so you could run that after the build, but before the export
<clever> bgamari: `nix-store --verify --check-contents` will just check every path, and report any problems
<clever> bgamari: it sounds like something modified /nix/store after a build was done
<clever> bgamari: what if you run `nix-store --verify-path` on that path?
<clever> betaboon: if you never use <foo> then the value of NIX_PATH doesnt matter
<clever> betawaffle: i would just not use <nixpkgs> within that shell.nix
<clever> yeah
<clever> betawaffle: it will dynamically adjust based on how other apps are using ram
<clever> you would just run them after the iptables-restore, and tell them to migrate
<clever> yeah
<clever> but increases the complexity
<clever> i also think using iptables-restore would be better for performance
<clever> lc: is it in ~/.config or ~/config ?
<clever> lc: the error says to use nixpkgs.config if using configuration.nix
<clever> lc: configuration.nix doesnt read config.nix
<clever> Henson: either irc or a PR, check `git blame` to see who has been touching most of it
<clever> Henson: but having it in nixpkgs natively would be nicer for others
<clever> Henson: you could use mkMerge, mkBefore, and mkAfter, to add your own nixo-fw-output, and flush it before all other rules, then append after others
<clever> Henson: nothing in OUTPUT for mine, i only filter incoming

2020-05-07

<clever> Henson: i do use nixos-fw for my stuff
<clever> Raito_Bezarius: justdoit is in the same dir as a kexec script, which gives you a kernel from nixpkgs
<clever> armin: i dont think /sys allows chgrp
<clever> then you can just `hello` directly
<clever> charukiewicz: `nix repl '<nixpkgs>'`
<clever> charukiewicz: or stdenv.lib
<clever> charukiewicz: pkgs.lib

2020-05-06

<clever> cab404[m]: ah, its probably the home-manager in imports, then the docs want to refer to it
<clever> cab404[m]: check https://logs.nix.samueldr.com/nixos/ to see how matrix is mangling things
<clever> cab404[m]: that didnt paste right
<clever> cab404[m]: what was it?
<clever> maralorn: its just a key name, doesnt do anything special
<clever> > { _ = "foo"; }
<clever> cab404[m]: and does the error go away if you comment out the 2 custom options?
<clever> cab404[m]: what is line 89 of /nix/store/rfk5j99kh4ny0jfi0m88yapv3pbw19nr-nixos-20.03.1619.ab3adfe1c76/nixos/nixos/lib/make-options-doc/default.nix ?
<clever> infinisil: no real way, because the passthru can contain anything that cant be serialized, and the drv path must always be a hash of its own contents
<clever> manveru: i had patched rust/default.nix to rename it back, but i can try undoing that...
<clever> niksnut: having some issues with rust cross-compiling, do you know about the area where it gets x86_64-pc-windows-gnu and x86_64-w64-windows-gnu mixed up?
<clever> DamienCassou: so pw prompts just silently "hang" because they opened in an ssh window on another box
<clever> DamienCassou: it then asks for the pw prompt on the ssh session, even if i'm back at the local keyboard
<clever> DamienCassou: ive also found that the gnupg module in nixos is much worse, it re-binds gpg to the "active" tty every time i ssh into the machine
<clever> WinchellsM: probably
<clever> basically
<clever> export SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
<clever> gpg-connect-agent /bye
<clever> $ cat ~/.xsession
<clever> DamienCassou: ive been just setting SSH_AUTH_SOCK manually
<clever> DamienCassou: you can only enable one ssh agent
<clever> WinchellsM: depends on if you want to boot with efi or legacy
<clever> and if efibootmgr doesnt work, there is a chance you booted without efi
<clever> WinchellsM: `grub.device = "/dev/sda";` is only used for legacy booting
<clever> WinchellsM: then you didnt boot with efi, so you cant manage any efi config
<clever> WinchellsM: yes
<clever> WinchellsM: after you modify the config, check the same chain of things on your end
<clever> so my bios will execute this file upon bootup
<clever> -rwxr-xr-x 1 root root 120320 Dec 23 04:39 /boot/EFI/BOOT/BOOTX64.EFI
<clever> and it is currently mounted to /boot
<clever> /dev/nvme0n1p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
<clever> this is a partition with that exact partuuid
<clever> [root@system76:~]# blkid /dev/nvme0n1p1
<clever> /dev/nvme0n1p1: UUID="7DBC-2698" TYPE="vfat" PARTUUID="27c99b08-455d-4dfe-a44f-6150cbc09ef8"
<clever> this tells the bios to look for a certain partuuid, and load a given file from that
<clever> Boot0004* UEFI OS HD(1,GPT,27c99b08-455d-4dfe-a44f-6150cbc09ef8,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
<clever> [root@system76:~]# efibootmgr -v
<clever> WinchellsM: what you want to do before you reboot, is verify all of the bootloader cfg
<clever> pie_: cole-h asked a "x or y" question, and your answer was "yes"
<clever> pie_: what was a multiple choice question, not a boolean
<clever> tobi_: i think you want .override, not .overrideAttrs
<clever> turion: it also moves that build dir, breaking more things
<clever> turion: it would mess with permissions and also require the entire build dir (potentially several gig) to be put into the store and kept long-term
<clever> nix-build wipes that dir every time
<clever> but if your reusing the build dir, with the state from before, you dont have to re-run it
<clever> turion: the other 2 should work fine though
<clever> turion: installPhase will never work right in nix-shell, since you lack access to /nix/store
<clever> turion: what does the buildPhase actually do? what is the 1st line of it?
<clever> turion: thats why i recommend using genericBuild with the phases var
<clever> turion: if buildPhase hasnt been overridden, you need to use bare buildPhase instead
<clever> turion: yeah, you usually only need to configure once
<clever> cole-h: default.nix should just contain: with import (builtins.fetchTarball ...) {}; callPackage ./app.nix {}
<clever> cole-h: and i try to fetchTarball nixpkgs, so it is reproducable
<clever> cole-h: i tend to add a default.nix that loads program.nix in that case