2018-10-12

<clever> Shados: if you want to force the entire build to happen remotely, you can use tricks like nix-instantiate, nix-copy-closure the drv over, nix-store -r the drv remotely, then nix-copy-closure the result back
<clever> Shados: nix doesnt know which things are going to build locally, which remotely, and which on a different remote slave
<clever> Church-: not likely, but i have gotten ghc to max out 32gig, lol
<clever> Church-: it might be low on ram
<clever> samueldr: my original plan, was to auto-generate dns and dhcp config, to assign IP's to macs, and map names to ip, and back
<clever> samueldr: it can do things like generate a PTR record for dns
<clever> samueldr: this allows you to manipulate IP's (v4 and v6) in nix
<clever> samueldr: oh, here is a random library i made, and then never used, lol: https://github.com/cleverca22/nix-tests/tree/master/ip-magic
<clever> samueldr: it may suddenly sprout another 4 ways of booting nixos, lol
<clever> disasm: i just run wpa_passphrase as root, and restart the service!
<clever> samueldr: ive been avoiding NM like the plague :P
<clever> Church-: ethernet is much simpler, and dhcpcd will auto-detect the moment you insert any cable
<clever> Church-: you can still connect to open and wep networks without wpa_supplicant
<clever> Church-: wep or wpa?
<clever> Church-: when the gpu drivers on my desktop die, X crashes hard, and if i attempt to restart X, the entire machine crashes, even harder
<clever> what about the journal?, `journalctl -u display-manager`
<clever> that should start x11, and launch a login manager
<clever> Church-: what error did you get?
<clever> jonreeve: nix-env -i ./result
<clever> samueldr: in theory, you could take my haskell-init idea, and just forkIO every single process on the machine, and run your entire distro from pid 1, lol
<clever> the fun part, is loading firmware, without udev
<clever> samueldr: one of my gentoo stage1's did network boot, over wifi
<clever> samueldr: i'm not counting the pre-nix stage1's i did in gentoo
<clever> samueldr: yeah
<clever> samueldr: this one, has zero bash
<clever> samueldr: i also have a 3rd stage-1 using nix: https://github.com/cleverca22/nix-tests/blob/master/haskell-init/hello_world.hs
<clever> not-os has its own stage1 and stage2
<clever> that muates the for loop i just mentioned, so it copies whatever /iso was mounting!
<clever> yuck!
<clever> line 62 of the above file adds "copytoram" to the boot menu
<clever> Church-: that is a boot option
<clever> the tricky part, is that you cant just put an if statement into the initrd, because nixos auto-generates a list that goes into a for loop
<clever> if you allowed 501 and 524 to refer to disk image files on the usb, or normal partitions, then all changes would persist
<clever> and 530 union's the ro-store and rw-store together
<clever> line 524 has another tmpfs for /nix/.rw-store
<clever> samueldr: line 501 uses a tmpfs for /
<clever> samueldr: one min
<clever> it was VERY noticable when i accidentally plugged it into a usb 1.0 hub
<clever> hard drive optional! :P
<clever> samueldr: everything, including $HOME
<clever> if i wanted anything to persist, i had to tar it up and put it back on the usb, at shutdown
<clever> worldofpeace: for several months, i lived like that, entirely in ram :P
<clever> worldofpeace: ive messed around with that before on gentoo, created a custom initrd that let me tar up the tmpfs and persist it to the next boot
<clever> Church-: just go thru the normal install procedure, but use the blockdev of your usb stick, not a sata disk
<clever> Church-: yep
<clever> then you can just nixos-rebuild and changes persist
<clever> samueldr: thats why i prefer installing to a usb, rather then using the iso

2018-10-11

