<clever>
this is the simplest way: systemd.packages = [ (pkgs.callPackage ./your-package.nix {}) ];
<clever>
visrelic: you need to somehow get the nix expr for building that storepath, into systemd.packages
<clever>
visrelic: nix-env cant do systemd level things
<clever>
visrelic: service stuff must go into a nixos module, not the package default.nix
<clever>
visrelic: usually best to have nixos generate the systemd unit via systemd.services
<clever>
visrelic: yes
<clever>
ajs124: if you do clone the nix directory, its best to not make any other changes to it until you reboot
<clever>
you could also ask a non-nix user that is nearby to just select a different option at grub, if others are stationed near the machine
<clever>
but without ipmi, that step is difficult
<clever>
ajs124: so if you do somehow tell grub to boot that image, it will be on the vpn
<clever>
ajs124: the rescue-boot has a benefit over a normal iso, in that you can configure the vpn on that config
<clever>
ajs124: i did basically the same thing with my laptop a few years ago, and thats when i made rescue-boot.nix
<clever>
ajs124: ah, that makes things more tricky, and if you make any mistakes, its bricked
<clever>
ajs124: you may be able to, but i find it simpler to do it offline
<clever>
ajs124: you can then boot from the rescue env, move /nix to where it should be (an offline move) and then boot back to the new generation `nixos-rebuild boot` had made
<clever>
ajs124: add that to your imports list, nixos-rebuild switch, then "fix" the configuration.nix to match where /nix will be, and nixos-rebuild boot
<clever>
ivan: you need per-slot reset, and it may be specific to the gpu drivers
<clever>
ivan: ive found that without the right motherboard, your forced to reboot the host any time windows reboots
<clever>
i prefer using grub at all times, even on efi
<clever>
freeman42x]NixOS: either use a 2nd hard-drive, or use gparted to shrink the windows partition
<clever>
freeman42x]NixOS: mostly, just install nixos as normal, without deleting windows, and then use grub.extraConfig to add a menu option for windows
<clever>
freeman42x]NixOS: trivial
<clever>
freeman42x]NixOS: the version of wine it gives you
<clever>
jlv: that is how nixops generates some of the nixos config
<clever>
jlv: you want to look at the nixops source code
<clever>
hyperfekt: the + is also using the path type
<clever>
hyperfekt: no need for the + and string
<clever>
> <nixpkgs/.version>
<clever>
freeman42x]NixOS: but windows doesnt make that easy
<clever>
freeman42x]NixOS: you would need some pulseaudio style features on the host to force it into working
<clever>
when you find the option, you could share it so i can update the iohk qemu stuff too
<clever>
which would then reboot, and destroy the clone, and fix the issue
<clever>
write failures should probably result in termination
<clever>
yeah
<clever>
and the guest wont notice a thing (other then the fact that it was hung for an hour)
<clever>
and you can resume the vm once the issue is resolved
<clever>
gchristensen: at least with virtualbox, it will suspend the vm if writes fail due to out of space
<clever>
gchristensen: oh, lol
<clever>
at the cost of more latency, you could have obs on windows, capture audio, stream it somewhere, then have obs on nixos play that stream, and re-stream it
<clever>
freeman42x]NixOS: the simpler option is to just run obs on windows
<clever>
freeman42x]NixOS: yes
<clever>
freeman42x]NixOS: then you first need to figure out how to force windows to route its loopback into the virtualbox capture device
<clever>
gchristensen: fsck it!
<clever>
gchristensen: wtf? :D
<clever>
freeman42x]NixOS: but what about the source of the audio, is it also in nixos?
<clever>
freeman42x]NixOS: are you trying to capture audio playing from nixos, or windows?
<clever>
gchristensen: obs automatically captures from the loopback of a device
<clever>
freeman42x]NixOS: which end is obs running on? where is the audio source?
<clever>
not many other things we can check
<clever>
gchristensen: and if you read it with less, it looks fine?
<clever>
gchristensen: what about `file /nix/store/0623dk7hhb392f7c17kxq4kww3lrwm4s-stdenv-darwin/setup` ?
<clever>
gchristensen: can that bash actually run?
<clever>
ok, so its not the classic linux binary on a mac
<clever>
gchristensen: run nix-store --query --binding builder /nix/store/7nz6z7f1j5vigd97qh0qvziwdry7b99x-aws-sdk-cpp-1.7.53.drv
<clever>
stites: nope, i dont do much python stuff in nixpkgs
<clever>
stites: you want to add python to the arguments, and then use that
<clever>
stites: ^^^
<clever>
> python3.sitePackages
<clever>
vika_nezrimaya: read the .service file, and then run nginx under strace
<clever>
vika_nezrimaya: logs?
<clever>
vika_nezrimaya: strace the pid?
<clever>
vika_nezrimaya: i would just continue to use normal acme
<clever>
DariusTheMede: and 31
<clever>
DariusTheMede: i would probably also fix lines 15-26, to use another <<EOF
<clever>
Ariakenom: is something currently cd'd into it?
<clever>
Ariakenom: try umount and then mount -v ?
<clever>
Ariakenom: the kernel itself
<clever>
Ariakenom: those are global ones, check `man mount`
<clever>
Ariakenom: i also tend to not trust any write support for linux+ntfs, id rather use a fat32 middleman then risk the partition becoming corrupt
<clever>
Ariakenom: the other option is the ntfs3g stuff that uses fuse, but i dont remember how to mount it from configuration.nix
<clever>
Ariakenom: oh wait, next line down, it does have limited write support
<clever>
Ariakenom: the driver your using only supports read-only mode
<clever>
DariusTheMede: ah, then youll need to fix it in configuration-common.nix, like vulkan = super.vulkan.override { vulkan = pkgs.vulkan-loader; };
<clever>
DariusTheMede: you can either fix the cabal file, or use an override like vulkan to force it
<clever>
DariusTheMede: and cabal2nix is just obeying that
<clever>
DariusTheMede: i think the problem is that the cabal file is asking for the "wrong" library