2018-02-23

<clever> LnL: the amd variant is handled by the kvm_amd kernel module
<clever> elvishjerricco: then its already using kvm, what about the ram within the guest, what does free -m report?
<clever> wervenyt[m]: /dev/kvm only exists if the modules are loaded and its enabled in the bios
<clever> elvishjerricco: while the VM is running, do "ps aux | grep qemu" on the host, and check its args, is kvm listed?
<clever> elvishjerricco: does /dev/kvm exist?
<clever> dottedmag: the closest thing i can think of is hnix, a haskell project
<clever> i prefer screen
<clever> ldlework: you want home.packages = [ (pkgs.python27Packages.python.WithPackages (ps: [ ps.jedi ]) ) ];
<clever> ldlework: also, nix lists are weird, that does not call withPackages, that makes a list containing a function and a list
<clever> ldlework: withPackages expects to be given a function, that is passed all the python packages
<clever> lejonet: oops, that was meant for ldlework
<clever> lejonet: you need to use python.withPackages
<clever> yeah
<clever> lejonet: youll also want to double-check that it still works on older nixpkgs
<clever> TweyII: same
<clever> some small bits like builtins.fetchTarball with a sha256 require both client&daemon to be updated
<clever> lejonet: sounds like a bug in nixops, not compatible with that nixpkgs version, maybe send nixops a PR?
<clever> the irc client doesnt always tab-complete in a predictable way
<clever> oops
<clever> mrkgnao: thats systemd only
<clever> a small OS built with nix and using runit
<clever> taohansen: and nix-env -f '<nixpkgs>' -iA nix-info ?
<clever> taohansen: and nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
<clever> taohansen: what does sudo nix-channel --list say?

2018-02-22

