2018-03-08

<clever> Judson: what nix-env command did you run?
<clever> boomshroom: and checkout the 1.11.16 branch
<clever> boomshroom: yeah
<clever> you have to add it to the search path with -I nix=/path/to/nix
<clever> i havent tested that release-arm.nix against 2.0, so id recomend trying 1.11.16
<clever> though you still also need to nix-env -i nix itself, to root it
<clever> that registers all the paths as being valid in db.sqlite, so nix wont try to delete itself
<clever> that will be at the root of the tar file
<clever> nix-store --load-db < $UNPACK2/nix-path-registration
<clever> boomshroom: or, if you use the make-system-tarball version, just make sure to --load-db the registration file, one sec...
<clever> if you just edit that, insert a url to a tar generated by release-arm.nix, and run it, it should work
<clever> there is an if statement at the top of the script that picks the right tar for your arch
<clever> boomshroom: this generates the exact same tarball that https://nixos.org/nix/install refers to
<clever> boomshroom: one min
<clever> ottidmes: and put an if statement inside it
<clever> ottidmes: use a bash function instead of an alias
<clever> ping-store!? :O
<clever> which reminds me, thats also where `zpool status` is
<clever> import/export are part of zpool
<clever> boomshroom: and/or check `zfs status`
<clever> boomshroom: try to umount and export the pool, then re-import and mount, and see what changes
<clever> boomshroom: anything abnormal in the dmesg?
<clever> does mac have dmesg?
<clever> boomshroom: what if you run lsattr on it?
<clever> gchristensen: any idea why boomshroom cant delete the above file?
<clever> boomshroom_lapto: yeah, i cant see anything fishy like a symlink
<clever> srhb: its a few hours before midnight, due to the tz
<clever> boomshroom: ls -lh
<clever> boomshroom: can you paste me the output of ls on that path?
<clever> boomshroom: what about chmod -R +w ?
<clever> and it fails to build without them
<clever> but some projects have 20 -X flags
<clever> i still prefer bare ghci
<clever> it supports all flags cabal supports
<clever> fresheyeball: runhaskell Setup.hs repl
<clever> boomshroom: what error does that fail with?, and cant you just chmod +w the problem directory and its parent?
<clever> boomshroom: what if you try to just rm that path yourself?
<clever> but cabal the library is
<clever> there is a weird thing in nix's haskell framework, where cabal the binary isnt available
<clever> srhb, fresheyeball: i just make a Setup.hs and runhaskell it
<clever> boomshroom: as root, can you run `strace -o logfile nix-collect-garbage --max-freed 1` and then pastebin that log file?
<clever> boomshroom: ls -lh /nix/store/.links/0w702rv3ddcj5d9mplmhff0c7rias1z9x330z12yg9ik8yzkwsxa
<clever> boomshroom: and what does dmesg say?
<clever> boomshroom: what is it failing to delete?
<clever> stdenv*
<clever> you might be able to use { std, "389-ds-base" }@args: .... args."389-ds-base" as well
<clever> Shell: pkgs."389-ds-base"
<clever> but rebooting to an older generation (f607771d0f5) did fix it
<clever> a rollback without a reboot didnt fix it
<clever> with nixos-unstable 831ef4756e3 i ran into kernel related issues that just stopped amdgpu from working entirely
<clever> copy it or fail :P
<clever> ottidmes: in this case, it forces extra-utils to have zero dependencies
<clever> ottidmes: this line is the cause
<clever> allowedReferences = [ "out" ]; # prevent accidents like glibc being included in the initrd
<clever> ottidmes: not that i know of
<clever> ottidmes: line 49-52, its just a dumb wrapper around cp, and thats it
<clever> ottidmes: cp -L ${pkgs.sedutil-scripts-unwrapped}/bin/* $out/bin/
<clever> ottidmes: just manually cp it with a different cp flag
<clever> ottidmes: thats a safety to prevent you from pulling in a crap-ton of things by mistake
<clever> ottidmes: line 51 does cp -d, which results in the symlink staying intact, nix then pulls in ahh
<clever> ottidmes: symlinks work in the initrd
<clever> so the builds will fail it they happen
<clever> nix doesnt allow such cycles to ever exist
<clever> and one of them also refers to doc
<clever> and doc refers to all
<clever> Lisanna: ive had problems where the binaryes refer to lib and share, and share refers to lib, and lib refers to bin
<clever> Lisanna: also, cycles cant exist between the outputs
<clever> jxf: that will generate a result symlink pointing to the final build
<clever> jxf: one option, nix-build https://github.com/cleverca22/nixpkgs/archive/9f4fa91d8fd.tar.gz -A spotify
<clever> yes
<clever> Lisanna: the whole derivation is a single unit, which must produce all the outputs, and they cant be part of other derivations
<clever> jxf: https://github.com/NixOS/nixpkgs/pull/36467 and it still uses alsa
<clever> outputs = [ "out" ]; ?
<clever> but at this point, does it even need the right output name?
<clever> the post-fix at the end of .outPath is the only thing i can think of
<clever> and keep in mind, you can always // { outputs = fulllist; }; after you call derivation
<clever> to declare that you only have 1
<clever> then you need to set outputs = [ "out3" ];
<clever> also, nixpkgs has something similar
<clever> Lisanna: ah, you would need to map over everything in outputs, and copy all of them from src to dst, and fix up cross-references between them
<clever> what will it mutate?
<clever> Lisanna: ?
<clever> Lisanna: why?
<clever> Lisanna: the only difference is the .outPath
<clever> though libcef.so looks odd
<clever> jxf: also, spotify is just electron, so it might be possible to repackage it
<clever> jxf: if you can find similar libraries in ubuntu (or even use the nix ones maybe?) and create an asound.conf, it may fix your issue
<clever> jxf: under nixos, spotify is trying to use alsa, but pulseaudio has configured a special alsa "driver", that connect to pulseaudio

2018-03-07

<clever> hakujin: and if your a vim user, check out the vim.nix in the repo root
<clever> they dont have enough drive space to build their own updates
<clever> hakujin: this is how i managed a pair of old 32bit netbooks: https://github.com/cleverca22/nixos-configs/blob/master/deployments/netbooks.nix
<clever> you can also just set the targetEnv to "none" and then it will only manage the nix side
<clever> nixops will automate the creation of the machine in ec2, and the copy-closure+activate
<clever> nixops also greatly simplifies things if you want to run a server and do any kind of updates
<clever> the .system at the bottom will generate a directory that contains the closure, but not an AMI image
<clever> hakujin: line 1 of your gist, configuration = { config, lib, pkgs, ... }: {
<clever> hakujin: a nixos module can start with { config, lib, pkgs, ... }:
<clever> hakujin: config.services
<clever> then somebody will need to bump the version in nix and that may fix it
<clever> jxf: which version?
<clever> and will likely have the same issues
<clever> and all nix is doing is re-packaging the .deb file, which could just as easily be installed on ubuntu
<clever> version = "1.0.69.336.g7edcc575-39";
<clever> you just get whatever spotify provided
<clever> spotify is pre-compiled and patchelf'd, so there is no options or optional features
<clever> infinisil: thats nixos only
<clever> 5gig free on my primary desktop
<clever> infinisil: mine runs every day at midnight
<clever> dtz: look up nix.gc in the docs
<clever> symphorien: 1.11 also has `nix-store -l /nix/store/path` for successfull local builds
<clever> jxf: you need to nix-env -iA nixos.spotify
<clever> jxf: there is no default.nix inside .nix-defexpr, thats why it failed
<clever> and machine1 = { ... }: hmmm, no nodes is passed to the nixos instances, not the deployment files
<clever> infinisil: oh, i think you can cheat, nodes.machine1.config would let you store things in a random machine
<clever> infinisil: in the example i linked, 2 files define nixos config for report-server
<clever> but nixos definitions on each machine are merged as you would expect
<clever> there is no way to pass sets between the files
<clever> infinisil: it works identically to just listing several .nix files at `nixops create` or `nixops modify`, except you can manage the list with git
<clever> infinisil: you can make a tree of deployment files with require, the same as imports, but you cant define custom options and pass them around between deployment files
<clever> infinisil: yeah, the require trick in nixops is much more limited then imports
<clever> infinisil: 110 instances of nixos (100 nixos containers over 10 ec2 machines) takes several minutes and several gig of ram
<clever> infinisil: it evals all of them in the same process, one at a time
<clever> infinisil: the memoize builtin also fixes that
<clever> infinisil: i can only see it being useful in nixops, when you want to force all 10 machines to share a single instance of nixpkgs, so nix doesnt have to eval the same version 10 times
<clever> blankhart: yeah, his docs suck, he never made the public key public!
<clever> infinisil: and yeah, that attribute has no way to change service definitions
<clever> infinisil: i think thats more about the services from <nixpkgs/nixos> expecting version A and your custom pkgs set have version B, and now everything breaks
<clever> blankhart: yeah, you will need to either remove that binary cache, or add the caches public key to your nix.conf
<clever> infinisil: why?
<clever> infinisil: ah, i can see how that works
<clever> blankhart: what is the contents of your nix.conf, and what output does nix give when ran?
<clever> blankhart: did you add his public key to your nix.conf file?
<clever> then you can just leave it at the current value
<clever> fyuuri: if nothing has broken, then your probably just not using the software that is likely to break, so the new version is probably also good
<clever> you cant
<clever> if you want to upgrade to a new version, you need to run nix-channel --add as root, to add a new url, and give it the name nixos
<clever> and it wont update anything
<clever> if you mess with the stateVersion, it will break the things it was meant to fix
<clever> things like the type of ssh host keys you had when you installed
<clever> fyuuri: that is the version of the state on-disk, and must not be changed, and it has no effect on what version of nixpkgs you get
<clever> but you cant declaratively control them, only use them
<clever> fyuuri: if you have the channels on root, you can access them at <nixos> and <nixpkgs>
<clever> fyuuri: those are channel names from nix-channel --list
<clever> infinisil: thats likely also why inherit works inside there
<clever> blankhart: how big is "du --max=0 shared server -c -h" ?
<clever> "baz"
<clever> [clever@amd-nixos:~]$ nix-instantiate --eval -E 'let inherit (foo) bar;foo.bar = "baz";in bar'
<clever> the pkgs on line 1 is now a no-op
<clever> line 6, that sets pkgs = { haskell ... };
<clever> i see the problem
<clever> oh
<clever> blankhart: how is this file being ran?
<clever> i almost never see a path starting with something other then ./ or /
<clever> infinisil: yeah
<clever> blankhart: and line 16 has a stray _ that doesnt look right
<clever> blankhart: does it behave any differently if you just do pkgs.runCommand ?
<clever> and you cant mix attributes from several parents when writing a rule
<clever> mog: -a on the above will make it walk up to every parent
<clever> mog: and then with this, i can see some stats on it
<clever> [root@amd-nixos:/etc/udev/rules.d]# udevadm info -q property /sys/devices/pci0000:00/0000:00:16.0/usb13/13-1/13-1:1.0/0003:046D:C215.0005/input/input18/js0
<clever> in my case, i get an entry like this
<clever> KERNEL[344792.356680] add /devices/pci0000:00/0000:00:16.0/usb13/13-1/13-1:1.0/0003:046D:C215.0004/input/input17/js0 (input)
<clever> mog: ok, run this, then reconnect again: udevadm monitor
<clever> mog: also, have you checked `journalctl -f` during the disconnect/reconnect
<clever> mog: so if you instead do ${/home/mog/bton.sh} within a nix string, it will be copied into the store automatically, and then it wont complain
<clever> mog: aha, it checks that they "exist", as in, they can be read from inside a nix sandbox
<clever> it may be falsely complaining about absolute paths
<clever> mog: ah, i think there was something to auto-detect running things not in the default PATH
<clever> #!/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh
<clever> i see sh scripts in my udev rules
<clever> ./99-local.rules:SUBSYSTEM=="usb_device", ACTION=="remove", RUN+="/nix/store/0agl54945fx9xi8hqdzaidf27dgmjbz9-virtualbox-5.2.6/libexec/virtualbox/VBoxCreateUSBNode.sh --remove $major $minor"
<clever> mog: if the script has a #! and is +x, you can just RUN+="/home/mog/bton.sh"
<clever> hyper_ch: i forgot about units when i configured justdoit.nix to make a 40gig swap, lol
<clever> sphalerite: and yeah, zfs cant be shrank, so such a change requires a reinstall, my laptop is currently stuck with a 40mb swap
<clever> sphalerite: thats why i have a dedicated swap partition, outside zfs
<clever> it will let me allocate ram i dont yet have, and then zfs mostly gives up blocks before the swap can kick in
<clever> sphalerite: i find that 64gig of swap makes the kernel just not complain
<clever> sphalerite: ah
<clever> sphalerite: thats very similar to `echo 1 > /proc/sys/vm/drop_caches`
<clever> kitttn: substituteAll only works for tokens @wrapped@ with @'s
<clever> ottidmes: though i'm not 100% sure it works inside those
<clever> ottidmes: inside the <>'s
<clever> mbrgm: so if you omit that, you wind up with /path/to/nixcfgand/its/subdir
<clever> mbrgm: <nixcfg> returns a path without a trailing slash
<clever> ottidmes: you can also do <nixcfg/${hostName}/config/openssh/root/id_ed25519.pub> i think
<clever> ottidmes: mostly just preference and if you want to see errors at compile-time or boot time, lol
<clever> ''-DCMAKE_INSTALL_PREFIX=''${out}/instdir'' would escape it so it becomes the bash var out
<clever> ${out} is a nix level variable, but out is only defined at the bash level
<clever> 846*
<clever> 864 may be related?
<clever> greglearns: hmmm, maybe the nixops repo would be better then, so the nixops people see it right away
<clever> greglearns: its best to open an issue within nixpkgs
<clever> greglearns: comments on commits are very easy to miss
<clever> i even see your username on the comments there! heh
<clever> greglearns: the fix is only going to be in the 18.03 channel, when it comes out later this month
<clever> greglearns: that doesnt work when using an nvme drive
<clever> greglearns: the ami contains a 2gig disk image, on the first bootup, it has to auto-resize its own partitions and the FS within
<clever> greglearns: i heard something about the auto-resize not supporting nvme drives at the moment
<clever> greglearns: what does fdisk say about the root drive?
<clever> kitttn: using small GC's like that lets you get X mb free, without destroying too much and loosing your dl cache
<clever> kitttn: so if you do `nix-collect-garbage --max-freed 10M` it will delete 10mb worth of garbage, starting with the failed builds
<clever> kitttn: and the garbage collector will delete those failed builds first
<clever> kitttn: any build that fails will automatically be garbage
<clever> greglearns: what does fdisk say about the drive?, and did you change ebsInitialRootDiskSize before or after the deployment?
<clever> kitttn: but if you perfectly undo a change to the .nix file, the hash will match up, and nix will reuse some of the "garbage", making it not-garbage again
<clever> kitttn: anything older then that is garbage and can be deleted
<clever> kitttn: the last result nix-build made will be pointed to by a result symlink, which protects it from GC
<clever> kitttn: yeah, the default is to run genericBuild, which handles unpack, patch, configure, make, and install
<clever> kitttn: the buildInputs are flattened down to a simple string, and that string is what gets hashed
<clever> the strings in the .nix file are part of that hash
<clever> kitttn: every $out is unique, based on the inputs, so it will never be able to change a path that is already in use elsewhere
<clever> kitttn: just do nix-build, it cant break things
<clever> jwynn6: if grub was unable to read /boot, it would drop into a rescue shell
<clever> kitttn: if you only want to read the source, you could just ls -lh $src
<clever> kitttn: also, fetchFromGitHub does the unpacking in this case, and unpackPhase is just a recursive cp
<clever> kitttn: its more that the directory lacks the +w bit by default, and even though you have permission to give yourself write, rm -rf cant delete it
<clever> jwynn6: try using something like f12 to manually boot from each drive
<clever> jwynn6: ah, then it should just work, which drive is it set to boot from?
<clever> kitttn: chmod -R +w thatdir
<clever> jwynn6: is legacy booting enabled in the bios?
<clever> jwynn6: yeah, that looks like a normal grub stage 2
<clever> jwynn6: at offset 0x120, do you see an the text from grub?
<clever> jwynn6: hexdump -C /dev/sda2 | head -n30
<clever> jwynn6: what partition is the bios boot partition?
<clever> jwynn6: the strings command is part of binutils, but i wouldnt run it on a partition
<clever> 2
<clever> clever@c2d ~ $ nix-instantiate -E '1+1' --eval
<clever> jwynn6: if you run something like this against the bios boot partition, do you see a string like 00000120 6e 67 00 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 |ng......Geom.Rea|
<clever> [nix-shell:~]$ hexdump -C /dev/sde1 | head -n30
<clever> jwynn6: and both those drives have bios boot partitions that are not mounted/formated?
<clever> jwynn6: what is boot.loader.grub.device(s) set to?
<clever> jwynn6: efi or legacy booting?
<clever> nick_l: that is setting a config entry called data_subnet, so there must be a matching options.data_subnet to define its type
<clever> nick_l: why are you using inherit then?
<clever> nick_l: can you gist that file?
<clever> nick_l: the config on line 15 refers to line 24, which is an empty set
<clever> nick_l: aha, yeah, the rec is to blame
<clever> nick_l: can you paste the exact error?
<clever> nope
<clever> nick_l: nix code can also be used to auto-generate the options, just use map and listToAttrs
<clever> nick_l: options.stuff = mkOption { ... }; and then in every file, do stuff.thing1 = ... and stuff.thing2 = ...
<clever> nick_l: define a single option of type attrs, then store everything inside of that
<clever> you can set the default value to refer to the second option with type attrs
<clever> nick_l: also, you have to reference it via config, config.udp_security_group.value;
<clever> nick_l: it needs its own mkOption, or nixos will refuse to allow it
<clever> and then you refer to the attrs one in the default of the str one
<clever> then you need to define 2 options, one with the type of attrs, and one with a type of str
<clever> nick_l: then tfvars.nix should set it to a string
<clever> nick_l: try type = types.attrs;
<clever> nick_l: also, you need to adjust the type on line 13 of the pastebin some
<clever> nick_l: thats what imports does
<clever> nick_l: you want to just omit the default, tfvars.nix will set the value
<clever> [clever@amd-nixos:~]$ cat /run/wrappers/bin/fusermount.real
<clever> /nix/store/y76fs08y8wais97jjrcphdw2rcaka1qa-fuse-2.9.7/bin/fusermount
<clever> mfiano: they are in different versions of fuse
<clever> /nix/store/5b51q0sb2c08fnz0sxfa4a339ycx16i5-fuse-3.2.1/bin/fusermount3
<clever> /nix/store/y76fs08y8wais97jjrcphdw2rcaka1qa-fuse-2.9.7/bin/fusermount
<clever> nick_l: can you gist all of the involved files?
<clever> nick_l: quoting it breaks the path magic in nix
<clever> nick_l: so your nixops file should look like this: { machine1 = { config, ... }: { nixos config; }; }
<clever> nick_l: the config param is at the nixos level, not the nixops level
<clever> nick_l: this allows most of nixos to just throw things into system.build.whatever, and then later read config.system.build.whatever in another file
<clever> nick_l: you can create an option of type attribute set, then nix just lets you stick almost anything in there
<clever> nick_l: what are you trying to do exactly?
<clever> nick_l: those are nixos features
<clever> nick_l: allvars.nix can optionally do that
<clever> nick_l: only if you also define options.foo to be a valid option using mkOption
<clever> nick_l: { config, pkgs, lib, ... }: { imports = [ ./allvars.nix ]; }
<clever> nick_l: { config, pkgs, lib, ... }:
<clever> nick_l: nixos will merge whatever values that sets, and make them available in the config attr passed to every module
<clever> nick_l: if you add the file to imports (not import), then imports will be searched automatically and recursively
<clever> nick_l: how are you having to repeat things when just adding imports = [ ./allvars.nix ]; to the nixos configs?
<clever> nick_l: if you try to create a machine in nixops called defaults, its config will be merged into every other machine in the file
<clever> nick_l: defaults = { imports = [ ./allvars.nix ]; }; within a nixops deployment file will apply to every machine in the deployment
<clever> nick_l: have you seen the special defaults in nixops?
<clever> nick_l: cant you just add imports = [ ./allvars.nix ]; to the main nixos config?
<clever> nick_l: import doesnt obey imports
<clever> nick_l: imports only works if the file containing it is within another imports field
<clever> nick_l: so "with (import ./allvars.nix)" creates an attr called imports, that contains the path to foo.nix
<clever> nick_l: imports is a special attr in nixos, nix alone doesnt treat it specially
<clever> ottidmes: yeah
<clever> rawtaz: its not officialy supported to install startx
<clever> rawtaz: services.xserver.enable = true;