<clever> maybe with a way to escape the ${sep}
<clever> samueldr: all i can think of is to improve the description, description = "string seperated by ${sep}";
<clever> lol
<clever> i tend to get obsessed with how things work, and devour the entire source tree :P
<clever> ive memorized the whole source tree and was expecting to find that in lib/types.nix
<clever> samueldr: lines runs the separatedString function, which returns a set with description = "string";
<clever> that was back before hnix, so i had no easy way to convert to/from configuration.nix and a treeview
<clever> you have a standard treeview, which dynamically shows the description at the bottom, and you can add the selected option to the tree on the left
<clever> samueldr: https://www.youtube.com/watch?v=rIdPKzYTN-w is the QX one
<clever> i also built my own UI's over it
<clever> yep
<clever> samueldr: this is part of my old nixos-installer idea, it would build that json file, from the current channel, and then render the options as an interactive tree
<clever> yeah
<clever> samueldr: the type is actualy lines, which will join multiple values together with a \n
<clever> bgamari_: but if you do `sandbox = relaxed`, then fixed-output derivations get full access to any world-readable file on the host, without having to request anything special
<clever> bgamari_: ive also discovered, that if you do `sandbox = on`, fixed-output derivations are still in a mount namespace, and only get network
<clever> bgamari_: __noChroot is the special key in the drv
<clever> bgamari_: if you set `sandbox = relaxed` in nix.conf, then you can put a special tag in your derivation to disable it
<clever> yep
<clever> Berra: nix strips any trailing /'s from paths
<clever> Berra: path + "/../dir2"
<clever> o1lo01ol1o: nope
<clever> Church-: oh, and my battery is more external, and i can swap it while the machine is on
<clever> so the laptop could be as wide or narrow as they want, and still use the same board
<clever> all of my ports on the right side are on a daughter board with an extension cable, lol
<clever> Church-: the photo on https://system76.com/laptops/oryx looks like a different motherboard
<clever> Church-: you can see that a very large chunk of the kudu is just empty space, and there is an obvious void where the GPU and cooler went
<clever> Church-: https://imgur.com/a/hMY9A
<clever> Church-: i also notice that the oryx shows some pictures of the motherboard, one min
<clever> Church-: i have thought about it a bit, but never got around to it
<clever> Church-: yeah
<clever> o1lo01ol1o: you may need to fork hydra master, then cherry-pick my oldernix commit, and then see what happens with that version
<clever> the branch above, includes both a submodule fix, and the older nix fix
<clever> the option was renamed (and hydrrra was updated to handle the new name), but we are using an older nix
<clever> o1lo01ol1o: yep, i have a branch with that fix
<clever> o1lo01ol1o: simpler to just paste the error your getting
<clever> o1lo01ol1o: hydra can fail to build if your nix version isnt right, i had to patch that to hndle an older nix
<clever> Judson: what about passthru, rather then passThru ?
<clever> Judson: and nix repl lets you eval things directly
<clever> Judson: thats probably reading it at nix time, run `nix show-derivation` on the .drv thats failing, to see what nix generated in the string
<clever> patch*
<clever> o1lo01ol1o: look at what the package is doing exactly, does it check for a file like .version? and then either provide that, or pach what its doing
<clever> steam-run doesnt include everything, so it might still fail due to something missing
<clever> bitmapper: if they need the same dependencies, yeah
<clever> o1lo01ol1o: and some packages try to run `git rev-parse HEAD` to figure out what version they are building
<clever> o1lo01ol1o: fetchFromGitHub doesnt keep the .git directory
<clever> Judson: attributes in the passthru section only apply at the nix level, and dont exist at build time
<clever> (hello.override { foo = bar; }).overrideAttrs (drv: { baz = qux; })
<clever> yeah
<clever> overrideAttrs changes the set that was passed to mkDerivation
<clever> override changes the params at the callPackage level, what gets passed on line 1
<clever> if your trying to do things with an override of some kind
<clever> schmittlauch[m]: you want overrideAttrs, not override
<clever> aleph-: not sure, simplest way to find out is to set it to false and see if it fails
<clever> kiloreux_: or just nix-instantiate
<clever> > hello.drvPath
<clever> Ke: values on the right side have priority, so that will overwrite the "override" value if seb_b contains a .a
<clever> drakonis: yeah, you would want to avoid justdoit in that case, and just drive it manually, normal lvcreate/fdisk/mount/nixos-install
<clever> keep in mind that nixos will probably overwrite the fedora bootloader, and you would need to add a boot option to boot it again
<clever> then just continue with the normal install directions from the manual
<clever> if you want to use lvm for your install, you will need to run lvcreate, and then mount the nixos rootfs to /mnt, and also mount your chosen boot partition to /mnt/boot
<clever> i dont think it has an off button
<clever> lvm is enabled automatically in the initrd
<clever> you can then do whatever nixos things you want from there
<clever> the machine is now running nixos, from a ramdisk, and the previous os has essentialy had an improper shutdown
<clever> then i scp the tar up to a victim machine, unpack it to / and run the bash script
<clever> in this example session, i build a tarball containing a bash script, kexectools, and a kernel+initrd
<clever> kexec lets you just boot a given kernel+initrd, without having to shutdown or mess with any bootloader stuff
<clever> ah, then justdoit wont be of direct use
<clever> drakonis: kexec + justdoit is also an option
<clever> aleph-: that was more of a configuration.nix example
<clever> any time you can have a value, you can also have a `let key=value; in value`
<clever> { pkgs, config }: let common = ...; python = ...; both = common ++ python; in { ... users.users.aleph.packages = both; ... }
<clever> aleph-: you can also put it into a let block at the top of that file
<clever> now you need to decide what to do with common and python, if they are both lists, you could: in common ++ python
<clever> gist updated
<clever> first thing, i would merge them into a single let block...
<clever> having syntax highlighting also makes it obvious its not valid
<clever> you have 2 values
<clever> a nix file must have a single value at the top level
<clever> aleph-: and the file that loads this did what?
<clever> aleph-: can you pastebin the exact contents that failed when you did python36Packages.requests ?
<clever> yeah
<clever> aleph-: re-importing a new copy of nixpkgs in each file will harm performance
<clever> aleph-: it would be better to accept pkgs as an argument with `pkgs:` or `{ pkgs }:`
<clever> ,tofu
<clever> and if you reused the hash of another derivation, it gives you that other source
<clever> judson: it takes the sha256 you give it, computes what the output path is, and then check the cache for a pre-made copy

