2020-01-28

<clever> grin[m]: what path are you editing?
<clever> grin[m]: that tells grub which drive to install the MBR stub into
<clever> grin[m]: for non-efi installs, you must set something like boot.loader.grub.devices = [ "/dev/sda" ];
<clever> wedens[m]: you can just nix-build that pulseaudio, to see if it did what you want
<clever> wedens[m]: id use buildEnv for that, but that will likely cause a mass rebuild
<clever> the clients obviously wont respect the changes, but will connect to the patched daemon
<clever> wedens[m]: hardware.pulseaudio.package = pkgs.pulseaudio.overrideDerivation ...;
<clever> wedens[m]: if your patched pulseaudio only goes into hardware.pulseaudio.package, it wont be a mass rebuild
<clever> ,invite hyper_ch2
<clever> kleisli: `nix-shell '<nixpkgs>' -A hello` or `nix-shell /nix/store/hash-hello.drv`
<clever> kleisli: thats what nix-shell is for
<clever> to say where
<clever> all nix does, is give $out, the env var
<clever> kleisli: its up to the builder to create it
<clever> kleisli: $out can also be a file or a symlink

2020-01-27

<clever> najksz: `nix-store --serve --write`
<clever> exarkun: nixos/modules/installer/tools/tools.nix is an example
<clever> exarkun: ah, target is an internal thing, $dir is the input
<clever> exarkun: what does substitute-all.nix do with target?
<clever> exarkun: target is relative to $out, when you want to create a $out/bin/foo
<clever> exarkun: it returns the new path
<clever> exarkun: its also a nix function, that does the same job
<clever> > pkgs.substituteAll
<clever> eoli3n_: adobe has stopped supporting it ages ago, and modern browsers dont support that type of plugin
<clever> eoli3n_: step 1, let flash die, step 2, repeat step 1
<clever> astk: this is an example, that loads 2 cabal files, for machotool and macho, i can then just `nix-build -A machotool` to compile it
<clever> astk: buildEnv merges them the same way, so you have fewer things to copy and/or install
<clever> gather seperate exes in the same place
<clever> astk: installing things with nix-env merges them into ~/.nix-profile/
<clever> astk: nix-env would merge them together anyways
<clever> astk: if you install them with nix-env, yes
<clever> astk: each .cabal file will have its own bin dir, you can then either install of them with nix-env, or merge them with buildEnv
<clever> astk: when nix-build is done, youll have a regular ELF binary in a bin dir, just like any c/c++ project
<clever> astk: nope
<clever> astk: you would either need to use cabal2nix to generate a .nix file for each component, or try using haskell.nix
<clever> that will copy the entire thing over
<clever> astk: after you compile the binary with `nix-build`, just do `nix-copy-closure ./result --to root@machien`
<clever> astk: you can also use nixops to deploy nixos to aws
<clever> astk: yeah, avoiding conflicts like that is half the reason to use nix
<clever> yep
<clever> astk: yeah, you would have nix installed on both ends, and nix just uses its own version of glibc
<clever> astk: if you build a binary using `nix-build`, then nix will keep track of everything it depends on, and you can use `nix-copy-closure` to deploy that to another machine
<clever> astk: nix will copy the required one for you
<clever> astk: if you properly copy the closure (using nix-copy-closure), then the glibc version wont matter
<clever> rsoeldner: there is an argument to change the lock file dir, i cant remember which one, check the man page
<clever> rsoeldner: https://github.com/samueldr/hydra-in-a-bag does that
<clever> rsoeldner: yeah, you could manually run the postgres daemon, and pass it flags to change all of the dirs
<clever> rsoeldner: you need to enable the postgresql service globally
<clever> jbit: --option substituters ''

2020-01-26

<clever> jakubgs: `nix repl '<nixpkgs/nixos>'`
<clever> thomashoneyman: pkgs.fetchurl
<clever> xavierzwirtz[m]: add a derivation that has a etc/passwd, etc/group, and etc/shadow

2020-01-25

