2018-08-17

<clever> LnL: yeah...., there is line 150 lines missing from the start....
<clever> *looks*
<clever> which would have caused merge conflicts for every single open pr
<clever> i think that set was moved into a let block or funtion of some kind, and that would have required adding 2 spaces to every single line
<clever> LnL: all-packages.nix is also indented wrong, there is a comment near the start saying so
<clever> the variable parts will depend on what you have named things
<clever> BlessJah: nixos1808.callPackage <nixosunstable/pkgs/foo/bar> {};
<clever> Thra11: yeah, and you need the sandbox on to ensure it fails loudly
<clever> Thra11: nix will make the PATH pure, but only the sandbox stops scripts from "fixing" $PATH
<clever> its essentially a proxy
<clever> johanot: the fact that i'm using an ipv6 tunnel is what breaks netflix
<clever> johanot: if my ISP offered v6, then the geolocation would say canada, and everything would be fine
<clever> and then its just 100% ignoring nix!
<clever> or export PATH=/usr/bin/
<clever> Thra11: it might simply be /usr/bin/g++
<clever> Thra11: is this on nixos or another distro?
<clever> johanot: in the past, i was successfully able to get the american lineup, using ipv6
<clever> so i have a 2nd wifi that lacks ipv6, just for netflix use, lol
<clever> netflix thinks i'm trying to get around region lockout, so it refuses to play anything!
<clever> johanot: oh, and the tablet on my main wifi, has ipv6, which is a tunnel, so it exits in the wrong country
<clever> johanot: i just use the tablet
<clever> johanot: due to that, ive just given up on netflix in the laptop or desktop :P
<clever> johanot: yeah, ive had to play netflix inside virtualbox, with windows 10, lol
<clever> johanot: ive found that the android netflix app can remotely control the netflix app on a ps3 (and likely the chromecast), and skip the entire streaming layer
<clever> > hello.drvPath
<clever> aanderse-work: only if you have a derivation object
<clever> Xyliton: $out/include/
<clever> ocharles: can you rename the file in the gist to have a .nix extension?
<clever> sphalerite: there is another mode in nix, that already disables getEnv
<clever> so it just ignores the cache when you use scopedImport
<clever> but when that was written, you couldnt use an attrset as a key
<clever> so if you re-import the file again, it can reuse the previous Value
<clever> and if you import a given file, with no overrides, nix will save the file into a hashmap, keyed on path
<clever> ocharles: as for the import cache, `import` is just an alias to `scopedImport {}`
<clever> ocharles: this injects an <ssh-config-file> entry
<clever> sphalerite: yes
<clever> ocharles: oh, i also already have an example
<clever> and if somebody where to overwrite __nixPath, then <nixpkgs> would just obey the new value
<clever> ocharles: <nixpkgs> gets parsed as-if you had typed __findFile __nixPath "nixpkgs"
<clever> ocharles: yeah, one min
<clever> but, all of this breaks the import caching
<clever> so when foo.nix calls `import ./bar.nix`, its actually calling your wrapper, which can then propagate things
<clever> but, you can use scopedImport to overwrite the import function
<clever> bar.nix wont obey the changed you forced
<clever> if you use scopedImport to import foo.nix, then foo.nix imports bar.nix
<clever> but, it can overwrite the import function...
<clever> ocharles: also note that scopedImport is not recursive
<clever> scopedImport can overwrite them
<clever> true and false, are technically global variables, that are defined to the values you would expect
<clever> ocharles: it can even swap true and false!
<clever> ocharles: it lets you do fun things like remap foldl to foldr :P
<clever> ocharles: no, use the code from the PR as an example
<clever> ocharles: if you use that when importing eval-machine-info, it will be able to change what <nixpkgs> resolves to
<clever> ocharles: this uses builtins.scopedImport to overwrite the __nixPath variable in the glboal scope
<clever> yeah, i see the problem, one sec
<clever> one min
<clever> ahh
<clever> then you shouldnt need any <nixpkgs> at all in your codebase
<clever> and to have a json file within the project, that can fetch its own nixpkgs
<clever> what i try to do, is to not supply nixpkgs with -I at all
<clever> and give it the full path
<clever> just use the local-path type
<clever> that also returns a set, not a path
<clever> so that wouldnt really fit into -I anyways
<clever> and i think the type nix is just a bare nix expresion
<clever> ah
<clever> ocharles: can you link your hydra's UI?
<clever> with the name you gave in the build inputs config
<clever> ocharles: hydra adds a -I for every build input you configure on the jobset
<clever> mplayer has support for both methods, and they claim the runtime detection results in slightly worse performance
<clever> and the wiki page doesnt say which ones the opcode is in
<clever> gchristensen: my desktop has sse4a and misalignsse
<clever> gchristensen: sse4_1 and sse4_2, along with some older ones
<clever> gchristensen: what sse flags does 'grep sse --color /proc/cpuinfo' show?
<clever> Dezgeg: ah yeah, that helps a lot for these things
<clever> gchristensen: how old is the cpu?
<clever> gchristensen: also, is this failing on the host or in qemu?
<clever> ocharles: try reproducing the warning via nix-instantiate -vvv
<clever> gchristensen: if possible, run it under gdb and then disassemble that area
<clever> gchristensen: something at instruction pointer 7ffff748d796 ran an invalid opcode
<clever> but typing just `buildPhase` will always use the function version
<clever> TweyIV: the stdenv will prefer the variable if it exists
<clever> TweyIV: also of note, there can be BOTH a buildPhase function, and a $buildPhase variable
<clever> rauno: why do you want to rebuild a package?
<clever> inquisitiv3: it could just be that you did a nix-build command and forgot about it
<clever> inquisitiv3: thats what nix-build does by default
<clever> but which 1gig it selects is random, so the chance of loosing something important depends on how much garbage you have
<clever> that will only delete 1gig of garbage, rather then all garbage
<clever> inquisitiv3: a secondary option is `nix-collect-garbage --max-freed 1g`
<clever> inquisitiv3: figure out every path of important, and make indirect roots with `nix-build '<nixpkgs>' -A hello -o hello-root`
<clever> garbage collect less often, and avoid GC'ing when your about to loose internet
<clever> inquisitiv3: if the nix-shell is still open, it wont delete those things
<clever> i'm still waiting for a copy of your configuration.nix
<clever> yeah, it has some risks
<clever> there is a gist command in nixpkgs
<clever> ashkitten: can you gist the whole configuration.nix, nix-channel --list, and the error?
<clever> ashkitten: can you gist the whole configuration.nix, nix-channel --list, and the error?
<clever> ashkitten: what kind of problems?
<clever> sir_guy_carleton: does the name have a - in it?
<clever> yeah, that all looks good
<clever> the module attribute contains the same value you would normally put into configuration.nix
<clever> adamantium: line 9-ish, module = { lib, ... }:
<clever> adamantium: and add lib to the tart of the module
<clever> adamantium: networking.wireless.enable = lib.mkForce false; maybe
<clever> what was the exact error?
<clever> it already has a flag set there to support zfs
<clever> adamantium: there is a chunk of nixos config in rescue_boot, just add normal nixos options to it
<clever> patchShebangs .
<clever> kenshinCH: sounds like you need to run patchshebangs over things
<clever> so it would be a lot simpler to just use nixos-unstable for everything
<clever> but your nixos modules are not aware of that change
<clever> oh, and spl was merged into zfs
<clever> ive not looked into that feature
<clever> without that, it will obey /root/.config/nixpkgs/config.nix
<clever> yeah, that will do it
<clever> ,unfree

