<clever>
kenran: possibly inside a set, as { something = pkgs.writeTextFile ...; }
<clever>
kenran: it would be a derivation that just goes writeTextFile directly
<clever>
kenran: it goes in something.nix
<clever>
kenran: you can point -o anywhere you want, if you want it somewhere else
<clever>
kenran: nix will generate the file, at a random path under /nix/store/, and the `-o /usr/local/etc/something.ini` will generate a symlink, pointing to that random path
<clever>
kenran: something.nix is a file you need to write, that describes the contents, but not the location
<clever>
gyroninja: $out is the main one, all derivations must put files there by default
<clever>
there should be dozens of examples in nixpkgs
<clever>
then nix will generate the ini file for you, and drop a symlink there
<clever>
kenran: you probably want to use pkgs.writeTextFile then, and then `nix-build something.nix -A something -o /usr/local/etc/something.ono`
<clever>
kenran: is the ini file in /etc? then a nixos module should be generating it
<clever>
rizary_: you could use pkgs.runCommand to generate a zip containing the files you want, and $out/nix-support/hydra-build-products to expose a download link in hydra's UI
<clever>
i cant think of any other programs that are more open
<clever>
that would let you override things without changing NIX_PATH
<clever>
Raito_Bezarius: you can always use -I nixpkgs=/whatever with `nixops deploy`, and you can use `nixops modify -I nixpkgs=/whatever deployment.nix` to make that override permanent
<clever>
Raito_Bezarius: yeah, the first entry forces <nixpkgs> to always be roots nixpkgs, and to ignore what your current user has
<clever>
echo $NIX_PATH ?
<clever>
youll need to refer to the value of $NIX_PATH
<clever>
so if the pathes are identical, then the nixpkgs hasnt changed
<clever>
the hashes in the store paths, are all hashes of the build directions
<clever>
your welcome
<clever>
just nix-channel --update, as root
<clever>
Raito_Bezarius: nix-channel --list, as root
<clever>
Raito_Bezarius: then it should use whatever channel root is using
<clever>
Raito_Bezarius: then nixops should be using whatever <nixpkgs> maps to in $NIX_PATH
<clever>
Raito_Bezarius: is `Nix path` listed at all?
<clever>
Raito_Bezarius: what about before the host list, can you pastebin that part?
<clever>
Raito_Bezarius: what does `nixops info` report?
<clever>
Raito_Bezarius: forcing it to re-copy wont make any difference then
<clever>
Raito_Bezarius: store paths are read-only, so there isnt much point in re-copying things
2019-11-11
<clever>
adisbladis: but if your on a none backend, youll need to edit the python to make it behave more like aws
<clever>
adisbladis: in the case of the aws backend, if you simply edit /root/.ssh/authorized_keys, the keys nixops is managing will cease to be of value
<clever>
adisbladis: for other backends, nixops adds it to the nixos config
<clever>
adisbladis: for aws, nixops creates an aws keypair, and relies on the scripts in the ami to embed it into /root/.ssh/authorized_keys
<clever>
adisbladis: nixops creating its own keys, is backend dependant
<clever>
adisbladis: ah, so youve set fileSystems."/" = { fsType = "tmpfs"; }; ?
<clever>
adisbladis: why is / a tmpfs then?
<clever>
adisbladis: how is it booting? netboot image?
<clever>
adisbladis: nixos must be setting an upper limit somewhere
<clever>
adisbladis: i dont see any sign of a 3gig limit, what happens if you just mount a new tmpfs to an empty dir?
<clever>
3619 ->>>>>>> * Per default we only allow half of the physical ram per
<clever>
3620 ->>>>>>> * tmpfs instance, limiting inodes to one per page of lowmem;
<clever>
3621 ->>>>>>> * but the internal instance is left unlimited.
<clever>
adisbladis: it also has a nr_blocks= mount option, which just bypasses the byte->block conversion
<clever>
104 ->>>>>>>return totalram_pages / 2;
<clever>
102 static unsigned long shmem_default_max_blocks(void)
<clever>
adisbladis: you can explicitely set `size=60%` and it will figure things out on its own
<clever>
Klein37: and then a mix of removing it from things, nix-env --delete-generations, and nix why-depends, to remove the roots
<clever>
Klein37: next time, use `nix-store --query --roots /nix/store/foo` to see why something cant be deleted
<clever>
Klein37: your only solution is to boot the nixos install iso, and re-run nixos-install, which will remake the missing parts, from configuration.nix
<clever>
Klein37: never use --ignore-liveness, you probably just deleted the entire nixos build, and nix itself
<clever>
EsperLily: yeah, not much can cache that right now
<clever>
EsperLily: if your developing somethng, just build it in nix-shell, and the .o files will persist between runs of `make`
<clever>
EsperLily: extra-sandbox-paths are read-only i believe
<clever>
EsperLily: but the sandbox doesnt allow you to access a shared cache dir
<clever>
elvishjerricco: unbind each one, and see what breaks, then re-bind if its not that
<clever>
red[m]: ah, tmux may undo a lot of those vars
2019-11-10
<clever>
red[m]: $NIX_LDFLAGS and $NIX_CFLAGS_COMPILE
<clever>
red[m]: its tied into cc-wrapper, and only impacts gcc, so ponyc may ignore it
<clever>
red[m]: so you just use the normal -ltermbox you always use
<clever>
red[m]: nix automatically adds a -L flag for you
<clever>
then you just try each one
<clever>
elvishjerricco: causing whatever usb devices are behind it, to vanish
<clever>
elvishjerricco: but the above steps let you basically disconnect any pci device from its driver
<clever>
elvishjerricco: i dont know of a way to directly do that
<clever>
just note, if you disconnect the usb card from the usb driver, you loose your keyboard, so test over ssh!
<clever>
elvishjerricco: you can use the bind find to re-connect things
<clever>
elvishjerricco: and i think if you `echo 00:16.2` to this file, it will just detatch the driver from the card, causing it was doing to stop (and all usb devices to unplug)
<clever>
--w------- 1 root root 4096 Nov 10 19:47 /sys/bus/pci/drivers/ehci-pci/unbind
<clever>
elvishjerricco: with this, i can figure out which driver is using a given card
<clever>
Kernel driver in use: ehci-pci
<clever>
00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller (prog-if 20 [EHCI])
<clever>
so you can do services.foo = mkMerge [ .... ];
<clever>
mkMerge basically does the same thing as imports, but works at any node
<clever>
while with mkMerge, it will verbosely complain if you set something twice
<clever>
also, with recurisveUpdate and //, it will just silently overwrite things
<clever>
[1] and [2] turns into [2], not [1 2]
<clever>
selfsymmetric-mu: but that wont respect nixos config merge rules
<clever>
it takes a list of nixos configs
<clever>
otwieracz: if its nixos config, you can also use mkMerge
<clever>
otwieracz: the way i personally do it, is i just define a users.users.foo, give it a home dir, and tell nixos to createHome = true;
<clever>
otwieracz: the "new" way is to use systemd tempfiles, but that name feels backwards and ive not looked into how to do it yet
<clever>
otwieracz: you can then freely use mkdir and chown to prepare things
<clever>
otwieracz: if you set PermissionsStartOnly, then the User= only affects ExecStart, so ExecPreStart gets ran as root
<clever>
Thra11_: set nixpkgs.overlays in the nixos config
<clever>
and if thats a tmpfs, it will be limited to 50% of ram, so the journal is limited to 5% of ram
<clever>
CMCDragonkai: it will not use more then 4gig for the logs, and not use more then 10% of the space on whatever fs is mounted to /var/log/journal
<clever>
CMCDragonkai: it will limit itself to keep a certain amount free, not use more then a certain amount (both absolute, and percentage), and gc automatically based on those params
<clever>
CMCDragonkai: `man journald.conf`
<clever>
boogiewoogie: and 2 hours ago, the status was changed to "has port to stable", so maybe we just have to wait for stable to update?
<clever>
with a minor change (make it not a module, add with import <nixpkgs>{};), i can nix-build it, and ./result/bin/vim to test the changes (or use it on somebody elses machine)
<clever>
wedens[m]: this generates a vim, that has a vimrc baked into it, along with plugins
<clever>
wedens[m]: you can also point NIX_PATH to a tarball that was made for a channel, but those are a bit more tricky to find
<clever>
wedens[m]: thats much simpler if it was built from a channel
<clever>
then go forwards/backwards in history
<clever>
but if you guess, and use nix-diff and nix-instantiate, you can see how much differs between whats built and your guess
<clever>
no easy way to find the nixpkgs rev directly
<clever>
ah, those also lack .version-suffix
<clever>
a url or a dir?
<clever>
wedens[m]: but what was it pointing to?
<clever>
wedens[m]: then it was built from a git clone, and the .version-suffix file is missing
<clever>
gyroninja: only other thing i can think of, is things like sse2 features
<clever>
thats weird
<clever>
gyroninja: likely, none of the inputs have changed, so hydra hasnt bothered to try again, since doing the exact same thing twice is the definition of insanity
<clever>
gyroninja: its likely just a random failure, and the hydra job needs to be restarted
<clever>
gyroninja: and the .drv nixpkgs generates, is identical to the one hydra has
<clever>
gyroninja: unxz is already in the PATH of that derivation
<clever>
gyroninja: what was the link to the hydra failure?
<clever>
or your copy is older, and its not xz yet
<clever>
its possible that your copy is newer and has a fix
<clever>
are you building with the same nixpkgs hydra used?
<clever>
oh, on yours it works
<clever>
because the src attribute is still pointing to an xz'd file
<clever>
gyroninja: the src ends in .xz, so it needs xz to unpack
<clever>
wedens[m]: bc94dcf5002 is the rev i build 480 from