<clever> sphalerite_: also, i managed to hard-lock pid 1 when the fuse process crashed
<clever> sphalerite_: oh, ive also got some systemd-nspawn scripts in my narfuse repo
<clever> gillmanash: you could maybe have a git repo of helper files for tasks like that
<clever> gillmanash: of you import <nixpkgs> { config = {}; overlays = []; } then all config.nix and overlays are ignored
<clever> gillmanash: and line 4 blocks the config.nix, but overlays didnt exist when i made that, so its not covered
<clever> gillmanash: for this project, the release.nix provides linux and darwin derivations for the nearby default.nix
<clever> gillmanash: yeah
<clever> gillmanash: i prefer having something like a release.nix, that loads nixpkgs and blocks all overlays/overrides, and provides its own
<clever> sphalerite_: i run nixos on my router, with static IP's via dhcp, and dns pointing to those IP's
<clever> when that was fixed, synergy broken, because it wasnt set to read /home/clever/.Xauthority
<clever> sphalerite_: the xorg was just allowing connections from any user
<clever> sphalerite_: when i first got into nixos, the synergy stuff was running as root, with $DISPLAY, and worked, due to an un-discovered security problem
<clever> shlevy: though both of them require uncompressed .nar files in a directory to operate
<clever> now it can lazily parse just enough of the nar to do what it needs
<clever> (one of the first big things i did in haskell)
<clever> https://github.com/taktoa/narfuse so with the help of taktoa, i rewrote it into haskell
<clever> but i found that c++ took too long to parse the files
<clever> shlevy: this is a c++ fuse layer, that takes a directory of nar files, and mounts them
<clever> shlevy: one min
<clever> ive found bluetooth to be a pain to work with
<clever> not sure then
<clever> jonge: in pavucontrol, on the configuration tab, what options do you have?
<clever> jonge: and you then need to connect with something like blueman
<clever> hardware.pulseaudio.package = pkgs.pulseaudioFull; has to be set to get bluetooth support
<clever> jonge: also, have you changed pulseaudio.package?
<clever> jonge: then something else running as the gdm user might be trying to use audio?
<clever> jonge: try killing it with the kill command?
<clever> BlessJah: i'm not sure whats the best way to deal with your ESP though
<clever> BlessJah: zfs supports its own raid'ing, so you dont need to put it ontop of mdadm or anything
<clever> lejonet: yeah
<clever> BlessJah: i believe the menu entries are programmed into the bios, with the efibootmgr program
<clever> BlessJah: EFI booting with grub just auto-detects whatever you mounted to /boot/
<clever> BlessJah: and i dont think the bios supports mdadm based raid, so if you did raid sda1&sdb1, it would have to be done without any headers prefixed onto them
<clever> BlessJah: that device field is only for legacy booting
<clever> BlessJah: if you are using EFI, then you dont need to set the device in grub
<clever> BlessJah: i'm not sure, ive found them to be a bit unpredictable
<clever> lejonet: put the configuration.nix stuff into a file, then nix-repl /path/to/nixpkgs/nixos -I nixos-config=/path/to/configuration.nix
<clever> BlessJah: yeah
<clever> BlessJah: so at least the rootfs and /nix have to be via legacy
<clever> BlessJah: the nixos boot scripts expect your rootfs to be mounted with the standard mount command
<clever> lejonet: and do you have a line like this?
<clever> lejonet: double-check against your version of nixos/modules/misc/version.nix
<clever> lejonet: it tries to read either your .git, or one of a few version files in the root dir of the nixpkgs
<clever> lejonet: let me see...
<clever> lejonet: sounds related
<clever> lejonet: not sure thats related
<clever> lejonet: the nixops state doesnt come that early into the nix eval
<clever> lejonet: i'm out of ideas then
<clever> lejonet: that can happen when your not on a version hydra has pre-built
<clever> does one nixpkgs fail, and the other nixpkgs work?
<clever> the values dont really matter, that build will never be booted
<clever> nix-build /path/to/nixos --arg configuration '{ ... }: { boot.loader.grub.devices = "/dev/sda"; }' -A system
<clever> you can set that config inside the {}
<clever> no, point it to /path/to/nixpkgs/nixos
<clever> lejonet: try both, and use the nixos sub-dir
<clever> nix-build /path/to/nixos --arg configuration '{ ... }: {}' -A system
<clever> lejonet: what about this command...
<clever> lejonet: but it sounds more like your nixpkgs is broken then nixops
<clever> lejonet: yeah, i'm not sure whats up with that
<clever> lejonet: /nix/var/nix/profiles/per-user/clever/channels/
<clever> lejonet: nixops deploy --build-only --show-trace -I nixpkgs=/path/to/something
<clever> lejonet: try pointing that at a normal channel temporarily, and see if `deploy --build-only` works
<clever> lejonet: where does <nixpkgs> point?, nix-instantiate --find-file nixpkgs
<clever> lejonet: everything looks just fine, try `nixops deploy --build-only --show-trace` and add it to the gist
<clever> lejonet: can you also add configuration.nix?
<clever> and it will update the gist (you will also want to gist --login)
<clever> lejonet: nix-env -iA nixos.gist, then "gist -u <gisturl> file1.nix file2.nix"
<clever> lejonet: and line 2 is missing a ;
<clever> lejonet: the ( on line 3 is missing the matching )
<clever> lejonet: can you add the 2 files on line 9 to the gist?
<clever> lejonet: can you gist that output?
<clever> lejonet: what does `nixops info` say?
<clever> lejonet: ?
<clever> lejonet: i think so
<clever> lejonet: and if the machine names match up, it will just upgrade them to match the new expressions
<clever> lejonet: i believe you can change the deployment file with nixops modify
<clever> manveru: have you seen not-os?
<clever> KABA: /exit
<clever> gchristensen: check the likn i linked above in nixos-install.sh
<clever> gchristensen: nixos-install basically resets NIX_PATH
<clever> nhill: sure
<clever> nhill: line 111 uses NIX_PATH to find <nixpkgs>, then it sets a new NIX_PATH, with only nixpkgs and nixos-config
<clever> nhill: maybe
<clever> nhill: nixos-install also messes with NIX_PATH
<clever> nhill: what command did you run to cause the rrror?
<clever> so all paths refering to the rootfs, are the host root
<clever> gchristensen: there is also a bug with the recent nixos-install, where it just does the nix-build in the host env, then copies the result over
<clever> so you can just makeFlags = [ "-Dsomeflag=foo" ];
<clever> TonyTheLion: the default buildPhase will obey makeFlags
<clever> TonyTheLion: ons min, oops
<clever> troydm: one min
<clever> troydm: and make sure its inside the linuxPackagesFor function, in all-packages.nix
<clever> nhill: also, setting programs.fish.enable adds it to systemPackages for you, so you can remove that bit
<clever> fish isnt a service that runs in the background
<clever> nhill: i think its programs.fish
<clever> boomshroom: you can also put that line into a shell-32bit.nix and then just point nix-shell at the file
<clever> boomshroom: nix-shell -E 'with import <nixpkgs> {}; pkgsi686Linux.stdenv.mkDerivation { name = "dummy"; buildInputs = []; }'
<clever> boomshroom: and if you use pkgsi686Linux.callPackage, everything you depend on will be 32bit
<clever> boomshroom: if you use pkgsi686Linux.stdenv.mkDerivation then it will use 32bit compiler/linkers
<clever> troydm: i havent done any kernel modules since getting into nix
<clever> troydm: grep the whole nixpkgs for the name of another directory in that region
<clever> troydm: you need to edit a file somewhere to reference the new rtl8192eu directory
<clever> guibou: it sounds like you need to add the library to the rpath of the program in question, with patchelf
<clever> but it will persist after a .overrideAttrs
<clever> so its the same as (mkDeriation ..) // { foo = bar; }
<clever> samueldr: so they have no effect on the hash of that derivation
<clever> samueldr: passthru adds attributes to the derivation, but does not actually exposed them as env vars within the derivation
<clever> samueldr: i would instead use passthru
<clever> samueldr: 1.11.15 also checks for that flag
<clever> samueldr: it will also obey the tarball-ttl field in nix.conf or --option
<clever> yeah, an hour sounds right
<clever> samueldr: you can also just make the url different when the contents change, thats another simpler way to deal with it
<clever> and then reuse caches, based on the hash of the tar
<clever> if you just nuke the entire directory, it will re-download the tar
<clever> the filename is a hash of the url its for
<clever> the second is a symlink to its location in the store
<clever> the first is the metadata about the url and a timestamp
<clever> lrwxrwxrwx 1 clever users 91 Feb 21 14:13 0d4h36hxmzd1dw4109idlxppb0ly013laj79b1bw1068mi0zgh2m-file -> /nix/store/d9q7wc59j6didr4m85hzwyxbqqgf7qaj-4fb198892d298452023ab176e7067da58d30772e.tar.gz
<clever> -rw-r--r-- 1 clever users 143 Feb 21 14:13 0d4h36hxmzd1dw4109idlxppb0ly013laj79b1bw1068mi0zgh2m.info
<clever> [clever@amd-nixos:~]$ ls -ltrh .cache/nix/tarballs/
<clever> one sec
<clever> and may reuse the output
<clever> and if you choose to have it unpacked, it will generate a derivation that unpacks, compute the output path, and check the store for that
<clever> then, based on the cache-control headers, it may discover it hasnt changed, and re-use the storepath again
<clever> and based on the TTL, either reuse the old store path, or re-query the webserver
<clever> samueldr: first, it will hash the url, and lookup a cache file in $HOME
<clever> samueldr: ive read the code involved in it
<clever> sphalerite_, triangles: -p doesnt accept channel names, only package attribute paths