2018-08-16

<clever> adamantium: this is something i did back when i wasnt commited to nixos, and i was still using the gentoo grub to source the nixos grub.cfg
<clever> adamantium: i had source inside a menuitem, so it only sources when i tell it to
<clever> adamantium: they could even share a zpool, if they have different roots
<clever> adamantium: you could potentially have 2 /boot partitions, for different OS's (even 2 nixos's!), and then have a menu option that sources the other one on-demand
<clever> adamantium: in the past, i have used the source command in grub.cfg to source another grub.cfg file
<clever> we need a way to add another linux based OS to the menu
<clever> LnL: nixos just doesnt have enough options for systemd-boot
<clever> ~460mb cost
<clever> LnL: this puts the entire nixos installer into /boot, along with a grub option to select it
<clever> then it had other uses, so i advertised it for those :P
<clever> adamantium: so i could boot my laptop into a 2nd "os", and move nix to its own dataset
<clever> adamantium: thats exactly what i made rescue_boot.nix for
<clever> adamantium: just boot.shell_on_fail by itself
<clever> either
<clever> adamantium: add it to the kernel params from grub, or boot.kernelParameters
<clever> adamantium: you can also use one of these to get a shell inside the initrd, then just manually do zpool import --force
<clever> adamantium: possibly
<clever> adamantium: if its a dual-boot on the same pool, sharing the hostid is perfect
<clever> adamantium: if both distros have the same hostid, then nixos wont notice it was last in use by a different "machine"
<clever> adamantium: force is only needed if the pool was last used by a different hostid
<clever> adamantium: every attribute under boot.loader is a seperate bootloader
<clever> adamantium: you cant use both bootloaders at once, and generationsDir wont work on its own
<clever> adamantium: generationsDir.copyKernels only has an effect if your using generationsDir.enable
<clever> adamantium: yep
<clever> adamantium: yeah
<clever> adamantium: since your using grub, boot.loader.grub.copyKernels = true;
<clever> adamantium: poor zfs support within grub, it was never tested on a directory with 100000 entries
<clever> adamantium: that is what this option is for: https://nixos.org/nixos/options.html#copyker
<clever> adamantium: the path length wont change, but as more directories get added to /nix/store it may break booting
<clever> neonfuz: use --user with start
<clever> neonfuz: enable doesnt work on nixos
<clever> so you need systemctl --user
<clever> neonfuz: its a user service, not a system service
<clever> neonfuz: did you nixos-rebuild?
<clever> adamantium: and it failing to even find kernels because there are too many directories in store
<clever> adamantium: ive heard stories of grub taking 5 minutes to load because it doesnt read the index in /nix/store properly
<clever> inquisitiv3: the read-only is on the mount point, not the directory
<clever> inquisitiv3: mount /nix/store /nix/store -o bind,ro
<clever> adamantium: i dont really trust grub with zfs, so i use an ext4 /boot/
<clever> inquisitiv3: nixos bind-mounts /nix/store read-only by default to stop you
<clever> adamantium: yeah
<clever> adamantium: ive not tried zfs support in grub, so it may need something like that to deal with zfs
<clever> not `rm result/`
<clever> inquisitiv3: rm result
<clever> ambro718: yep, just dd to the root of the drive, it already has partition tables
<clever> if its just a folder on / then you will need to insert a /boot onto the paths on lines 17&18 of the nix file
<clever> and that the existing grub.cfg has mapped $drive1 to that partition
<clever> adamantium: the grub config expects that /boot/ is the root of a partition
<clever> gchristensen: sometimes you just need to rip the safety labels off and let natural selection take its course :P
<clever> because if you use it the wrong way, it wont even be in the sandbox, and you will catch the problem a lot sooner
<clever> srk: and any time your using that, it helps to make sure the nix sandbox is enabled
<clever> and if you use that on the kernel params in script.ipxe, then script.ipxe wont depend on the init
<clever> but "${builtins.unsafeDiscardStringContext hello}/bin/hello" just throws that out, so now you have the path, but dont depend on it
<clever> so when you do "${hello}/bin/hello" it knows that the string depends on the hello package
<clever> srk: all strings in nix have some magic context, that allows nix to track dependencies
<clever> srk: builtins.unsafeDiscardStringContext
<clever> but nothing stops you from putting the same kernel+initrd pair on /boot and just loading them with grub
<clever> the netboot scripts in nixpkgs are for creating a kernel+initrd pair, that have the rootfs in the initrd, and booting it over the network
<clever> so you will need a sizeable /boot
<clever> adamantium: note, that it uses about 300mb on /boot
<clever> yep
<clever> adamantium: just copy that file into /etc/nixos/ and add ./rescue_boot.nix to the imports list
<clever> adamantium: this module adds a full nixos installer into /boot/, and then you can just select that and repair a missing /nix if you wanted to
<clever> adamantium: yeah, as long as i have the config, and maybe the nixpkgs rev, i can repair almost any damage to /nix (except the nix-env profile list of packages)
<clever> you have snapshots of /etc/nixos, so you can just rollback the config and nixos-rebuild
<clever> it keeps daily and monthly snapshots
<clever> and if / is on the same dataset, you are loosing backups of /
<clever> and then you have to manually destroy snapshots to get your space back
<clever> adamantium: the snapshot keeps a copy of everything you GC, and then you gain zero free space
<clever> snapshots on /nix make it difficult to garbage collect
<clever> then i have automatic snapshots on / but none on /nix
<clever> i prefer having seperate datasets for / and /nix
<clever> yeah
<clever> adamantium: i dont really use the zfs rollbacks much, nixos generations handle that task fine
<clever> Henson: which prevents bugs like moving things out of the store
<clever> it makes the store read-only, so root cant modify files in the store
<clever> adamantium: nixos always does that
<clever> both of those are identical i believe
<clever> and line 61 will be wrong on 32bit, you want --interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"
<clever> line 63 is also not needed, the stdenv already defaults to the current system
<clever> Henson: if you run ldd after patchelf, then you dont need LD_LIBRARY_PATH
<clever> Henson: line 24, you can change the cp to: cp -a ${./69-basler-cameras.rules} .... and then delete line 8, and repeat for other similar things
<clever> Henson: `set -e` is not needed, the stdenv does that for you
<clever> Henson: can you gist what you have now and i can check it for anything minor?
<clever> gchristensen: i easily missed the notice Sigyn sent when i started to flood a bit
<clever> kalbasit[m]: to start with, try adding boot.kernelParams = [ "console=ttyS0" ]; and then nixos-rebuild boot and reboot
<clever> kalbasit[m]: that effects the initrd as well, and handles the luks passwords
<clever> kalbasit[m]: if you want linux on the serial and dont care about grub, you need to add console=ttyS0 to the kernel params
<clever> Henson: its refering to line 9 of the old default.nix
<clever> Henson: ${pylonArchive} is no longer a shell variable but a nix variable
<clever> samueldr: give up and use grub? lol
<clever> Henson: if you post the new nix file to gist, i can also check it for any other issues
<clever> Henson: nix-store --verify --check-contents
<clever> nix believes the file still exists, so it doesnt copy it again
<clever> Henson: your moving it out of /nix/store/ which then breaks everything
<clever> mv ${baslerUSBIDs} ${out}/nixstow.packages/Debian-8.2/usr/share/misc/usb.ids
<clever> 28
<clever> Henson: after making those changes, you can post the new version to a gist and any errors you may be having
<clever> coreutils, gzip, and many others are in the default stdenv, so those too can be deleted
<clever> and then you dont need binPath, so line 32 can go as well
<clever> when you use buildCommand, PATH is handled entirely for you, so you can omit line 8
<clever> those are more examples of how it works internally, doing it that way heavily limits what you can do
<clever> Henson: first, paste the entire contents of builder.sh into buildCommand = '' .... ''; in the nix file, and delete args/builder
<clever> Henson: it is much much simpler to write these things if you dont use builder/args
<clever> Henson: can you gist your files?
<clever> so nix ignores that -I entry, and goes to the next thing in $NIX_PATH
<clever> which probably doesnt exist
<clever> sb0: yeah, because when nix does <nixpkgs> it resolves to ~/nixpkgs-unstable/nixpkgs
<clever> sb0: the same as -I in gcc
<clever> sb0: -I foo/ and <nixpkgs> will try to use foo/nixpkgs
<clever> sb0: oops, -p not -E
<clever> both parts are using types.submodule
<clever> sb0: nix-shell -E 'python3.withPackages (ps: with ps; [ h5py ])' -I nixpkgs=$HOME/nixpkgs-unstable
<clever> sb0: you cant mix -p and default.nix files
<clever> this is a submodule, inside a submodule!
<clever> services.nginx.virtualHosts."www.example.com".locations."/".root = /foo;
<clever> this is a simple example
<clever> ldlework: yeah, thats part of how submodules work
<clever> those sets still have types for all of there keys
<clever> so its identical to fileSystems = [ { mountPoint = "/"; foo = ...; } ];
<clever> ldlework: line 62 then maps that into the mountPoint option
<clever> so when you set fileSystems."/".foo, it will call this function with name == "/"
<clever> ldlework: and the submodule has an extra argument called name
<clever> yeah
<clever> its a fairly complex area of nixos
<clever> other code in the same file should use something like map to iterate over all values, and apply them to another config option
<clever> label has a type of nullOr nonEmptyStr, so it can only be set once, and trying to merge is a fatal error
<clever> if you set fileSystems."/" = ...; in 2 different files, it will just recurse into both, and merge based on the types in the submodule
<clever> that is a second way of doing it
<clever> these 2 seem to be compatible, because i had no trouble mixing the 2 and adding my own things to fileSystems, lol
<clever> that one is using loaof (list of attribute set of) and a submodule
<clever> ldlework: this is where the rest of the options are defined: https://github.com/NixOS/nixpkgs/blob/release-18.03/nixos/modules/tasks/filesystems.nix#L149-L162
<clever> that is one way of doing it, there are about 3 i think
<clever> this defines fileSystems.<name>.iscsi.enable
<clever> ldlework: this one always installs vim, but can adjust how complex the vim is: https://github.com/cleverca22/nixos-configs/blob/master/vim.nix
<clever> ldlework: this one has a single enable flag: https://github.com/cleverca22/nixos-configs/blob/master/arcstats.nix
<clever> ldlework: this is a rather basic one, that doesnt actually have any options
<clever> sb0: drop the nixos.
<clever> ldlework: they just define some options, piece together a few strings, then set other options, usually ending in systemd or environment
<clever> ldlework: that sounds like what 99% of nixos modules do
<clever> cmcdragonkai: depends on if you need to complete any builds to do that
<clever> foo.${variable}.enable
<clever> and then imports grabs a normal nixos module
<clever> by just setting targetHost on each machine, nixops will ssh into it and take over
<clever> ldlework: here is how i manage my house: https://github.com/cleverca22/nixos-configs/blob/mast
<clever> and then if you just swap that file out, you can test the same setup there
<clever> a common reason to split them up like in your gist, is that you can create a sophos-vbox.nix, that sets deployment.targetEnv = "virtualbox"; instead
<clever> in your gist, the only resource is an ec2 keypair
<clever> and resources is the non-machine stuff defined in the nixops files
<clever> nodes is a set of every other machine in the cluster, so you can do nodes.sophos.config,services.whatever to read the config of another machine
<clever> nixops adds 2 extra arguments that nixos modules can accept, nodes, and resources
<clever> { imports = [ (import ./sophos-aws.nix).sophos (import ./sophos.nix).sophos ]; }
<clever> so its basicaly as-if you had the following in configuration.nix
<clever> and then it does a nixos build over each list
<clever> i believe it creates a list of modules, grouped by the hostname (the key in the nixops file)
<clever> if they dont match, then nixops will create 2 seperate machines
<clever> the attribute names have to match for it to merge them
<clever> and will then merge them all, based on the option types
<clever> the nixos module framework takes 100's of modules like this
<clever> you can just do { config, pkgs, resources, ... }: and put all of that into one file if you choose to
<clever> ldlework: { resources, ... }: is still a nixos module
<clever> ldlework: lines 8 and 5 are both nixos modules, the ... causes them to just ignore some of the args that the other happens to not ignore
<clever> ldlework: gist helps when dealing with multiple files
<clever> ldlework: the exact same way as nixos modules being added to the imports field of configuration.nix
<clever> ldlework: resources is a argument nixops adds to all nixos modules