<clever> scheming_around: basically, nix will just turn the entire $out into a single string (like `tar $out > foo.tar`, and then grep that string for every input path
<clever> kalbasit: so direnv can change all defaults
<clever> kalbasit: and $NIX_CONF_DIR can override the location of nix.conf
<clever> kalbasit: you can then use bash to join things together
<clever> kalbasit: there is also `nix show-config` which can read the current values
<clever> kalbasit: you can add all public keys to nix.conf, and then use extra-substituters to actually then the cache on/off
<clever> kalbasit: replace it entirely
<clever> yep
<clever> scheming_around: nix-env -E '_: with import <nixpkgs> {}; callPackage ./. {}' -i
<clever> scheming_around: nix-env -f . -iA foo
<clever> and 59 then reads it
<clever> chagra: check the example i linked, that lets me set programs.vim.fat = true
<clever> chagra: add your own options to nixos

2020-01-24

<clever> quiet_laika[m]: that one should also be good
<clever> quiet_laika[m]: not sure then
<clever> quiet_laika[m]: are you using the pkgs.luarocks package?
<clever> quiet_laika[m]: are you using nix-shell?
<clever> pie_[bnc]: it also lets you treat x86 much more like a c64
<clever> pie_[bnc]: when you want to have a complex program, and no os in the way
<clever> pie_[bnc]: bios testing and such
<clever> pie_[bnc]: somebody already wrote python for grub
<clever> MasseGuillaume: as root?
<clever> MasseGuillaume: did you --update?
<clever> MasseGuillaume: and you did the above `nix-channel --list` as root?
<clever> aiverson: it can help to number each hash uniquely, just replace a 0
<clever> ,tofu aiverson
<clever> so you can just run them yourself
<clever> all of the default phases, are just bash functions
<clever> pie_[bnc]: fetchzip has a misleading name, and handles both zip and tar
<clever> pie_[bnc]: you can also use `runCommand "name" { src=...; } "unpackPhase ; mv $sourceRoot $out"`
<clever> pie_[bnc]: https://github.com/input-output-hk/cardano-explorer/blob/master/docker/default.nix#L12-L19 and maybe some unpackPhase if you expect $src to be compressed, you may need `unpackPhase ; mv $sourceRoot $out`
<clever> pie_[bnc]: fetchzip, will both download and unpack in one go
<clever> infinisil: ^^
<clever> notgne2: that doesnt look right at all
<clever> pie_[bnc]: yeah, thats what i was wondering too, but the makefiles arent easy to read while multi-tasking
<clever> NemesisD: id just do it manually at that point
<clever> pie_[bnc]: usually
<clever> though nofail and some manual vgchange would also work
<clever> NemesisD: i think setting neededForBoot = true; is your only fix
<clever> NemesisD: and thats ran, for every device flagged as neededForBoot
<clever> NemesisD: line 78-101, will re-run vgchange -ay, in a loop, until a given device appears
<clever> NemesisD: so the device doesnt exist yet
<clever> NemesisD: line 226 might be ran before usb is online
<clever> NemesisD: preLVMCommands is literally ran right before a `vgchange -a y`
<clever> NemesisD: `vgchange -a y` has to be ran every time you boot, normally the initrd automates it, but ive only really used lvm on the boot disks
<clever> NemesisD: noauto is also of use
<clever> NemesisD: i think it was nofail?
<clever> NemesisD: there is also a flag under options to make systemd shut up
<clever> NemesisD: `vgchange -a y`
<clever> NemesisD: theres not much harm in adding too many things, it just makes the initrd file bigger
<clever> NemesisD: i think those are the main ones
<clever> NemesisD: xhci_hcd, ohci_hcd, ehci_pci, ehci_hcd, xhci_pci,ohci_pci
<clever> NemesisD: the usb related modules from `lsmod`
<clever> NemesisD: boot.initrd.availableKernelModules
<clever> NemesisD: did you include usb drivers in the initrd?
<clever> pie_[bnc]: and now i'm lost, ive never seen a file like that in make before!
<clever> grub-core/Makefile.core.def: name = zfs;
<clever> $ unpackPhase
<clever> $ nix-shell -E 'with import <nixpkgs> {}; (grub2_full.override { zfsSupport = false; zfs = null; }).overrideAttrs (old: { configureFlags = [ "--disable-libzfs" ]; })'
<clever> ah, i see it on this end
<clever> pie_[bnc]: what is the filename the last cmd found?
<clever> pie_[bnc]: *looks*
<clever> not sure whats going on
<clever> it may already be false then
<clever> which can happen based on supportedFilesystems
<clever> nixos/modules/tasks/filesystems/zfs.nix: zfsSupport = true;
<clever> based on that
<clever> 458 zfsSupport = mkOption {
<clever> 459 default = false;
<clever> pie_[bnc]: grub.nix (the module) will do its own override
<clever> 16 else if cfg.zfsSupport then grubPkgs.grub2.override { zfsSupport = true; }
<clever> pie_[bnc]: you want grub2 = self.grub2_light;
<clever> 3787 grub2_light = grub2.override {
<clever> 3788 zfsSupport = false;
<clever> 6 , zfsSupport ? true
<clever> pie_[bnc]: why bother removing zfs?
<clever> it is, line 3779 above
<clever> pie_[bnc]: why not name your custom module something unique?
<clever> ah, which is an alias
<clever> 3779 grub2 = grub2_full;
<clever> pie_[bnc]: i think its using pkgs.grub2, not pkgs.grub2_full
<clever> 16 else if cfg.zfsSupport then grubPkgs.grub2.override { zfsSupport = true; }
<clever> 15 realGrub = if cfg.version == 1 then grubPkgs.grub
<clever> NemesisD: i tend to avoid it
<clever> pie_[bnc]: grub testdisk or linxu testdisk?
<clever> pie_[bnc]: i would just add a custom module to the dir by hand, for testing
<clever> but if you disable efi support, grubEfi = null
<clever> pie_[bnc]: grub.nix is grabbing the overridden version, and putting that into the grubEfi var
<clever> pie_[bnc]: one sec
<clever> pie_[bnc]: the grub-install program, from grub itself
<clever> it checks if the thing exists in the options tree first
<clever> could be worthy of a bug report
<clever> which may confuse nixos-option
<clever> they exist in config, but not in options
<clever> the option is system.build, thats why its like that
<clever> pie_[bnc]: yeah, it only works for system.build
<clever> installBootLoader = «derivation /nix/store/rj5ccb5cj332qhdlpy1384nxz9zjq4i5-install-grub.sh.drv»;
<clever> Value:
<clever> [root@amd-nixos:~]# nixos-option system.build
<clever> pie_[bnc]: nixos-option may not let you view attrs of it, only the whole thing
<clever> pie_[bnc]: system.build is a single option, of type attr set

2020-01-23

<clever> jgt: yeah
<clever> jgt: and how did you do the override in the nixops file?
<clever> jgt: how is your nixops file referencing it?
<clever> jgt: probably
<clever> jgt: thats the only way to change the args on line 1
<clever> jgt: you must use .override
<clever> pbb: without nscd, you dont have dns caching, so each app has to read /etc/hosts and /etc/resolv.conf and do its own dns (via glibc)
<clever> pbb: mainly, it deals with loading libraries to make things like avahi/mdns work
<clever> disasm: should be possible to just run `${pkgs.sudo}/bin/sudo -u foo ${script}`
<clever> CMCDragonkai: only a fixed-output derivation can be part of the original net ns
<clever> CMCDragonkai: by default, all builds are ran in a network namespace, with only lo
<clever> and could be simpler then cntr
<clever> that would make it trivial to debug sandbox build failures
<clever> nix-shell --ultra-pure
<clever> but just connect stdio to a tty, and dont save the resulting $out
<clever> ive thought before, about how nix-shell could setup a complete nix sandbox, same as nix-daemon would have
<clever> that reminds me
<clever> infinisil: it is, there is a derivation that runs cabal2nix for you, in a nix build, and then imports
<clever> CMCDragonkai: it will re-run cabal2nix any time your .cabal file changes
<clever> CMCDragonkai: callCabal2nix is one use-case
<clever> infinisil: i do have one sample, of how to sign into wpa with a name/pw

2020-01-22

<clever> ah, its since been renamed, my bookmark auto-filled
<clever> Raito_Bezarius: i would just point it towards a pkgs.writeShellScript, and export PATH within that
<clever> Raito_Bezarius: <runcommand> in the hydra.conf file i think
<clever> bqv[m]: nixos/modules/installer/tools/tools.nix
<clever> bqv[m]: its a special nixos module, outside of the package tree
<clever> thats more likely to be an incompatible QT version
<clever> those almost never need a restart of xorg, for any reason
<clever> iqubic: no idea what cockatrice even does
<clever> let my_cockatrice = ...
<clever> simplest way to avoid confusion from `with pkgs;` is to just name your thing something else
<clever> look at my example, it has a {}
<clever> your missing a {}
<clever> that will always grab hello from a specific git checkout
<clever> iqubic: let foo = (import /home/clever/apps/nixpkgs {}).hello; in ...
<clever> but you can skip that, and just hard-code paths
<clever> <foo> is just a shortcut to generate a path by looking it up in NIX_PATH/-I
<clever> iqubic: use `import /home/clever/foo` instead of `import <foo>`
<clever> infinisil: ah, ive not played with the auto stuff yet
<clever> dansho: patchelf --set-interpreter $(cat $NIX_CC/nix-support/dynamic-linker)
<clever> dansho: ah, then just patchelf as normal
<clever> dansho: how does it fail when compiling?
<clever> dansho: patchelf?
<clever> dansho: this magic path will always have the right name, even on other arches (arm, 32bit x86)
<clever> $ cat $NIX_CC/nix-support/dynamic-linker
<clever> /nix/store/qb6k4hp7gk331x9fydw0w7qj4dv09bwz-glibc-2.27/lib/ld-linux-x86-64.so.2

2020-01-21

<clever> Raito_Bezarius: then you had a previous non-sandboxed build still in your /nix/store, and didnt reproduce anything locally
<clever> Raito_Bezarius: delete the $out, then -r the drv
<clever> Raito_Bezarius: try `nix-store --delete /nix/store/foo` then just plain `nix-store -r /nix/store/foo.bar`
<clever> Raito_Bezarius: try `nix-store -r /nix/store/foo.drv --check`
<clever> hpfr[m]: you want pkgs.fetchFromGitHub
<clever> Raito_Bezarius: do they both produce the same $out?
<clever> does it boot from sdb1?
<clever> you had to rename the .efi file ot match windows
<clever> because the bios is hard-coded to the filename windows used
<clever> i have seen cases where it refuses to even boot linux
<clever> then vendors go and screw up the implementation :P
<clever> the design can be very powerful
<clever> uefi is a giant mess
<clever> trevthedev: looks like that bios is just completely ignoring the os, youll just have to reboot and see what happens
<clever> you want to look at the next entry in bootorder
<clever> trevthedev: that says that the top priority for booting, is your cdrom
<clever> can you pastebin the output from both>
<clever> do they match?
<clever> trevthedev: and then compare the uuid of boot0006, with `blkid /dev/sdb1`
<clever> trevthedev: the bootorder line from `efibootmgr -v`
<clever> trevthedev: what does bootorder say?
<clever> trevthedev: in the output from `efibootmgr -v`
<clever> trevthedev: and there should be a boot0006 line
<clever> trevthedev: and is the one at the start of bootorder, matching up with the uuid of your new /boot?
<clever> trevthedev: oops, -v
<clever> trevthedev: double-check `efibootmgr -V` and see if it looks good
<clever> trevthedev: efi variables are in /sys/firmware/efi/efivars
<clever> trevthedev: efi variables arent on sdb1
<clever> trevthedev: why cant you pastebin?
<clever> trevthedev: what does `fdisk -l /dev/sda` report?
<clever> trevthedev: how are you resizing it?
<clever> trevthedev: does it give an error?
<clever> trevthedev: only if you delete the partition home is on
<clever> trevthedev: more, that if your new ssd doesnt boot, you cant just go back to the old one, if the old /boot is toast
<clever> trevthedev: also make sure to save anything in /etc that may be of value
<clever> trevthedev: you could do that resizing first, but then there is no undo
<clever> trevthedev: if you mount your home partition to /mnt/home, nixos-generate-config will put the right entry into hardware-configuration.nix for you
<clever> Raito_Bezarius: not sure, never tried it on a symlink
<clever> it sounds like the script is never actually being patched
<clever> Raito_Bezarius: /usr/bin/env doesnt exist when the sandbox is on
<clever> Raito_Bezarius: thats why
<clever> Raito_Bezarius: is your sandbox enabled?
<clever> Raito_Bezarius: is the script actually being patched?
<clever> Raito_Bezarius: dont think it can really fail, but it can not do what you want
<clever> trevthedev: thats basically all `move /mnt/home/home/trevthedev to /mnt/home/trevthedev` is doing, once you delete the other stuff
<clever> trevthedev: ah yeah, youll want to move /mnt/home/home/trevthedev to /mnt/home/trevthedev after you mount it
<clever> trevthedev: once you confirm the new disk can boot, you can delete the old stuff
<clever> trevthedev: and then procede with the install as normal
<clever> trevthedev: id say the simplest option, is to boot the nixos livecd, format and mount sdb1 to /mnt, and then mount sda4 to /mnt/home
<clever> neeasade: you want $out not ${out}
<clever> zgrep: nixos-rebuild test should do that
<clever> neeasade: can you paste the configuration.nix file?
<clever> neeasade: then its not using what you put into the pastebin
<clever> neeasade: does it list an installPhase?
<clever> neeasade: you almost never need a builder.sh file
<clever> neeasade: it should give the path to a .drv file that is failing to build, what does `nix show-derivation` say about that drv?
<clever> shyim: you may also want to check `smartctl -a /dev/sda`
<clever> shyim: an improper shutdown can result in data not being saved, and a failing disk can just corrupt anything
<clever> shyim: and then follow up with a `nix-store --verify --check-contents`
<clever> shyim: `nix-store --repair-path /nix/store/l98cfjbh7dda7zrvsgy2qpaa4k9qh75i-go-1.13.6`
<clever> shyim: more corrupt things!, your go binary got scrambled
<clever> shyim: nix-store --verify-path /nix/store/l98cfjbh7dda7zrvsgy2qpaa4k9qh75i-go-1.13.6
<clever> shyim: file /nix/store/l98cfjbh7dda7zrvsgy2qpaa4k9qh75i-go-1.13.6/bin/go
<clever> shyim: `file /home/shyim/.nix-profile/bin/go` ?
<clever> shyim: `rm /nix/var/nix/profiles/per-user/shyim/profile-13-link /nix/var/nix/profiles/per-user/shyim/profile` should completely reset the profile
<clever> s/buf/buf/
<clever> shyim: that sounds like a different buf, what does `ls -l /nix/var/nix/profiles/per-user/shyim/profile-13-link` say?
<clever> shyim: exactly as i typed it
<clever> shyim: what about `ls -l`?
<clever> shyim: does it point to profile, or directly to profile-13-link?
<clever> shyim: `ls -l ~/.nix-profile` ?
<clever> shyim: thats a common issue from an improper shutdown after a nix-env -i/e
<clever> shyim: what is the exact error? what does `nix-env --list-generations` output?
<clever> shyim: try `nix-env --rollback`
<clever> Raito_Bezarius: there is a cancel non-current builds on the admin menu
<clever> Raito_Bezarius: cleanSourceWith will detect if its being ran on itself, and compose the filters for you
<clever> Raito_Bezarius: ah, never seen that before
<clever> Raito_Bezarius: i would expect cleanSource to work in hydra, check github for hydra and see if any issues exist
<clever> the problem i find, is when you get haskell involved, and it decides to build 3 copies of ghc at eval time
<clever> but node2nix is usually fairly fast
<clever> Raito_Bezarius: not really
<clever> Raito_Bezarius: hydra does technically handle IFD, but it runs the derivations at eval time, which can lead to the eval alone taking 4 hours, with zero progress
<clever> Raito_Bezarius: at eval time, cleanSource will recursively copy the path, and run the nix to figure out what to include/exclude
<clever> Raito_Bezarius: i believe its limited to only paths specified with -I
<clever> not sure about the restricted mode error
<clever> Raito_Bezarius: trackPureSource = gitignoreSource minimalTrackSrc; should have the same effect
<clever> Raito_Bezarius: trackPureSource is basically a no-op
<clever> Raito_Bezarius: if your just changing the release.nix, you can eval the jobset directly
<clever> Raito_Bezarius: only if you change the config for a jobset, or add more
<clever> but the jobsets otherwise work as normal
<clever> Raito_Bezarius: declarative jobsets is just an automated way to create a jobset, and it disables the edit/delete buttons in the gui