2018-10-10

<clever> judson: did you update the hash correctly?
<clever> so you need another nix expression that does: let pkgs = import <nixpkgs> {}; in import ./common.nix pkgs
<clever> nix-env doesnt provide that
<clever> the pkgs: defines it to be a function, that accepts a set of packages
<clever> those are strings...
<clever> aleph-: that is a list of strings, not a list of packages
<clever> ,pills
<clever> { is the start of a set, which must contain key=value; pairs
<clever> yeah
<clever> { [] } isnt valid either
<clever> and due to the `with pkgs;` nearby, you can just do [ python36 micro etc ]
<clever> { pkgs.[ "python36" "micro" "etc" ] } is not valid nix
<clever> maybe, lol
<clever> many ways to get it done
<clever> you could also just use modules, create a new file, that looks similar to configuration.nix, and does users.users.aleph.packages = [ pkgs.foo ]; and then just imports = [ ./newfile.nix ];
<clever> then something.nix contains, { pkgs }: [ pkgs.foo pkgs.bar ];
<clever> users.users.aleph.packages = import ./something.nix { inherit pkgs; };
<clever> Church-: the file can also return a list, rather then a single package
<clever> Church-: id generally use callPackage or pass some args when importing
<clever> Church-: most of those examples are meant to go into a config.nix (or under nixpkgs.config) and add packages to the pkgs tree
<clever> yep
<clever> o1lo01ol1o: you can probably use hydra master, and the hydra-fork.nix as an example, if you want to stay with the upstream hydra
<clever> https://github.com/NixOS/hydra/pull/599 somebody else beat me to merging a fix
<clever> my pr has a conflict, on the same file that fixes submodules...
<clever> which fixes many things, including submodules
<clever> o1lo01ol1o: that nix code should get you the hydra from this PR: https://github.com/NixOS/hydra/pull/597
<clever> o1lo01ol1o: the current version of hydra breaks when any inputs contain submodules
<clever> o1lo01ol1o: does the project contain any submodules?
<clever> o1lo01ol1o: then hydra wont check until you force an eval
<clever> o1lo01ol1o: what is the check interval in hydra?
<clever> judson: ah, so its building the entire package, then looking for a default.nix in its result, to build
<clever> Church-: then you want users.users.aleph.packages = [ (import ./pkg1.nix) (import ./pkg2.nix) ];
<clever> o1lo01ol1o: `sudo -u hydra -i` then try to `ssh git@gitlab.com` i think, what happens?
<clever> Church-: users.users.aleph.packages = import path/to/packages.nix; maybe, depends on what packages.nix contains
<clever> judson: the files in your overlays must return a set of packages, if you toss a normal default.nix in there, it will likely malfunction
<clever> o1lo01ol1o: the key must also be owned by the hydra user, or it wont have permission to read the keys
<clever> o1lo01ol1o: /var/lib/hydra
<clever> o1lo01ol1o: enabling the hydra module auto-creates a hydra user
<clever> o1lo01ol1o: the key must exist in the hydra users home, not root's
<clever> o1lo01ol1o: and use an ssh based URL in the build inputs
<clever> o1lo01ol1o: `sudo -u hydra -i` then `ssh-keygen` and give that keypair access, there must be no passphrase
<clever> o1lo01ol1o: one sec
<clever> https://nixos.org/nixos/options.html is another format for the docs in `man configuration.nix`
<clever> that feels like somebody got sloppy with `git add --all`
<clever> but it added no references to the 4.0, so it was useless
<clever> this commit, that claims to be about php stuff, also added the 4.0 version of wxPython
<clever> Synthetica: yeah, duplicating the wxPython30 = line would be better
<clever> ghostyy: this command will load it as a python3 package, and then build it
<clever> nix-build -E 'with import <nixpkgs> {}; python3Packages.callPackage <nixpkgs/pkgs/development/python-modules/wxPython/4.0.nix> {}'
<clever> i see 3.0, but not 4.0 being used
<clever> pkgs/top-level/python-packages.nix: wxPython30 = callPackage ../development/python-modules/wxPython/3.0.nix {
<clever> you also have a copy in ~/.nix-defexpr/ that was made by nix-channel
<clever> grep on nixpkgs
<clever> ghostyy: first, does any other nix file refer to 4.0.nix?
<clever> aleph-: this service runs several weechats, with the weeslack plugin, under systemd services
<clever> aleph-: and nix-env only controls ~/.nix-profile/ and nothing else
<clever> aleph-: for things installed with nix-env, its likely just running on defaults, only nixos-rebuild can impact /etc/
<clever> aleph-: /etc is almost always a symlink to something in /nix/store
<clever> though that exact command is only recomended for single-user installs, and can cause problems on a multi-user machine
<clever> that grabs the latest nixos-unstable from the channels, and installs the nix within it
<clever> Synthetica: recently, i had to update nix on a random box, but didnt want to update the channel because of past latex problems
<clever> Synthetica: so it may be better to pick a rev that you know is stable, and has the thing you want
<clever> Synthetica: and master isnt always built by hydra, or tested
<clever> Synthetica: yeah, but every time you nixos-rebuild it will re-download the latest master, and update those things
<clever> Synthetica: you can fetch a specific revision with builtins.fetchTarball
<clever> this is how i configure my editor
<clever> Synthetica: then i just list which keys i want to have access to what
<clever> but in my setup, i have an attrset containing a list of machines and usernames
<clever> Synthetica: yep, thats also an option
<clever> `cat /etc/ssh/authorized_keys.d/clever` shows you the generated config, after nix has processed that list
<clever> the [ and ] in the string may be breaking it?
<clever> so you can just `curl https://github.com/cleverca22.keys >> ~/.ssh/authorized_keys` and you have access
<clever> if you use that on your own github username, you can get all of your ssh keys
<clever> also handy, `curl https://github.com/cleverca22.keys` will output every public key i trusted in my github
<clever> setup an ssh key in ~/.ssh/authorized_keys
<clever> ssh disables root login by default
<clever> and that
<clever> aleph-: if you just mount the devices under /mnt again, you can re-run nixos-install to apply changes in configuration.nix
<clever> mic921: when the link from the master to the slave dies, the slave kills the in-progress build
<clever> though the copy part may be tricky
<clever> rfold: you can sometimes use `nix copy` and `NIX_STORE=local?root=$NIX_BUILD_TOP/fake-nix/` to be able to test things using nix
<clever> yeah, thats still a problem
<clever> and it will error out if somebody has messed with things
<clever> catern: nix stores the hash of every build product in db.sqlite
<clever> rawtaz: "the cloud is just somebody elses server"
<clever> aanderse: yep
<clever> aanderse: the default shell for that user was probably set to the nologin binary, double-check passwd
<clever> Synthetica: its a common mistake ive seen a couple users do
<clever> aanderse: ive seen a few packages using su to change to a given user
<clever> Synthetica: try "clever++" instead
<clever> either way works
<clever> yeah
<clever> nixos-generate-config would have set it up in hardware-configuration.nix, if /boot was mounted when you ran it
<clever> either configuration.nix or hardware-configuration.nix
<clever> Synthetica: mount | grep boot
<clever> Synthetica: is /boot mounted correctly?
<clever> > "${./.}"
<clever> > toString ./.
<clever> nix turns it into an absolute path automatically
<clever> > builtins.toJSON { path = ./.; }
<clever> > builtins.toJSON { path ./.; }
<clever> but i think builtins.placeholder is the new way to do it
<clever> cocreature: "$(out)" is the usuall hack
<clever> joko: i also need to fix the github status's further, they still have some bugs
<clever> joko: the submodule thing is likely something that would help a number of users
<clever> i have admin access on 4 hydras ....
<clever> and nix-channel does some tricks to obey the same redirect for all files in the dir
<clever> a lot of this stuff just gets burried into your subconcious over the years, and you type the right thing without even knowing why
<clever> only a .xz is generated, no .gz is present
<clever> HTTP/1.1 302 Found
<clever> that url 404's after the 302
<clever> the entire nixos-unstable directory is a redirect to a specific version
<clever> [root@amd-nixos:~]# curl -I https://nixos.org/channels/nixos-unstable/nixexprs.tar.xz -L
<clever> kyren: change that to nixos-18.09, and youll get the exact same tar nix-channel uses, which has the .version file
<clever> kyren: -I nixpkgs=https://nixos.org/channels/nixos-unstable/nixexprs.tar.xz
<clever> kyren: the official channel has a .version file in it to solve that
<clever> kyren: nixpkgs has no way to tell what git rev the tarball came from, so it can only say 18.09pre-git
<clever> jackdk: was mostly thinking about avoiding recursion, but there is none in this case
<clever> jackdk: yeah, you could also do factorio-headless = pkgs.factorio-headless-experimental;
<clever> vikingman: nixpkgs.config.packageOverrides = pkgs: { factorio-headless = pkgs.factorio.override { releaseType = "headless"; experimental = true; }; };
<clever> so you want an overlay or override, to set factorio-headless = factorio.override { releaseType = "headless"; experimental = true; };
<clever> factorio-headless-experimental = factorio.override { releaseType = "headless"; experimental = true; };
<clever> factorio-headless = factorio.override { releaseType = "headless"; };
<clever> the nixos module uses the pkgs.factorio-headless package

2018-10-09

<clever> bemeurer: should be as simple as just nix-env -iA nixpkgs.nix after you update the channel
<clever> ah, neat
<clever> echo $SSH_AUTH_SOCK outside, and then export SSH_AUTH_SOCK=<the value> inside
<clever> or re-set SSH_AUTH_SOCK
<clever> so a directory either exists in complete, or doesnt exist, and is never between
<clever> nix is focusing on atomicly removing things from the store, rather then deleting fast
<clever> but files are deleted instantly
<clever> another factor, is that nix moves the garbage directories to /nix/store/trash, so you gain almost no space for 90% of the time spent
<clever> space*
<clever> yeah, those are more mutable and just give you the speed
<clever> but, if you encounter a garbage file in /nix/store/ it wont be renamed to trash, and will be deleted immediately
<clever> so even renaming an entry in /nix/store requires space
<clever> and similarly, zfs cant modify any directory in-place, and has to make a new directory listing
<clever> zfs is as immutable as nix, and if you have a snapshot, you gain nothing upon deletion
<clever> but some filesystems dont actually give you space back when that happens
<clever> it will also delete this 8mb file when it starts, to give itself some room
<clever> -rw------- 1 root root 8.0M Oct 9 14:53 /nix/var/nix/db/reserved
<clever> rawtaz: it moves all garbage to /nix/store/trash, and it has to update a sqlite database
<clever> you can also just stop when you hit your goal, and keep some garbage around
<clever> and then gradually work the number up until it has enough to gc normally
<clever> that will stop after deleting 1kb
<clever> rawtaz: nix-collect-garbage --max-freed 1024