<clever>
jlv: the `import ./nixpkgs {}` is likely loading the same overlay, causing infinite recursion
<clever>
fresheyeball: the nix-ssh user is configured to never give a shell, and to directly run nix-store, so its more secure when the keyfile lacks a passphrase
2019-09-09
<clever>
fresheyeball: for example, nix-build, ran inside a nix-shell, will use the shell based exprs
<clever>
fresheyeball: i try to avoid lib.inNixShell, it causes things to behave in weird and unexpected ways
<clever>
syd: $src will always be read-only, and by default, cp preserves permissions, so you need to `chmod -R +w` the dest after you copy
<clever>
rawtaz: who needs state? :D
<clever>
rawtaz: i call it reproducible!
<clever>
rawtaz: i have some qemu setups configured to exit when you try to reboot, and then rollback the entire disk
<clever>
rawtaz: in some cases, a machine cant boot while out of space, so id prefer fixing it without a reboot
<clever>
fendor_: nix will think the files exist, when they dont, `nix-store --verify` will test for damage
<clever>
fendor_: manually delete the tar with plain rm, then do --delete also
<clever>
fendor_: if not, you need to manually delete something non-nix first, then follow up with a small --max-freed
<clever>
fendor_: `nix-collect-garbage --max-freed 1M` can sometimes work
<clever>
sphalerite: i skimmed over it, and it looks good at a glance
<clever>
eylusion: this work has already been done 3 or 4 times
<clever>
eylusion: you may want to look at the existing minecraft package in nixpkgs, and copy that
<clever>
and the shell script its using will instead not use kvm, if /dev/kvm doesnt exist
<clever>
then it will think it has kvm support, and try the build
<clever>
within the docker container
<clever>
Ilya_G: edit /etc/nix/nix.conf to have the middle line i just pasted above
<clever>
2019-09-09 14:55:57 < Ilya_G> error: a 'x86_64-linux' with features {kvm} is required to build '/nix/store/02vqmq7lknz31gc5yx22qnvlfdzmx1pf-nixos-disk-image.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, nixos-test}
<clever>
rndd: you have to run patchelf on it to fix the interpreter
<clever>
shadrach: yeah
<clever>
shadrach: i believe nixops supports macos and azure
<clever>
try listing how many cards are available
<clever>
being built with cuda, and being able to talk to the drivers are seperate issues
<clever>
shadrach: ive done cuda on nixos before, and when the hardware is meant for cuda, it works perfectly
<clever>
yeah
<clever>
shadrach: highly likely to run into problems
<clever>
shadrach: ubuntu wont work either, you would have to either use the system cuda, or nixos
<clever>
and the libraries have to match the version of the kernel
<clever>
shadrach: pretty sure you have to be running nixos for the cuda to work, since it involves driver parts
<clever>
shadrach: and where does it fail?
<clever>
shadrach: what os did you run that nix-shell on?
<clever>
shadrach: what does line 56 of that file say?
<clever>
shadrach: your trying to build a linux kernel on darwin?
<clever>
shadrach: the nix package likely hasnt been tested/fixed on macos
<clever>
but if the dir itself is deleted (the -r in rm -rf), you get that back (as long as another snapshot wasnt made)
<clever>
yeah, since you have snapshots on, deleting files will actually consume more disk space, as it creates new versions of the dir listing, to mark them as not in the dir anymore
<clever>
iqubic: rm -rfv
<clever>
and if you are below something like 5% free, writing anything is cpu intensive
<clever>
also, in the case of zfs, when you remove a file from a dir, it has to write the new version of that dir listing to disk
<clever>
zfs just does the hard work in the background, there is a garbage collector somewhere
<clever>
ive heard that xfs has faster deletes for large files
<clever>
simpson: ext3 i think also does that
<clever>
simpson: and for some FS's the time to delete a file scales with the size of the file
<clever>
Ashy: nix-build creates a result symlink pointing to the ... result!
2019-09-07
<clever>
so it updates faster
<clever>
yeah
<clever>
multun: it takes a dozen hours to compile
<clever>
yep, master has 69, and unstable is still 68
<clever>
> firefox.name
<clever>
gyroninja: and unstable-small JUST updated, but its using a commit that is 2 hours old
<clever>
so unstable is 6 days behind master, and updated 1 day ago
<clever>
so, 1 day ago, the commit from 6 days ago finished testing, and the channel updated
<clever>
gyroninja: BUT, unstable is pointing to a commit from 6 days ago!
<clever>
gyroninja: 1 day ago for unstable, 15 hours ago for 19.03
<clever>
bikki[m]1: correct
<clever>
infinisil: no entry for nixpkgs master?
<clever>
> master.firefox.name
<clever>
but the stable channels typically only get security fixes and browser updates, so they update much faster
<clever>
so it can sometimes take longer for changes to go from master->unstable
<clever>
bikki[m]1: because unstable is so unstable, it sometimes doesnt pass automated testing, which holds the channel back
<clever>
when the user decides to manually run `upgrade-boot` in a root shell?
<clever>
and you tell the user to enable the right one for their platform
<clever>
samueldr: what if you just have nixos modules for each device, that install an upgrade-uboot script into systemPackages?
<clever>
samueldr: that can make things more complex...
<clever>
sphalerite: but thats just the config, does it also install the grub binaries?
<clever>
sphalerite: ah
<clever>
samueldr: it should probably use the same install-bootloader stuff that the rest of nixos uses, on x86
<clever>
emily: the number mostly refers to the cpu, and the letter, the accessories (usb hub and such), the + is just a new version that is backwards compat
<clever>
willghatch: its in the nix-index package
<clever>
romildo: override the package to not make a setup hook
<clever>
omnipotententity: ive configured my rpi's to netboot, without u-boot, but you have to burn a fuse to do it, and its very picky
<clever>
willghatch: yes, lol
<clever>
willghatch: buildFHSUserEnv isnt meant to be used for compiling, so it doesnt
<clever>
willghatch: stdenv.mkDerivation will handle .dev for you
<clever>
willghatch: i'm not sure if buildFHSUserEnv will properly work with gcc, have you tried libuuid.dev ?
<clever>
ddima: ^^
<clever>
,locate
<clever>
willghatch: nix-locate confirms that it should be in libuuid, can you pastebin your nix expr?
<clever>
libuuid.dev 3,402 r /nix/store/ybncb8fp9xfvqw6axf58km865lxkdzv7-util-linux-2.29.2-dev/include/uuid/uuid.h
<clever>
,locate uuid uuid.h
<clever>
,locate uuid.h
<clever>
i think the kernel is responsible for calling exit_boot()
<clever>
xlibs*
<clever>
for some weird reason, its in xlibx.libXi
<clever>
xlibs.libXi.dev 36,014 r /nix/store/0k14cs4zyy7bl7r3r8hgc5nqp16f10aj-libXi-1.7.9-dev/include/X11/extensions/XInput.h
<clever>
willghatch: xorg.xinput does not contain an XInput.h
<clever>
ah
<clever>
Acou_Bass: also have a look at security.acme.certs in the nixos options
<clever>
mac10688: services.mysql.package only controls the version the systemd service runs
<clever>
and then incrementally edit the config to null out the differences
<clever>
omnipotententity: if you nix-diff the .drv for /run/current-system, and nixos-rebuild dry-run, you can see how your cfg differs from the running os
<clever>
omnipotententity: nix-diff
<clever>
sb0: they may exist, and i just didnt look hard enough
<clever>
zeta_0: but there is the pmount program, that does most of the work, so you could modify xmonad to run pmount maybe?