2018-02-21

<clever> gchristensen: try logging `ps -eH x` from inside this program to see what its parent is?
<clever> dash: yeah, getting the npm built under nix is still a tricky part
<clever> dash: this downloads an electron based darwin app, extracts the javascript code, then generates a nix package that runs it under nixpkgs electron
<clever> dash: i have recently noticed that discord patchelf's the discord supplied electron, and now the file-browse dialog is significantly older and lacking of features
<clever> dash: i just run ${electron}/bin/electron against the dir with package.json
<clever> which may count as bloat
<clever> firefox linking against PA will pull it in as a dependency, even when the user isnt using it
<clever> i use pulseaudio on all of my desktop systems
<clever> 2 laptops, 1 desktop, router, nas, and several servers
<clever> i use nixos on every machine i have installed since discovering nixos
<clever> same
<clever> nixpkgs.config.packageOverrides = pkgs: { openssl = pkgs.libressl.override { fetchurl = pkgs.fetchurlBoot; }; };
<clever> i copied some mistakes again, lol
<clever> wait
<clever> toogley: this might fix it
<clever> nixpkgs.config.packageOverrides = super: config: { openssl = super.libressl.override { fetchurl = pkgs.fetchurlBoot; }; };
<clever> toogley: yep, openssl is given a special fetchurl to prevent the issue
<clever> 10614 fetchurl = fetchurlBoot;
<clever> 10613 inherit (callPackages ../development/libraries/openssl {
<clever> toogley: curl uses openssl, and nearly everything needs curl to download its src
<clever> toogley: oh, i think i know why
<clever> toogley: can you gist the files you have?
<clever> toogley: oops, my example gist carried over that mistake
<clever> toogley: packageOverrides is a function that expects only 1 argument
<clever> that content only works in configuration.nix or another nixos module
<clever> none of that belongs in config.nix, lol
<clever> wait
<clever> and your being passed pkgs on line 3, so dont ask for any params at all
<clever> toogley: config.nix shouldnt be asking for params like that, its not a module
<clever> it will only effect foo
<clever> but if you do foo = pkgs.foo.override { openssl = pkgs;libressl; };
<clever> toogley: if you do openssl = pkgs.libressl;, it will affect every single package that uses openssl
<clever> toogley: you could do nixpkgs.config = import /home/clever/.config/nixpkgs/config.nix; to reload the same overrides in nixos
<clever> toogley: but the nixpkgs inside configuration.nix, obeys the nixpkgs.config attribute in your configuration.nix
<clever> toogley: nixpkgs on its own, will load ~/.config/nixpkgs/config.nix for overrides
<clever> toogley: the whole point of packageOverrides is that it lets you alter the inputs to some packages without having to clone nixpkgs
<clever> [clever@amd-nixos:~]$ nix-build '<nixpkgs/nixos>' --arg configuration '{ pkgs, ... }: { services.mysql.enable = true; services.mysql.package = pkgs.mysql; }' -A config.systemd.services.mysql.runner
<clever> gchristensen: one minute, typing up an example...
<clever> gchristensen: is that the perl wrapper around systemd?
<clever> a fetchFromFile would have solved that
<clever> and every single eval took an extra 30 seconds, to re-hash it
<clever> i was doing data manipulation with nix, and feeding it a 400mb file with src = ./foo.tar.gz;
<clever> and ive ran into similar issues before
<clever> i dont think so
<clever> Myrl-saki: depends on if root ever builds and runs that variant of pocl
<clever> Myrl-saki: and if configuration.nix obeys those overrides, it becomes the global sudo that actually has perms
<clever> Myrl-saki: the packages cant sudo, but the packageOverrides can define a new version of sudo
<clever> seequ: the only thing stateVersion does, is adjust what version of something like postgresql you get, to make sure you dont break the on-disk state
<clever> Myrl-saki: i could put in a malicious packageOverride to sudo or ping, both of which have setuid root
<clever> seequ: you always get the version in the channel, stateVersion doesnt control what version you get
<clever> Mic92: what Myrl-saki said, somebody could add an extra user with wheel perms in your config files in $HOME, and next time you nixos-rebuild, they get a free user with admin
<clever> seequ: switching from unstable to 17.07 will probably downgrade some things
<clever> seequ: just change the channel with the nix-channel command, and nixos-rebuild to update it
<clever> seequ: you dont have to clean install to get new features
<clever> Myrl-saki: which mutates the defaults in the stdenv
<clever> Myrl-saki: when you put cmake into the buildInputs, the stdenv will source this script
<clever> seequ: the stateVersion must always be set to the version you originally installed with
<clever> seequ: changing it defeats the entire point of having it
<clever> seequ: it must not be bumped
<clever> Myrl-saki: i always enable it
<clever> seequ: you could even just boot it normally, nix-channel --add the right url, and nixos-rebuild switch
<clever> Myrl-saki: darwin or nixos?
<clever> Myrl-saki: yeah
<clever> so you have to passwd and systemctl start sshd
<clever> seequ: the installer has an sshd, and i think root login is enabled, but auto-start is off
<clever> mt_caret_: add an echo to the script?
<clever> so just load it with pkgsi686Linux.callPackage and it should work
<clever> mt_caret_: pkgsi686Linux will give you 32bit versions of everything
<clever> mt_caret_: is the package doing a 32bit only build, or a mixed 32/64 build?
<clever> chreekat: you can also just add the nix-serve thing to the binary-caches config, and it will just always use the cache
<clever> chreekat: i dont think ssh-substituters has a trusted variant
<clever> chreekat: i think it has to be configured in /etc/nix/nix.conf for all users to benefit from it
<clever> sondr3: but you can set a uid = 1001; in the configuration.nix to prevent that
<clever> sondr3: it wont even try to fix the uid, so you may lack access to your own home directory
<clever> sondr3: yeah
<clever> sondr3: it wont delete anything from /home
<clever> ah, i probably need to update my channel
<clever> not actually a .lib output
<clever> "/nix/store/rimh7x5nn5dzzzfppp3m6nhv2a6z206j-clang-4.0.1"
<clever> nix-repl> "${clang.cc.lib}"
<clever> error: attribute ‘lib’ missing, at (string):1:1
<clever> nix-repl> clang.lib
<clever> dtz: i dont see a lib output
<clever> this would roll the socat stuff directly into nix, so you just pass a flag to nix-build and it works
<clever> i also have an issue open about improving things: https://github.com/NixOS/nix/issues/1256
<clever> so its just a matter of then passing the -I's to nixos-rebuild
<clever> taohansen: you could create a systemd service that manages starting the socat, and the file from the 2nd command should persist if your not wiping /tmp on shutdown
<clever> taohansen: but you can give it access to an ssh-agent, which keeps the secret a secret
<clever> taohansen: there is no real secure way to give nixbld access to the private key, without exposing it to every single build you do
<clever> taohansen: one min
<clever> Lisanna: can you gist the nix expressions?
<clever> unsafeDiscardStringContext should be identical to just typing it in directly
<clever> if you refer to it elsewhere, anywhere in the closure, it will be checked for
<clever> Lisanna: can you gist the nix expression?
<clever> nflores: ah, putting the -H and its param in the same string probably messed with things

2018-02-20

<clever> ive got no idea what the original problem was, lol
<clever> then the changes will be compiled in from the start
<clever> aminechikhaoui: you can also modify the nix expressions in nixpkgs that generated all of this, then just nixos-rebuild switch and reboot
<clever> aminechikhaoui: it might be contacting the existing instance, and reusing the script it was given
<clever> aminechikhaoui: ps aux | grep udhcpc
<clever> aminechikhaoui: what about just adding an echo $router or just plain 'set' or 'env' to the script?
<clever> aminechikhaoui: did you point udhcpc at the modified version of the script?
<clever> aminechikhaoui: preferably after a reboot so the state has been reset
<clever> aminechikhaoui: copy the script to the current directory, and edit it to add "set -x", then re-run it
<clever> aminechikhaoui: probably the reply it got from the dhcp server
<clever> vitiral-lap: yeah
<clever> vitiral-lap: sure
<clever> aminechikhaoui: that script is passed to the dhcp client, which will then set the vars and run it
<clever> udhcpc --quit --now --script ${udhcpcScript} && hasNetwork=1
<clever> nflores: try downloading it with a manual curl from a normal shell, and see what happens?
<clever> nflores: i also suspect that the token only applies to the first url, you want to switch to -u
<clever> nflores: there is a flag for curl to make it follow redirects, check its man page
<clever> nflores: that puts your token into the nix store, and it basically becomes public, depending on what you have configured
<clever> infinisil: so you can pre-test a dns, before making it active
<clever> infinisil: the first obeys /etc/resolv.conf, the second forces it to use a certain server
<clever> infinisil: `dig google.com` and `dig google.com @192.168.2.1`
<clever> infinisil: i prefer dig for testing
<clever> nflores: and i think you can put a user:pass for github or also a personal access token into that
<clever> nflores: if you set NIX_CURL_FLAGS prior to starting a build, those will be passed to curl when it tries to download things
<clever> nflores: ahh, i dont think the artifacts are available over ssh, one min
<clever> nflores: ive done it with ssh and ssh-agent
<clever> infinisil: possibly, but until we know what the "right" config is, its hard to know what commands to run
<clever> vitiral-lap: are you able to connect from another linux distro and have it work?, gather the same command outputs, and compare them
<clever> vitiral-lap: so its trying to access those servers via your main router/gateway
<clever> vitiral-lap: it also doesnt direct it over eth0, so those arent "local"
<clever> vitiral-lap: oh, the routing table doesnt direct that over tun0
<clever> vitiral-lap: but its likely what it inserted into /etc/resolv.conf
<clever> vitiral-lap: the logs dont clearly say what the dns server is
<clever> vitiral-lap: no
<clever> hask_bee_3: can you run nix-instantiate --find-file nixos-14.04, and then run ls -lh on that path?
<clever> *looks*